Licensing and Copyright
Luke Kanies
I fear this discussion will quickly devolve into a recursive flame-
fest, but it needs to be broached, so here we go. Note that I kind of
think this is more of dev topic than users, but I want to make sure
everyone knows the conversation is happening and can easily
participate. This is also likely to be the first of a series of
conversations I'll be starting to try to paper over the lack of
organization and process we've had in the past.
First, I want to be clear that this is me seeking your input - we
haven't decided on anything, and I'm starting this thread so we have
the necessary data to make a decision. We have to be conscious that
Reductive Labs is a commercial company, though. My development of
Puppet and the money I make around it feeds my family and keeps us
housed, allowing me to focus on it full time.
I think our focus on building community stands on its own, but the
contributor list is an equally clear indication that being paid to
work on Puppet results in a lot more work being done on Puppet - of
the top ten Puppet contributors (http://www.ohloh.net/p/puppet/contributors
), 5 have been paid by their companies to do the work, and 4 have been
paid specifically by Reductive Labs (me, Andrew, Rick, and Ben/ajax).
One of my goals in this discussion is to figure out the best way to
pay more people to work on Puppet, by having enough money to hire
them. (Incidentally, I should be posting a job description for a full-
time programmer at Reductive Labs this week.)
Finally, if you have concerns about this topic that you don't feel
comfortable voicing publicly, feel free to contact me directly.
So:
We've never done a very good job of having much of a licensing or
copyright strategy for Puppet and the tools around it. While all of
the projects have a license, there's no documentation on how to
maintain the license (e.g., whether every file should have a license
header), and there's a bit of confusion around the license itself
since Puppet's current license file says 'GPL2 or later'.
As to copyright, we're *pretty* good at maintaining that, especially
since we switched to Git, since everyone who commits has their email
address recorded with the commit, but we don't have an official
project policy published anywhere one way or another, and we just
haven't been tracking copyright.
For both the project and my company, I think we need to develop
complete policies around these two topics, and then spend time
actually maintaining them.
Given that we have a license but no policies or history around it, I
think it's worth revisiting the basics, and assessing what's best for
the project. I expect that Reductive Labs would fund any work that
needs to be done to enact these policies, but as always, I'll do what
I can to encourage community involvement.
I think there are essentially two decisions to make, with some details
around them:
1) Should we use a completely open Apache-style license, or a
reciprocal/viral GPL-style license?
2) Should we require copyright assignment of any kind?
Going with those questions, we have two priorities:
1) Maximize ability to grow and sustain a community
2) Enable Reductive Labs to increase its funding of development
This second point is important to be obvious about - like Pixar (http://www.nytimes.com/2009/04/06/business/media/06pixar.html
), we make money so we can write software, and Puppet clearly needs
more development time than we're spending on it right now. There are
further tools beyond Puppet that we also want to create, but we need
enough developer manpower to be able to do so.
I expect this point to be the biggest source of contention, so all I
can really say is, Reductive Labs isn't suddenly morphing into an anti-
community commercial vendor who uses open source for marketing but
doesn't actually believe in it. I'm asking *you*, right now, how we
can tune our licensing and copyright policy to best meet your needs.
If that doesn't satisfy you, I'll be glad to fly out and discuss it
with you for $5,000 USD per day. :)
Really, though, one of my other goals here is to be more transparent
about how Reductive Labs hopes to make money and continue funding
development. Many people in the community are curious on this front
for many reasons, and I think it's important it be clear.
Here is some reading on this subject, to kind of set the context:
http://madstop.com/2009/02/28/the-most-freetm-way-to-make-money-from-open-source/
(This article came out much more in favor than Open Core than it was
supposed to; the article was supposed to be a question, rather than an
answer.)
http://blogs.the451group.com/opensource/2009/04/06/on-the-importance-of-copyright-assignment/
http://www.knowledgetree.com/blog/company-driven-open-source-communities-copyright-assignment
Fundamentally, I see three basic choices:
1) Leave them like they are. No copyright assignment, no real
copyright maintenance, GPL2 or later. This means that every
contributor ever must give permission for things like license changes,
we can't easily protect against license infringement (http://www.gnu.org/licenses/why-assign.html
), no one can ever dual license, and essentially no commercial
software can ever be produced that integrates with Puppet.
2) Stick to a viral/reciprocal license (probably AGPLv3) but require
Sun-style copyright contribution (which provides the project a non-
exclusive license to the copyright). This provides a single
organization with a license for all copyright, and allows that license
holder (Reductive Labs) to protect against license infringement,
provide patent indemnity (which I've already been asked about by
others but cannot currently offer), relicense Puppet (and produce
commercial software that integrates with that relicensed product),
and probably more.
3) Switch to a non-reciprocal license (e.g., Apache) and don't require
copyright coassignment. This allows anyone to do anything with the
code, so there's no real concern about license infringement and anyone
can make commercial add-ons. This is both good and bad, though, in
that even those with no commitment to Puppet's community could build
commercial products on it, which I think is not so great.
After spending the last month thinking about it, and talking with many
people (e.g., Tarus Balog, Matt Asay, Marten Mickos, Mark Radcliffe,
and many more), I think #2 is the best option. It provides the best
combination of openness for the community and opportunity for
Reductive Labs. It hurts to say this, because I've always thought
copyright assignment was evil, but I've been convinced otherwise,
mostly by the links above and conversation with Tarus of OpenNMS.
The problem I have with #1 is that is explicitly limits Puppet's
ability to integrate with other commercial software, which I think is
unfortunate and makes it hard to build Puppet into an ecosystem,
rather than just being a stand-alone tool. The problem I have with #3
is that I have a hard time seeing how Reductive Labs can add more
programmers to the project with it.
What do you think?
--
It is said that power corrupts, but actually it's more true that power
attracts the corruptible. The sane are usually attracted by other things
than power. -- David Brin
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com
Stephen John Smoogen
>
> Hi all,
>
> I fear this discussion will quickly devolve into a recursive flame-
> fest, but it needs to be broached, so here we go. Note that I kind of
> think this is more of dev topic than users, but I want to make sure
> everyone knows the conversation is happening and can easily
> participate. This is also likely to be the first of a series of
> conversations I'll be starting to try to paper over the lack of
> organization and process we've had in the past.
>
Hi I am cutting down a lot of stuff to try and put my comments into a
concise format:
> 1) Should we use a completely open Apache-style license, or a
> reciprocal/viral GPL-style license?
> 2) Should we require copyright assignment of any kind?
>
> Going with those questions, we have two priorities:
>
> 1) Maximize ability to grow and sustain a community
> 2) Enable Reductive Labs to increase its funding of development
>
> Fundamentally, I see three basic choices:
>
> 1) Leave them like they are. No copyright assignment, no real
> copyright maintenance, GPL2 or later. This means that every
> contributor ever must give permission for things like license changes,
> we can't easily protect against license infringement (http://www.gnu.org/licenses/why-assign.html
> ), no one can ever dual license, and essentially no commercial
> software can ever be produced that integrates with Puppet.
>
> 2) Stick to a viral/reciprocal license (probably AGPLv3) but require
> Sun-style copyright contribution (which provides the project a non-
> exclusive license to the copyright). This provides a single
> organization with a license for all copyright, and allows that license
> holder (Reductive Labs) to protect against license infringement,
> provide patent indemnity (which I've already been asked about by
> others but cannot currently offer), relicense Puppet (and produce
> commercial software that integrates with that relicensed product),
> and probably more.
>
> 3) Switch to a non-reciprocal license (e.g., Apache) and don't require
> copyright coassignment. This allows anyone to do anything with the
> code, so there's no real concern about license infringement and anyone
> can make commercial add-ons. This is both good and bad, though, in
> that even those with no commitment to Puppet's community could build
> commercial products on it, which I think is not so great.
OK with any licensing issue.. you need to have a lawyer's advice on
things :/. They will be able to give the best advice on whether a re
licensing can be done and what the best ways of doing so will be. The
method I have seen for anyone changing from 1 to 2/3 is that they
either required everyone to sign on the commit list or rewrite from
scratch and get FSF/Sun style copyright contributions going (or some
combination of the two.)
> After spending the last month thinking about it, and talking with many
> people (e.g., Tarus Balog, Matt Asay, Marten Mickos, Mark Radcliffe,
> and many more), I think #2 is the best option. It provides the best
> combination of openness for the community and opportunity for
> Reductive Labs. It hurts to say this, because I've always thought
> copyright assignment was evil, but I've been convinced otherwise,
> mostly by the links above and conversation with Tarus of OpenNMS.
>
> The problem I have with #1 is that is explicitly limits Puppet's
> ability to integrate with other commercial software, which I think is
> unfortunate and makes it hard to build Puppet into an ecosystem,
> rather than just being a stand-alone tool. The problem I have with #3
> is that I have a hard time seeing how Reductive Labs can add more
> programmers to the project with it.
>
> What do you think?
The one other issue you will need to do is craft what the license you
use to sell for people to incorporate puppet into a non-GPL product. I
believe a couple of companies have been screwed by selling a version
to some company under a 'closed' license and then seeing that the
other company uses that code to compete against the first company.
Again get a software lawyer well versed in contract law to draft an
appropriate one where A) they can't take improvements from the GPL
version and pull it into their license, and B) product improvements
that are made for them can be 'Freed' at some definite point in the
future (as in now to 6 months from the date they are made.).
--
Stephen J Smoogen. -- BSD/GNU/Linux
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"
Jason Slagle
> 1) Leave them like they are. No copyright assignment, no real
> copyright maintenance, GPL2 or later. This means that every
> contributor ever must give permission for things like license changes,
> we can't easily protect against license infringement (http://www.gnu.org/licenses/why-assign.html
> ), no one can ever dual license, and essentially no commercial
> software can ever be produced that integrates with Puppet.
>
> 2) Stick to a viral/reciprocal license (probably AGPLv3) but require
> Sun-style copyright contribution (which provides the project a non-
> exclusive license to the copyright). This provides a single
> organization with a license for all copyright, and allows that license
> holder (Reductive Labs) to protect against license infringement,
> provide patent indemnity (which I've already been asked about by
> others but cannot currently offer), relicense Puppet (and produce
> commercial software that integrates with that relicensed product),
> and probably more.
>
> 3) Switch to a non-reciprocal license (e.g., Apache) and don't require
> copyright coassignment. This allows anyone to do anything with the
> code, so there's no real concern about license infringement and anyone
> can make commercial add-ons. This is both good and bad, though, in
> that even those with no commitment to Puppet's community could build
> commercial products on it, which I think is not so great.
I think a lot of it depends on your goals.
Clearly long term #1 does not work. It provides a big mess for you and
puts in you a boat of only ever really being able to sell support.
I feel option number 2 will further limit the number of people willing to
contribute code. Especially if you plan to sell it commercially later.
For instance, at my employer here I could contribute some code (and as I
bone up on Ruby I may even attempt to, even if it's only some types and
stuff at first). However, it gets a lot stickier contributing back if the
I'm contributing code that you may be selling. Conflict and all.
I must admit I'm a fan of the Apache license or a BSD license of some
sort. It gives you the right to sell it while also remaining open. It
also means that I don't have to have a copyright laywer on staff to modify
your code and use it locally :)
Jason
--
Jason Slagle - RHCE
/"\ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
\ / ASCII Ribbon Campaign .
X - NO HTML/RTF in e-mail .
/ \ - NO Word docs in e-mail .
Kyle Cordes
> 2) Stick to a viral/reciprocal license (probably AGPLv3) but require
> Sun-style copyright contribution (which provides the project a non-
> exclusive license to the copyright). This provides a single
> organization with a license for all copyright, and allows that license
I think this kind of license is eminently fair: the sponsoring
organization, which pays for most of the development, gets the
(essentially exclusive) right to productize it, while others can use the
open product at no cost (or buy something from the company, of course),
but can't productize it.
However, while fair, I think this ends to lead to business models that
are relatively unappealing to both customers and potential contributors.
Contributing to projects licensed thusly feels like offering free labor
to a commercial enterprise, rather than to a community.
I don't have any better idea to propose, though. We all need to make a
living.
--
Kyle Cordes
http://kylecordes.com
Russ Allbery
> 2) Stick to a viral/reciprocal license (probably AGPLv3) but require
> Sun-style copyright contribution (which provides the project a non-
> exclusive license to the copyright). This provides a single
> organization with a license for all copyright, and allows that license
> holder (Reductive Labs) to protect against license infringement, provide
> patent indemnity (which I've already been asked about by others but
> cannot currently offer), relicense Puppet (and produce commercial
> software that integrates with that relicensed product), and probably
> more.
AGPL is a little controversial, to warn. So far, I think it's likely that
organizations such as Debian will continue to consider it sufficiently
free, but it's a bit odd in its requirements and depending on how one
reads it, some people think that it's onerous for a developer who wanted
to make private modifications.
I'm not sure it's a big enough problem to warrant not using it, but it's
something to be aware of. It makes people more nervous than the GPL does.
--
Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
Robin Lee Powell
> I think there are essentially two decisions to make, with some
> details around them:
>
> 1) Should we use a completely open Apache-style license, or a
> reciprocal/viral GPL-style license?
I'm not a big fan of viral-style in most cases; it seems like giving
with one hand and slapping with the other. (Depends on the
software, though; I don't mind it for compilers, for example. I
also don't really want to get into it.)
Having said that, I think either choice is extremely generous; I'd
still contribute (not that I've contributed code yet) if it was
"free to distribute but not modify", OSLT. This is your baby, I
can't imagine being bothered by what you choose to do with it as
long as it's still free for me with my 3 machines over here.
> 2) Should we require copyright assignment of any kind?
My limited understanding of the legal ramifications says that yes,
you probably should.
[snip]
> Fundamentally, I see three basic choices:
>
> 1) Leave them like they are. No copyright assignment, no real
> copyright maintenance, GPL2 or later. This means that every
> contributor ever must give permission for things like license changes,
> we can't easily protect against license infringement (http://www.gnu.org/licenses/why-assign.html
> ), no one can ever dual license, and essentially no commercial
> software can ever be produced that integrates with Puppet.
>
> 2) Stick to a viral/reciprocal license (probably AGPLv3) but require
> Sun-style copyright contribution (which provides the project a non-
> exclusive license to the copyright). This provides a single
> organization with a license for all copyright, and allows that license
> holder (Reductive Labs) to protect against license infringement,
> provide patent indemnity (which I've already been asked about by
> others but cannot currently offer), relicense Puppet (and produce
> commercial software that integrates with that relicensed product),
> and probably more.
>
> 3) Switch to a non-reciprocal license (e.g., Apache) and don't require
> copyright coassignment. This allows anyone to do anything with the
> code, so there's no real concern about license infringement and anyone
> can make commercial add-ons. This is both good and bad, though, in
> that even those with no commitment to Puppet's community could build
> commercial products on it, which I think is not so great.
I agree that #2 seems best. I'm really shocked by the Chef project;
it seems really offensive to me, and I'd like to see you guys go in
a direction that stops someone from just rebundling Puppet and
calling it theirs.
-Robin
--
They say: "The first AIs will be built by the military as weapons."
And I'm thinking: "Does it even occur to you to try for something
other than the default outcome?" -- http://shorl.com/tydruhedufogre
http://www.digitalkingdom.org/~rlpowell/ *** http://www.lojban.org/
David Lutterkort
> I fear this discussion will quickly devolve into a recursive flame-
> fest
Here we go ;)
> 1) Should we use a completely open Apache-style license, or a
> reciprocal/viral GPL-style license?
I would prefer if you dropped the word 'viral' in there - feels like a
strange (though popular) value judgment.
> 2) Should we require copyright assignment of any kind?
>
> Going with those questions, we have two priorities:
>
> 1) Maximize ability to grow and sustain a community
> 2) Enable Reductive Labs to increase its funding of development
Laudable and understandable goals.
> This second point is important to be obvious about - like Pixar (http://www.nytimes.com/2009/04/06/business/media/06pixar.html
> ), we make money so we can write software, and Puppet clearly needs
> more development time than we're spending on it right now. There are
> further tools beyond Puppet that we also want to create, but we need
> enough developer manpower to be able to do so.
I am not sure if this is what you are getting at, but if you are
thinking about some sort of proprietary/open split (ala ghostscript),
you need to carefully weigh the increase in revenue against both turning
off potential contributors and the lack of bug reports from the open
version.
I would only even consider this if you have solid data that you could
increase your revenue this way. (And I don't want to put you on the spot
here - don't feel like you have to respond to this paragraph) As with
any open source project, the big issue here are the people who like the
software enough to run it when it's free but not pay for the support
contract. Make sure that you have solid data that you can get some of
those to pay in whatever model you look at.
Have you considered being more agressive about doing only development
you are being paid for. I find the expectation that you help chase down
and fix bugs from people who have deployed puppet but are not willing to
buy support entirely unrealistic - you wouldn't dream asking for
something similar from your car mechanic.
> 1) Leave them like they are. No copyright assignment, no real
> copyright maintenance, GPL2 or later. This means that every
> contributor ever must give permission for things like license changes,
> we can't easily protect against license infringement (http://www.gnu.org/licenses/why-assign.html
> ), no one can ever dual license,
Copyright assignment is an interesting point in this - being able to
deal with license infringement would be an important aspect. I think
it's only workable if the software is under an extremely open license
(GPL). It also increases the burden to contribute quite a bit; while a
lot of employers won't mind sending the occasional patch to a mailing
list, getting copyright assignment papers signed is a serious headache.
If you want to go with copyright assignment, you should explore if
there's any way to turn puppet into an FSF project, since a lot of
people trust them to do the right thing, and have umbrella agreements in
place with them.
> 2) Stick to a viral/reciprocal license (probably AGPLv3) but require
I don't understand why the AGPL is of interest here - I was under the
impression that it was meant fo online services a la Google Apps.
Have you considered switching to the LGPL ? IANAL, but the idea that you
can 'link' from proprietary software to the open software might leave
enough room for you to write custom providers etc. for hire and keep
them closed for a while.
> provide patent indemnity (which I've already been asked about by
> others but cannot currently offer),
Strange - without knowing anything about your balance sheet, RL doesn't
have the resources to fight a patent suit, and not really anything else
that would make RL an attractive target for such a suit. By offering
indemnity, you'd make yourself a proxy in a fight between the big boys
(one being your client, and the other not)
> The problem I have with #1 is that is explicitly limits Puppet's
> ability to integrate with other commercial software, which I think is
> unfortunate and makes it hard to build Puppet into an ecosystem,
> rather than just being a stand-alone tool. The problem I have with #3
> is that I have a hard time seeing how Reductive Labs can add more
> programmers to the project with it.
>
> What do you think?
I am also much in favor of #2. I can see that relicensing as LGPL might
make some sense.
David
David Lutterkort
> I must admit I'm a fan of the Apache license or a BSD license of some
> sort. It gives you the right to sell it while also remaining open. It
> also means that I don't have to have a copyright laywer on staff to modify
> your code and use it locally :)
You don't need one with the (L)GPL either: as long as you don't
distribute your modifications, you can keep everything you do to
yourself.
And when you distribute, your obligations are only to those that receive
a modified version of the software, not the public at large. For
example, it's perfectly legal for Luke to modify the GPL'd puppet source
for a client and give that only to that client - all he is obliged to do
is to give the sources to whatever he changed to them and allow _them_
to pass that on. If that client chooses not to redistribute, that's the
end of the story - it has to be a choice though, Luke can't require 'no
further distribution' from his clients.
Having to distribute the sources of your modifications is kinda moot
with Ruby anyway - it would be much harder not to.
David
Paul Lathrop
I wish I knew more about the issues at hand. I know that my existing
knowledge as well as my intuition leads me to agree that option #2 is
best for Reductive Labs and the Puppet community as a whole. On the
other hand, I also know that the copyright assignment thing is going
to make it more difficult for me to make contributions. Although I'm
not a big contributor, I do have permission to spend time writing code
for Puppet -- as long as that process only impacts my department, I'm
likely to keep getting permission. Unfortunately, copyright assignment
involves the legal branch of our company, who are typically clueless
corporate-whore lawyers. Once they have to get involved, it is going
to get ugly. I think other people at startups might face similar
barriers to contribution.
Thanks for keeping this process open, Luke, I hope people give you the
credit you deserve for your efforts to make Reductive Labs be a
community member rather than a corporate dictator.
--Paul
Kyle Cordes
> best for Reductive Labs and the Puppet community as a whole. On the
> other hand, I also know that the copyright assignment thing is going
> to make it more difficult for me to make contributions. Although I'm
My impression is that the bulk of projects that use a
commercial-open-source model, regardless of the licensing, generally end
up with very few outside contributors anyway. I wish it weren't so, but
I suspect it is.
Robin Lee Powell
I'll take it a few steps further: the bulk of projects end up with
very few contributors.
You can talk about the bazaar all you want, but the truth is that
almost all software is written almost entirely by a small oligarchy
at most. Hence my being happy with pretty much anything Luke
chooses on this front.
Luke Kanies
Yep, I'm already working with a lawyer, so I have a good idea of what
any conversion will take (exactly as you say - every committer will
need to sign off, or his/her work will need to be redone). This will
be expensive time-wise, but I think all significant contributors are
still around and have no problems signing off (I've asked around
already).
Yeah, this license would certainly be picked carefully, again with
advice from a lawyer with significant experience in this space.
Any improvements for them would be handled on a per-contract basis,
but I'll certainly always push to have everything open-sourced right
away.
--
Life is too short for traffic. --Dan Bellack
Luke Kanies
Can you elaborate on what you think the problems will be?
I don't see how a conflict could develop.
>
> I must admit I'm a fan of the Apache license or a BSD license of some
> sort. It gives you the right to sell it while also remaining open.
> It
> also means that I don't have to have a copyright laywer on staff to
> modify
> your code and use it locally :)
Well, you wouldn't need a copyright lawyer if you bought a license
from us. I think that's part of the reason for supporting dual
licensing - if this is something that concerns your company, then you
can solve it by paying a bit. If you stay all open source, no problems.
I'm not saying this is what I would do, but that it is the natural
consequence of choosing a GPL-like license.
--
I love deadlines. I like the whooshing sound they make as they fly by.
--Douglas Adams
Mike
it. I would imagine that as long as there is a not-stagnant
community, bugs are being fixed regularly, it is included as part of
the distributions I use, and nothing comes along that is a lot better,
I'll keep using it. But the chances are relatively slim that I'll
ever contribute any code back. I'll always try to file a good bug
report or answer questions when they come up. But if I'm paying for
support, then all bets are off. If I were paying for support (and
with 10 linux machines and relatively simple needs, its unlikely that
I would pay for support) all bets are off - I'm not filing any bug
reports or helping anybody else.
I don't know how many people would stop contributing if they had to
assign their copyrights to Reductive Labs. But that requirement
wouldn't stop me. Like Robin mentioned, I would guess over time the
number of contributors stays relatively small. If you think about the
Mythical Man Month, the number of contributors is always going to be
small - just like the percentage of people in an operating room who
are surgeons is relatively small. There are lots of non-code tasks
that are part of software development.
And just for the record, if there was a version of Puppet that worked
on Windows clients, I probably would want some sort of support
contract for about 100 machines.
Luke Kanies
I have the same kind of mixed feelings, and I've traditionally fallen
on the side of "give it all away with no strings attached".
Except, of course, the GPL attaches its own strings. I realized when
looking into it that I almost definitely couldn't release commercial
add-ons to my own project if I wanted to, because I don't own all of
the copyright and it's released under a reciprocal license.
At some point, everything's a compromise: Either you compromise the
amount of free, or you compromise the ability to build a company
around the produt. There aren't a lot of open source projects out
there in the infrastructure space that succeed without companies
paying for the majority of development, so it seems pretty important
to have a healthy company behind Puppet's development.
--
The most dangerous strategy is to jump a chasm in two leaps.
-- Benjamin Disraeli
Luke Kanies
I'll keep that in mind. I don't know license specifics; I was
planning on leaving that up to the lawyerly discussions, given a
general plan.
--
Fallacies do not cease to be fallacies because they become fashions.
--G. K. Chesterton
Luke Kanies
>
> On Mon, Apr 06, 2009 at 02:15:44PM -0500, Luke Kanies wrote:
>> I think there are essentially two decisions to make, with some
>> details around them:
>>
>> 1) Should we use a completely open Apache-style license, or a
>> reciprocal/viral GPL-style license?
>
> I'm not a big fan of viral-style in most cases; it seems like giving
> with one hand and slapping with the other. (Depends on the
> software, though; I don't mind it for compilers, for example. I
> also don't really want to get into it.)
>
> Having said that, I think either choice is extremely generous; I'd
> still contribute (not that I've contributed code yet) if it was
> "free to distribute but not modify", OSLT. This is your baby, I
> can't imagine being bothered by what you choose to do with it as
> long as it's still free for me with my 3 machines over here.
It's true that this was my baby initially, and I've still got the vast
majority of the commits (and probably an even larger share of the
lines), but it's becoming less true all the time, and I hope it
becomes even less true over time.
At the same time, I hope to have more room to do the long-term cool
stuff I actually built Puppet to do, and that's where I will hopefully
be able to exert my influence beyond basic ability to churn out code.
>
>> 2) Should we require copyright assignment of any kind?
>
> My limited understanding of the legal ramifications says that yes,
> you probably should.
Yeah, the legal side seems to say yes, we'll see if the community side
will allow it.
To be clear here, Chef isn't Puppet rebundled or anything; it takes a
lot of Puppet's obvious advancements, but it doesn't share any code
(and can't, because we use the GPL2). Fortunately it doesn't seem to
include any of Puppet's less obvious advancements, so... :)
--
A conservative is a man who believes that nothing should be done for
the first time. --Alfred E. Wiggam
Jason Slagle
>> I feel option number 2 will further limit the number of people
>> willing to
>> contribute code. Especially if you plan to sell it commercially
>> later.
>> For instance, at my employer here I could contribute some code (and
>> as I
>> bone up on Ruby I may even attempt to, even if it's only some types
>> and
>> stuff at first). However, it gets a lot stickier contributing back
>> if the
>> I'm contributing code that you may be selling. Conflict and all.
>
> Can you elaborate on what you think the problems will be?
>
> I don't see how a conflict could develop.
Sure..
While $employer doesn't necessarily mind me contributing code to open
source projects (As well as making donations which is something I'll
certainly look at once I finish my rollout), it becomes a lot more harry
if I'm working on code on $company's dime that your selling directly as a
commercial product.
You almost are forced to make a pretty hard split like some of the other
projects where you have seperate sites and everything for the "community
edition" and the commercial one.
It can be done - I think mysql for instance does it fairly successfully.
It's just considerably trickier from a contribution standpoint.
>> I must admit I'm a fan of the Apache license or a BSD license of some
>> sort. It gives you the right to sell it while also remaining open.
>> It
>> also means that I don't have to have a copyright laywer on staff to
>> modify
>> your code and use it locally :)
>
> Well, you wouldn't need a copyright lawyer if you bought a license
> from us. I think that's part of the reason for supporting dual
> licensing - if this is something that concerns your company, then you
> can solve it by paying a bit. If you stay all open source, no problems.
>
> I'm not saying this is what I would do, but that it is the natural
> consequence of choosing a GPL-like license.
The AGPL is really scary with it's section 13.
It's be even scarier to me if I was a company doing hosting and trying to
use your product, because it's a REALLY slipper scope when you deal with
things like modules.
LGPL is a little better. However, I think AGPL on a project like this
that is very "programming" based is really a huge problem.
Luke Kanies
>
> On Mon, 2009-04-06 at 14:15 -0500, Luke Kanies wrote:
>> I fear this discussion will quickly devolve into a recursive flame-
>> fest
>
> Here we go ;)
Indeed.
>
>> 1) Should we use a completely open Apache-style license, or a
>> reciprocal/viral GPL-style license?
>
> I would prefer if you dropped the word 'viral' in there - feels like a
> strange (though popular) value judgment.
I sometimes feel like it's pretty viral, but I understand your point -
the term is more hyperbolic than informative. I'll drop it.
I don't actually know how we'll increase revenue based on these
licensing changes; this discussion is driven by our lack of clarity
rather than revenue goals, I just want to make sure that the company
is out there as part of my input when discussing it.
I think there are valid revenue models around all options I outlined,
but I think they're most obvious and most common around a gpl that
allows relicensing. That combines maximum freeness for the community
while allowing the main company behind the product a bit more
flexibility, along with a push for some usages of the product to
encourage a relicensing.
>
> Have you considered being more agressive about doing only development
> you are being paid for. I find the expectation that you help chase
> down
> and fix bugs from people who have deployed puppet but are not
> willing to
> buy support entirely unrealistic - you wouldn't dream asking for
> something similar from your car mechanic.
I've tried this a bit, and I seem to have set completely unrealistic
expectations by providing such good free support for a few years. :/
I believe, to be crude, that many have taken my attempts to get paid
for development as a "fuck you pay me" attitude (yeah, that's a quote).
As is probably obvious, I've scaled back my free online support and my
attempts at fixing every bug ever, but a certain amount is still
required all around to make sure the community has the information it
needs and the product is stable.
It's true that I could step back even further and really only do
development I got paid for, but the truth is that I have *much* bigger
goals for Puppet and the tools around it, and I'm not content to sit
on the product as it is now. Dashboards and a module site are big
priorities this year, but there's other really interesting stuff to do
in the Puppet core, too.
>> 1) Leave them like they are. No copyright assignment, no real
>> copyright maintenance, GPL2 or later. This means that every
>> contributor ever must give permission for things like license
>> changes,
>> we can't easily protect against license infringement (http://www.gnu.org/licenses/why-assign.html
>> ), no one can ever dual license,
>
> Copyright assignment is an interesting point in this - being able to
> deal with license infringement would be an important aspect. I think
> it's only workable if the software is under an extremely open license
> (GPL). It also increases the burden to contribute quite a bit; while a
> lot of employers won't mind sending the occasional patch to a mailing
> list, getting copyright assignment papers signed is a serious
> headache.
Yep, that's already come up in off-list discussions, and I knew it
would be a big deal.
>
> If you want to go with copyright assignment, you should explore if
> there's any way to turn puppet into an FSF project, since a lot of
> people trust them to do the right thing, and have umbrella
> agreements in
> place with them.
I'm not sure I'm comfortable with that, but I don't have good
reasons. I don't know much about the organization, and the majority
of my impression of it comes from my own personal experience with
Stallman, along with some other second-hand (by many parties) stories
of behaviour I'm not a fan of.
>
>> 2) Stick to a viral/reciprocal license (probably AGPLv3) but require
>
> I don't understand why the AGPL is of interest here - I was under the
> impression that it was meant fo online services a la Google Apps.
I will be quite surprised if there isn't some kind of hosted
puppetmaster service at some point, and I'd like people who make those
to contribute their code back.
>
> Have you considered switching to the LGPL ? IANAL, but the idea that
> you
> can 'link' from proprietary software to the open software might leave
> enough room for you to write custom providers etc. for hire and keep
> them closed for a while.
Yep. That's an option, but it seems kind of not-quite-here-or-there.
It might be the best option in the end, though.
>
>> provide patent indemnity (which I've already been asked about by
>> others but cannot currently offer),
>
> Strange - without knowing anything about your balance sheet, RL
> doesn't
> have the resources to fight a patent suit, and not really anything
> else
> that would make RL an attractive target for such a suit. By offering
> indemnity, you'd make yourself a proxy in a fight between the big boys
> (one being your client, and the other not)
That's true, and my initial thought was "wtf? no way!". I've been
talking to lawyers about this, and apparently a far larger group of
people than you'd expect demand this. The most indemnity I could ever
provide is the amount that a customer paid me, but yeah, this is a
nasty situation all around.
>
>> The problem I have with #1 is that is explicitly limits Puppet's
>> ability to integrate with other commercial software, which I think is
>> unfortunate and makes it hard to build Puppet into an ecosystem,
>> rather than just being a stand-alone tool. The problem I have with
>> #3
>> is that I have a hard time seeing how Reductive Labs can add more
>> programmers to the project with it.
>>
>> What do you think?
>
> I am also much in favor of #2. I can see that relicensing as LGPL
> might
> make some sense.
That seems to be the majority view so far, but there are still plenty
of concerns about the copyright aspects.
--
However beautiful the strategy, you should occasionally look at the
results. -- Sir Winston Churchill
Luke Kanies
> I wish I knew more about the issues at hand. I know that my existing
> knowledge as well as my intuition leads me to agree that option #2 is
> best for Reductive Labs and the Puppet community as a whole. On the
> other hand, I also know that the copyright assignment thing is going
> to make it more difficult for me to make contributions. Although I'm
> not a big contributor, I do have permission to spend time writing code
> for Puppet -- as long as that process only impacts my department, I'm
> likely to keep getting permission. Unfortunately, copyright assignment
> involves the legal branch of our company, who are typically clueless
> corporate-whore lawyers. Once they have to get involved, it is going
> to get ugly. I think other people at startups might face similar
> barriers to contribution.
I expect you're right, but I would hope to be able to invest time in
helping to convince these lawyers.
If I have to pay for a couple of hours' time to convince a company's
lawyers to allow contribution here or there, it's probably worth it.
And after a few such conversations, I think our side could be carried
on without lawyers, or we'll have some on staff and won't pay the
hourly rates.
Either way the lawyerly stuff comes up a lot more often than I'd like.
>
> Thanks for keeping this process open, Luke, I hope people give you the
> credit you deserve for your efforts to make Reductive Labs be a
> community member rather than a corporate dictator.
Thanks, we try. :)
--
Charm is a way of getting the answer yes without asking a clear
question. -- Albert Camus
Luke Kanies
>
> On Mon, Apr 06, 2009 at 05:15:38PM -0500, Kyle Cordes wrote:
>>
>> Paul Lathrop wrote:
>>> best for Reductive Labs and the Puppet community as a whole. On
>>> the other hand, I also know that the copyright assignment thing
>>> is going to make it more difficult for me to make contributions.
>>> Although I'm
>>
>> My impression is that the bulk of projects that use a
>> commercial-open-source model, regardless of the licensing,
>> generally end up with very few outside contributors anyway. I
>> wish it weren't so, but I suspect it is.
>
> I'll take it a few steps further: the bulk of projects end up with
> very few contributors.
>
> You can talk about the bazaar all you want, but the truth is that
> almost all software is written almost entirely by a small oligarchy
> at most. Hence my being happy with pretty much anything Luke
> chooses on this front.
This is a good point. The vast, vast majority of open source projects
have a core set of people who do nearly all of the work, and the
majority of projects also have most of their work done by people being
paid to work on those projects.
Just looking at the ohloh contribtors[1] makes it clear that it's true
for us, and once I have a couple more programmers on staff we'll be
contributing an even larger share of the commits.
Of course, I'll continue to be commited to an open development
community, and I've already started pushing internal development
conversations to the list, which has been a strange and difficult
adjustment, for some reason.
1 - http://www.ohloh.net/projects/puppet/contributors
--
To define recursion, we must first define recursion.
Luke Kanies
I wouldn't have a community edition and a commercial edition. First,
all contributions would be guaranteed to be open source, so I could
never take someone's open contribution and only include it in a
commercial product. Second, I might have commercial add-ons, but one
of my main reasons for thinking about this is that I adamantly don't
want to get into a situation where there's anything like a commercial
edition.
That being said, I don't want to rule out the possibility of some
commercial add-ons that would only be useful in large or peculiar
environments. Not opening up these could never be said to cripple the
main project since most people would never use them anyway.
>
> It can be done - I think mysql for instance does it fairly
> successfully.
> It's just considerably trickier from a contribution standpoint.
They've basically set the standard, and I'd largely follow them. I
had a conversation with their former CEO about exactly this, and his
arguments were a big part of what got me thinking this way.
>>> I must admit I'm a fan of the Apache license or a BSD license of
>>> some
>>> sort. It gives you the right to sell it while also remaining open.
>>> It
>>> also means that I don't have to have a copyright laywer on staff to
>>> modify
>>> your code and use it locally :)
>>
>> Well, you wouldn't need a copyright lawyer if you bought a license
>> from us. I think that's part of the reason for supporting dual
>> licensing - if this is something that concerns your company, then you
>> can solve it by paying a bit. If you stay all open source, no
>> problems.
>>
>> I'm not saying this is what I would do, but that it is the natural
>> consequence of choosing a GPL-like license.
>
> The AGPL is really scary with it's section 13.
>
> It's be even scarier to me if I was a company doing hosting and
> trying to
> use your product, because it's a REALLY slipper scope when you deal
> with
> things like modules.
>
> LGPL is a little better. However, I think AGPL on a project like this
> that is very "programming" based is really a huge problem.
I see.
I'll make sure the final license choice is vetted thoroughly, and I'll
do my best to pick something relatively non-controversial. Or
something. It's all a pit of snakes, of course.
--
Don't hit at all if it is honorably possible to avoid hitting; but
never hit soft! -- Theodore Roosevelt
James Turnbull
Hash: SHA1
Luke Kanies wrote:
> I think our focus on building community stands on its own, but the
> contributor list is an equally clear indication that being paid to
> work on Puppet results in a lot more work being done on Puppet - of
> the top ten Puppet contributors (http://www.ohloh.net/p/puppet/contributors
> ), 5 have been paid by their companies to do the work, and 4 have been
> paid specifically by Reductive Labs (me, Andrew, Rick, and Ben/ajax).
> One of my goals in this discussion is to figure out the best way to
> pay more people to work on Puppet, by having enough money to hire
> them. (Incidentally, I should be posting a job description for a full-
> time programmer at Reductive Labs this week.)
So I'll put my ten cents in as the remaining member of the ten. To be
clear I am completely unpaid for my work on the project by my employer
or Reductive Labs. Though Luke does buy drinks sometimes.
Excuse any rambling I am typing this whilst on holidays in Thailand on
the end of some shaky connections.
*big snips*
> 1) Should we use a completely open Apache-style license, or a
> reciprocal/viral GPL-style license?
I have concerns over the use of the word 'viral' as a value judgement
but okay...
> 2) Should we require copyright assignment of any kind?
Fundamentally think that's a good summary.
> Going with those questions, we have two priorities:
>
> 1) Maximize ability to grow and sustain a community
> 2) Enable Reductive Labs to increase its funding of development
It should be clear here that under certain models these could be
mutually exclusive.
> I expect this point to be the biggest source of contention, so all I
> can really say is, Reductive Labs isn't suddenly morphing into an anti-
> community commercial vendor who uses open source for marketing but
> doesn't actually believe in it. I'm asking *you*, right now, how we
> can tune our licensing and copyright policy to best meet your needs.
> If that doesn't satisfy you, I'll be glad to fly out and discuss it
> with you for $5,000 USD per day. :)
I have no issues with you needing to eat and to be honest I've always
thought you were way too generous with your time on "non-core"
activities and especially to people who a) lack manners and b) treat the
community as if they were paying support.
> 1) Leave them like they are. No copyright assignment, no real
> copyright maintenance, GPL2 or later. This means that every
> contributor ever must give permission for things like license changes,
> we can't easily protect against license infringement (http://www.gnu.org/licenses/why-assign.html
> ), no one can ever dual license, and essentially no commercial
> software can ever be produced that integrates with Puppet.
I have no issues with a GPLv2/3 style license but I appreciate the
reasons why it might not work.
> 2) Stick to a viral/reciprocal license (probably AGPLv3) but require
> Sun-style copyright contribution (which provides the project a non-
> exclusive license to the copyright). This provides a single
> organization with a license for all copyright, and allows that license
> holder (Reductive Labs) to protect against license infringement,
> provide patent indemnity (which I've already been asked about by
> others but cannot currently offer), relicense Puppet (and produce
> commercial software that integrates with that relicensed product),
> and probably more.
I have no issues with an AGPLv3 license but obviously see issues with 1.
I personally probably wouldn't be able to contribute to the community in
this instance. It would be quite difficult for me professionally to
sign a Sun-style SCA/copyright contribution license.
> 3) Switch to a non-reciprocal license (e.g., Apache) and don't require
> copyright coassignment. This allows anyone to do anything with the
> code, so there's no real concern about license infringement and anyone
> can make commercial add-ons. This is both good and bad, though, in
> that even those with no commitment to Puppet's community could build
> commercial products on it, which I think is not so great.
This is my preference but again understand the challenges. I do wonder
how many people would be potentially building commercial products from
Puppet currently - though I can understand the potential future threat.
> What do you think?
I find myself in broad agreement with David Lutterkort on most of the
issues in this discussion. Though, personally, I don't much care which
license is used - LGPL seems to be attractive, (A)GPLv3, even BSDv2 -
all of which suit me fine to varying degrees of "fine". Dual licenses
also seem a reasonable approach to me (though all these models all
require copyright assignment of some kind - see below).
The copyright assignment I find myself conflicted about. I think there
would need to be a compelling commercial reason to do this. I obviously
want to see Reductive and Puppet flourish - and if this requires that an
SCA/copyright assignment of some kind takes place then so be it.
I think it'd limit the potential contributions to the community -
including mine. I also think a lot of casual bug/patch submitters won't
bother if they have to sign an agreement - especially if, like me, it
requires dealing with corporate legal people. I suspect that some of
the "paid" corporate contributors are also going to have issues with this.
Regards
James Turnbull
- --
Author of:
* Pro Linux Systems Administration
(http://www.amazon.com/gp/product/1430219122/)
* Pulling Strings with Puppet
(http://www.amazon.com/gp/product/1590599780/)
* Pro Nagios 2.0
(http://www.amazon.com/gp/product/1590596099/)
* Hardening Linux
(http://www.amazon.com/gp/product/1590594444/)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFJ2sIj9hTGvAxC30ARAnfiAJ9sPzevOWO6L4uJL+fya46JYWLI2wCeLv8P
AKnvxtnqVeTDrFt8kPDcsdw=
=Jlmd
-----END PGP SIGNATURE-----
Kyle Cordes
> As is probably obvious, I've scaled back my free online support and my
> attempts at fixing every bug ever, but a certain amount is still
There is dangerous territory nearby: Paying customers have a higher
expectation of a smooth out-of-box-experience, than open source users;
to make this happen it is necessary to debug vigorously. However, open
source users tend to chafe at the thought of a "community" version
intentionally left buggy while a "pay" version is fixed. I think the
only clean way out of this is a lot of debugging.
Related to this, I can tell you from personal experience in commercial
software: support costs can be an enormously drain. The most effective
way to keep them down is with relentless quality improvement: kill bugs,
make features more comprehensible, document, make failure modes gentle,
make errors clear, etc.
Robin Lee Powell
> > I agree that #2 seems best. I'm really shocked by the Chef
> > project; it seems really offensive to me, and I'd like to see
> > you guys go in a direction that stops someone from just
> > rebundling Puppet and calling it theirs.
>
> To be clear here, Chef isn't Puppet rebundled or anything; it
> takes a lot of Puppet's obvious advancements, but it doesn't
> share any code (and can't, because we use the GPL2).
Yeah, I know; it just got my dander up.
Luke Kanies
>
> Luke Kanies wrote:
>> As is probably obvious, I've scaled back my free online support and
>> my
>> attempts at fixing every bug ever, but a certain amount is still
>
> There is dangerous territory nearby: Paying customers have a higher
> expectation of a smooth out-of-box-experience, than open source users;
> to make this happen it is necessary to debug vigorously. However, open
> source users tend to chafe at the thought of a "community" version
> intentionally left buggy while a "pay" version is fixed. I think the
> only clean way out of this is a lot of debugging.
Yep, it's essentially a ridiculous balance to try to find, especially
since the third leg of the balance (after revenue and community) is my
own life. I seem to sacrificing it rather than the other two, and I'm
trying to find a better balance between them all.
I don't think I'm doing great at any of them, and my wife would
certainly agree, but I'm constantly tuning it. I've been spending
more effort on the lists recently (albeit in chunks).
And, of course, I remain committed to keeping Puppet itself as stable
as possible, but the definition of "stable" is always open to
definition, unfortunately.
>
> Related to this, I can tell you from personal experience in commercial
> software: support costs can be an enormously drain. The most effective
> way to keep them down is with relentless quality improvement: kill
> bugs,
> make features more comprehensible, document, make failure modes
> gentle,
> make errors clear, etc.
Considering how many people have told me they don't buy support
because they find Puppet so easy that they just don't need help, I'm
not too concerned about this yet.
--
The chief lesson I have learned in a long life is that the only way to
make a man trustworthy is to trust him; and the surest way to make him
untrustworthy is to distrust him and show your distrust.
-- Henry L. Stimson
Larry Ludwig
>> Related to this, I can tell you from personal experience in
>> commercial
>> software: support costs can be an enormously drain. The most
>> effective
>> way to keep them down is with relentless quality improvement: kill
>> bugs,
>> make features more comprehensible, document, make failure modes
>> gentle,
>> make errors clear, etc.
>
(said somewhat tongue and cheek)
Hey, isn't that the purpose of commercial software?
You need support because while it works in some way, yet does not
completely work and must pay for support to get it working? :-)
Support most certainly can be a profit center.
In a serious note, for an OSS project I would say Puppet has a pretty
good development/testing process. Hell I've known commercial products
that went through less testing. Can Puppet's development process be
improved? Definately yes and is something that will be constantly
revisited.
-L
--
Larry Ludwig
Reductive Labs
Andrew Shafer
I've been using Puppet for a month or two, and plan to keep on using
it. I would imagine that as long as there is a not-stagnant
community, bugs are being fixed regularly, it is included as part of
the distributions I use, and nothing comes along that is a lot better,
I'll keep using it. But the chances are relatively slim that I'll
ever contribute any code back. I'll always try to file a good bug
report or answer questions when they come up. But if I'm paying for
support, then all bets are off. If I were paying for support (and
with 10 linux machines and relatively simple needs, its unlikely that
I would pay for support) all bets are off - I'm not filing any bug
reports or helping anybody else.
Mike,
Why would support change your behavior so much?
Clearly, the way my perspective has changed since I started working for an Open Source company cannot be overstated
The way I saw it before your email (and this isn't just in regard to Puppet) was a classification of support customers handful of overlapping categories. For example 'bought support as a company policy', 'recognized the value of the project and bought support to support the project' and 'really needed help with the software'.
I've used many open source projects and many commercial products. Ironically, particularly when considering your statement, I believe I have opened more bugs against commercial products. I also usually helped whomever with any software that I clearly could help with, regardless of the licensing.
Your statement here stuck out and struck me as far removed from my own perspective. I'm hoping you will elaborate so I can better understand your position.
Regards,
Andrew
Bryan Kearney
contributed too (Apache, Fedora, JBoss) and they all require copyright
assignment. It does not seem to be way off base.
The issue will be, I believe, how Reductive reacts to having the
copyright. Some people will be offended by dual licensing, others will
be offended by open-core licensing. I dont know that you can please
everyone. As long as the actions which Reductive takes are supportive of
the community, I think it would be fine. I personally would prefer the
LGPL license, but I could see where RL would prefer GPL + copyright
assignment. That would protect them the most from a revenue point of view.
Anyone know an editor at the Harvard Business Review? It would be great
to get the process/thinking pros and cons documented.
-- bk
Bryan Kearney
developers. But users are even more valuable. If RL were to release a
full featured community version, and then a supported version based on
that.. the community is doing the hardening. This does not mean that the
community version is bad.. just new. The proof would be that bugs get
fixed in both.
-- bk
Jason Slagle
> Kyle Cordes wrote:
>>
>> There is dangerous territory nearby: Paying customers have a higher
>> expectation of a smooth out-of-box-experience, than open source users;
>> to make this happen it is necessary to debug vigorously. However, open
>> source users tend to chafe at the thought of a "community" version
>> intentionally left buggy while a "pay" version is fixed. I think the
>> only clean way out of this is a lot of debugging.
>>
>> Related to this, I can tell you from personal experience in commercial
>> software: support costs can be an enormously drain. The most effective
>> way to keep them down is with relentless quality improvement: kill bugs,
>> make features more comprehensible, document, make failure modes gentle,
>> make errors clear, etc.
>>
> But this is the value of a community. Too often the focus is on the
> developers. But users are even more valuable. If RL were to release a
> full featured community version, and then a supported version based on
> that.. the community is doing the hardening. This does not mean that the
> community version is bad.. just new. The proof would be that bugs get
> fixed in both.
That's not how the model tends to work though. Usually the paid community
gets the product first with the community version lagging behind by a
release.
Bryan Kearney
> On Tue, 7 Apr 2009, Bryan Kearney wrote:
>
>> Kyle Cordes wrote:
>>> There is dangerous territory nearby: Paying customers have a higher
>>> expectation of a smooth out-of-box-experience, than open source users;
>>> to make this happen it is necessary to debug vigorously. However, open
>>> source users tend to chafe at the thought of a "community" version
>>> intentionally left buggy while a "pay" version is fixed. I think the
>>> only clean way out of this is a lot of debugging.
>>>
>>> Related to this, I can tell you from personal experience in commercial
>>> software: support costs can be an enormously drain. The most effective
>>> way to keep them down is with relentless quality improvement: kill bugs,
>>> make features more comprehensible, document, make failure modes gentle,
>>> make errors clear, etc.
>>>
>> But this is the value of a community. Too often the focus is on the
>> developers. But users are even more valuable. If RL were to release a
>> full featured community version, and then a supported version based on
>> that.. the community is doing the hardening. This does not mean that the
>> community version is bad.. just new. The proof would be that bugs get
>> fixed in both.
>
> That's not how the model tends to work though. Usually the paid community
> gets the product first with the community version lagging behind by a
> release.
>
> Jason
>
>
way. As typical, your mileage may vary.
-- bk
Kyle Cordes
> Considering how many people have told me they don't buy support
> because they find Puppet so easy that they just don't need help, I'm
> not too concerned about this yet.
I think you're getting a false signal from this. I am confident that
tools in/around Puppet to make a gentle learning curve would make it
accessible to many times more users. For every 1 person that tells you
this, there could be 10 (100?) who struggle for a few hours to get
started, hit some of the many caveats, and wander away.
I really like Puppet. I've been working with Linux for over a decade. I
have a highly automation-centric mindset. I know Ruby and can read its
stack traces. Yet I had to struggle quite a long while to get Puppet up
and going correctly on a set of machines.
The sky is the limit, in terms of using the fruits of monetization to
create a positive feedback loop in which more success (users / money /
polish) yields more success.
Kyle Cordes
> The way I saw it before your email (and this isn't just in regard to
> Puppet) was a classification of support customers handful of overlapping
> categories. For example
> 'bought support as a company policy',
> 'recognized the value of the project and bought support to support the
> project' and
> 'really needed help with the software'.
Now that is very interesting. For a company looking for a good open
source business model, it could be very informative to somehow eke
information out of existing commercial open source firms, about the
typical customer breakdown (and price point tolerance) among those
categories.
Michael Semcheski
> The way I saw it before your email (and this isn't just in regard to Puppet)
> was a classification of support customers handful of overlapping
> categories. For example 'bought support as a company policy', 'recognized
> the value of the project and bought support to support the project' and
> 'really needed help with the software'.
Very recently, I looked at Zmanda as a backup solution. Zmanda is a
commercial entity that sells the Amanda open source backup system.
They're offering a web-based front-end for Amanda, as well as
packaging and most importantly, support. For something that is
"critical infrastructure", its not hard to justify paying for
support... if you have enough infrastructure that you're going to need
support frequently. (How frequent is frequently enough depends on
what you'll tolerate in terms of outages.)
I don't use Amanda, but if I did, I would be using the work someone
else did and all I could give in return is my contribution to the
community. If I used Zmanda, then the relationship is very different.
They have a clearly defined support channel that their customers go
through and their may be a little friction there. I don't want to
hear that I have to file a bug report - I'd rather open a trouble
ticket, upload my log files, and let a level 1 technician write the
bug report and give me the solution. What it comes down to is my
employer can't / won't pay to "support a project" or fit a policy. We
will pay for support to put an upper bound on the amount of time our
staff has to spend working with something.
In the end, Zmanda had a promising product, but there were too many
bugs and their package was just too immature. It was a lot cheaper
than the alternatives we were looking at, maybe when our current
contract is up we'll look at them again.
Burkholder, Peter
> That's not how the model tends to work though. Usually the
> paid community gets the product first with the community
> version lagging behind by a release.
Huh? Not in Red Hat's model:
Fedora -> RHEL
JOPR -> JON
Spacewalk -> Satellite.
The community version leads, not lags.
-Peter
Jason Slagle
Different operating model than the ones I'm thinking of. Things like
zmanda as pointed out where the commercial version will get features or
other items not yet present in the community edition.
Groundwork monitor seems to follow a similiar model.
It's more appropriate to new features, but thats where your bugs tend to
come from.
And you're not exactly right.
Spacewalk was just born from satellite. The open source version lagged by
years.
Similiar story with GFS, directory server, etc. The features went in the
commercial product first. Only later were they opened up. If you
consider them as addons to redhat, it makes the story similiar there.
The "Core" would lag, but the add ons bolted on would lead. Those addons
will be the things with bugs.
Luke has expressed a disinterest in this model though so it's largely
irrelevant.
Luke Kanies
>
>
>
> On Tue, 7 Apr 2009, Burkholder, Peter wrote:
>
>>> That's not how the model tends to work though. Usually the
>>> paid community gets the product first with the community
>>> version lagging behind by a release.
>>
>> Huh? Not in Red Hat's model:
>>
>> Fedora -> RHEL
>> JOPR -> JON
>> Spacewalk -> Satellite.
>>
>> The community version leads, not lags.
>
> Different operating model than the ones I'm thinking of. Things like
> zmanda as pointed out where the commercial version will get features
> or
> other items not yet present in the community edition.
>
> Groundwork monitor seems to follow a similiar model.
I can't speak for zmanda, but IMO Groundwork is more of a horrible
warning than a good example. AFAICT they basically founded the
company as a way to make money from open source without going through
the minor bother of actually writing any.
My understanding is that they've gotten better in recent years, and I
don't know enough about them to be really mean, but if Puppet ever did
have an "enterprise" edition (which is pretty unlikely) it would
always look a lot more like RHEL than, um, the other stuff.
Enterprises like it slow and stable. :)
>
> It's more appropriate to new features, but thats where your bugs
> tend to
> come from.
>
> And you're not exactly right.
>
> Spacewalk was just born from satellite. The open source version
> lagged by
> years.
It's more appropriate to say that Satellite was only recently open-
sourced.
>
> Similiar story with GFS, directory server, etc. The features went
> in the
> commercial product first. Only later were they opened up. If you
> consider them as addons to redhat, it makes the story similiar there.
>
> The "Core" would lag, but the add ons bolted on would lead. Those
> addons
> will be the things with bugs.
>
> Luke has expressed a disinterest in this model though so it's largely
> irrelevant.
I will say, I'm a lot less sure about the future revenue models than I
was when I started.
At this point, I'm mostly interested in clarity, with a much smaller
focus on our long term revenue. I just don't want to make stupid
decisions here that hurt our ability to grow Puppet in the long term.
--
I'm worried about Bart. Today, he's sucking people's blood,
tommorrow he might be smoking. -Marge Simpson
susan baur
> Luke Kanies wrote:
>> Considering how many people have told me they don't buy support
>> because they find Puppet so easy that they just don't need help, I'm
>> not too concerned about this yet.
>
> I think you're getting a false signal from this. I am confident that
> tools in/around Puppet to make a gentle learning curve would make it
> accessible to many times more users. For every 1 person that tells
> you
> this, there could be 10 (100?) who struggle for a few hours to get
> started, hit some of the many caveats, and wander away.
Count me one of the 10 (100?). I for one would try to get my $employer
to buy support. And I'd probably cost you money at first in supporting
me since I'm not a programmer and completely Ruby illiterate. I'm
intrigued by puppet, got a proof of concept instance running, looked
at what I really wanted to do with it and decided I didn't have the
time/bandwidth to figure out ERB and everything else now. Things to
gentle the learning curve would be awesome. Until they exist and/or I
have a nice chunk of time to try to force new knowledge into my poor
brain, I will probably not be moving much past my proof of concept.
--Susan
Andrew Shafer
I don't want to
hear that I have to file a bug report - I'd rather open a trouble
ticket, upload my log files, and let a level 1 technician write the
bug report and give me the solution. What it comes down to is my
employer can't / won't pay to "support a project" or fit a policy. We
will pay for support to put an upper bound on the amount of time our
staff has to spend working with something.
I've been on both sides of this equation many times and my experience has always been that every intermediary in the communication loses/distorts information, so if I really want something to be fixed the best strategy always seemed to be provide the best possible report with clear steps to reproduce the issue.
This is probably a topic for a different thread, but I think it is directly related to why this thread started.
What are your expectations for support? Have you ever had support from Oracle(replace with enterprise software company of your choice)? Did that put an upper bound on the amount of time your staff had to spend working on anything?
I want to explore this topic so Reductive Labs can provide the most valuable support possible by understanding everyone's expectations and motivations.
David Lutterkort
> Different operating model than the ones I'm thinking of. Things like
> zmanda as pointed out where the commercial version will get features or
> other items not yet present in the community edition.
What Red Hat sells, and customers see value in, is stability: stability
from extensive testing, stability from being very deliberate about
updating etc.
> Spacewalk was just born from satellite. The open source version lagged by
> years.
Huh ? When Satellite was open-sourced, Spacewalk _was_ the Satellite
code base. Satellite should also serve as a warning to anybody thinking
about doing something partially closed-source - for example, yum was a
direct response to the fact that the server bits of up2date were closed
source. up2date withered, yum is still around.
David
Simon J Mudd
> I fear this discussion will quickly devolve into a recursive flame-
> fest, but it needs to be broached, so here we go.
...
I'm a little surprised by the problem.
One way to perhaps make things easier is to break puppet into
independent chunks of code that do more clearly defined tasks, but
work together. Publish an interface which states how the components
talk together. Then you can add on extra comercial "functions"
modules which are paid for, or substitute existing "community modules"
with "non-free paid for 'better' versions. As the interface is defined
there's no need to worry about some of the issues you are discussing.
We've seen issues with the standard puppet master's performance.
- A "plug-in" enterprise replacement would be great.
There was talk earlier about push-scheduling of changes (for example
deployment of new software on certain servers during certain
maintenance windows).
- A plugin enterprise module would be great.
You mentioned support contracts
- I guess most of the people who are going to want support are for
initial setup and configuration consultancy, and perhaps solving new
problems as the "puppet installation" grows. If the support people
are good word will spread.
Puppet is currently very ruby centred.
- That's fine but I often wonder if a more generic interface might be
better. If you defined the interface in a language independent manner
then it might allow solutions in other languages to be offered.
So perhaps a different way of looking at the problem is looking at
puppet slightly differently and making it easy to add or replace
components. Also to make sure that the interface to these various
components is able to be expanded reasonably transparently.
Looking at the problem this way doesn't change the licensing concerns
you are expressing but does make them much easier to manage than now.
That might require a lot of initial work, and redesigning in the short term
but potentially would make your life easier in the end.
Simon
Luke Kanies
>
> lu...@madstop.com (Luke Kanies) writes:
>
>> I fear this discussion will quickly devolve into a recursive flame-
>> fest, but it needs to be broached, so here we go.
>
> ...
>
> I'm a little surprised by the problem.
It's really only a problem because no policy has ever been set or
maintained, and people have questions that aren't always clearly
answered by the current situation.
I just wanted to view this lack of policy, and the work we're going to
have to do to rectify it, as an opportunity to pick the best route
forward rather than just picking the easiest one.
>
> One way to perhaps make things easier is to break puppet into
> independent chunks of code that do more clearly defined tasks, but
> work together. Publish an interface which states how the components
> talk together. Then you can add on extra comercial "functions"
> modules which are paid for, or substitute existing "community modules"
> with "non-free paid for 'better' versions. As the interface is defined
> there's no need to worry about some of the issues you are discussing.
> [snipped example external modules]
> So perhaps a different way of looking at the problem is looking at
> puppet slightly differently and making it easy to add or replace
> components. Also to make sure that the interface to these various
> components is able to be expanded reasonably transparently.
That's hopefully something we're much closer to accomplishing with
0.25, but I fear we're still a ways out from transparent module
replacement.
And, actually, this module replacement exacerbates licensing concerns,
rather than obviating them - I can't actually currently publish
commercial modules that interface with Puppet.
>
> Looking at the problem this way doesn't change the licensing concerns
> you are expressing but does make them much easier to manage than now.
>
> That might require a lot of initial work, and redesigning in the
> short term
> but potentially would make your life easier in the end.
I think this is something we can realistically start looking at in
2010, probably - we've got bigger fish to fry right now, but I think
we're going to get more and more interest in replacing subsystems with
external modules, either commercial or just different.
--
The remarkable thing about Shakespeare is that he really is very good,
in spite of all the people who say he is very good. -- Robert Graves