[bcantrill]

But here's the deal: for someone like AWS who isn't giving back, the choice is not "do they give back or don't they?" -- it's "do they run your software or someone else's?" So: do you want to grow the ecosystem around your software or not? Do you want AWS to at least create a market for people who understand your software? Do you want at least the intrinsic satisfaction that your software is being used in an important capacity, even if it doesn't mean immediate remuneration? Finally, if AWS runs your software and it becomes core to their business, there is a non-zero probability that they will contribute something tangible in the limit -- if they do not run it, there is, in fact, zero probability of such contributions. It's not dissimilar to the arguments around open sourcing otherwise proprietary software[1]: you need to get out of "what will this buy me?" and into "what does this cost me?"

[1] http://www.slideshare.net/bcantrill/corporate-open-source-an...

[falcolas]

> there is a non-zero probability that they will contribute something tangible in the limit

I wouldn't hold my breath for that, frankly. My experience in working for a few large companies has shown that they actively discourage contributions, since it opens the doors for lawsuits (frivolous or not), further contribution and maintenance expectations. To them, the cost is not worth the benefits.

There are, of course, the exceptions to this rule - but that's all they are, exceptions.

For one great example, look at the plight of OpenSSL. Before it broke way open, how many companies really contributed to it? And how many just used it, not giving a second thought to using it unless there was a CVE?

[boomboomsubban]

>For one great example, look at the plight of OpenSSL. Before it broke way open, how many companies really contributed to it? And how many just used it, not giving a second thought to using it unless there was a CVE?

So you think there were a large number of companies privately fixing bugs in OpenSSL? Or how would a less permissive license forced companies to contribute to a project they weren't actively improving?

And on your earlier points, keeping changes private likely requires more future contribution and maintenance expectations

[JoshTriplett]

> But here's the deal: for someone like AWS who isn't giving back, the choice is not "do they give back or don't they?" -- it's "do they run your software or someone else's?"

That assumes 1) the other software exists (GPL/AGPL has much more effect for software without viable competitors), 2) the license causes more of a problem than switching does, 3) you don't sell an alternative license that costs less than switching does.

[drewcrawford]

> So: do you want to grow the ecosystem around your software or not?

In short: of course not. Or at least "not at any cost".

Open source projects do loads of things that reduce the potential ecosystem. People choose to work on projects that aren't web browsers, for example. Or they choose languages that aren't the #1 most popular. They target a platform that has less than 50% marketshare. All of those things turn away potential users in exchange for authorial convenience of some form or another.

It is a foreign concept to me to write e.g. a developer tool for a minority environment and then all of a sudden worry about the license being some major barrier.

But more broadly your position is very strange to me in its wider implications. Let us say that some voice actor could donate some spare reel to Disney. Or that some author could donate a manuscript to Penguin. Or that some musician could donate their track to Sony. Do you believe they should do so, under the theory that this in some way "grows the ecosystem" for their work?

[jdmichal]

Artists "give away" things all the time to increase mindshare. If nothing else, they typically give or show copies to influential reviewers.

[notacoward]

How much is that "market for people who understand your software" worth? Sometimes those people are your competitors, using your own code plus local improvements (or "improvements") to sell against you. It's not as simple as saying you'll always win or you'll always lose. There are both opportunities and risks, which have to be weighed on a case by case basis. I've seen my own code sold against me too many times to believe permissive licensing is always the right answer.