The failed economics of our software commons and what to do about it
pchiusano.github.io
pchiusano.github.io
I'm not sure what the best mechanism is, but making some group pledge on a website probably isn't it. I can't envision that any substantial fraction of people would contribute regardless if other people are helping.
Instead lets restate the problem a little: '$Billions in value is built partially relying on the use of these tools. How do convince the whales that they make money by contributing?'
I wonder if people from the operational side of the house could start this conversation. Business will already do something similar with legacy systems. I.E. Vendor disappears and management finds one of the developers formerly employed at the vendor and cuts them a check for help. When X critical system is at risk everyone gets their checkbook out. We need to connect the operational risk from things like heartbleed with a cost that business people will understand. I like the free software/paid support model, but clearly there could be something better.
I don't think it would take more than a little prodding to make a company like Google contribute to something like that, so long as it's easy.
Actually, you could get the government involved here. There could be a tax break for the first $X of contributions to open source. That would effectively make a public subsidy to OSS, directed by market forces. Pretty cool
Google has some extremely-Google-specific work they want done. Google spins up a project to do it as an external entity, and "donates" the money to make it happen. Google takes that as a tax deduction, and meanwhile the 501c3 gets all the other tax benefits a 501c3 gets (often property tax exemption, for instance).
This is a fair objection, to a point - an organization whose sole purpose is to benefit a for-profit company should probably be paying property tax. I think they take it too far - "Be On Look Out" is appropriate, but it shouldn't mean "no" when projects are genuinely creating value that is broadly accessible.
Your narrower program described above also solves the problem, albeit arguably in a patchier way. The money from Google that would be spent on business expenses anyway wouldn't have been taxed anyway.
I'm not sure what the solution is, but the first step I think is to admit that you've got a problem. Supply chains in the physical goods world aren't a piece of cake by any means, but at least they are predictable. If you make an SSD, you buy flash from Micron and a controller form Marvell, etc. You just buy it. That simple "money for product" transaction allows the incentives to line up. If it was possible to make money selling SSL libraries the same way it's possible to make money selling flash controllers, the world might be a better place.
The way I see it, Google, Amazon, Walmart and others would create a small firm of about 10 people. The central processing system could probably handle real traffic with as little as 20 production servers. All tolled, the company would cost probably 10 mill a year. The benefit is that the founding companies would save in transaction fees their contribution to the new monetary commons. If Amazon didn't lose 3% to credit card purchases, they would save billions a year. At that point what is 10 mill to keep that going? Hell, if I'm off by an order of magnitude, 100 mill a year is still cheaper than the fees.
I like the idea. If something like this caught on, it would give corporations a centralized place to support open source tools they rely on.
I admit I haven't done as much as I could to promote the site, but the initial reception it got was decidedly unenthusiastic. So I'm afraid I've let it rot, and will probably shut it down soon. If you want to take a look: https://bountyoss.com/
Crowdfunding of OSS still seems to me like a problem that must have a solution. I just don't know what it is.
I'd say with 3rd party platforms the solution is marketing. Look at patreon.com that is mentioned in this thread. It grew from Youtube vloggers. These people know how to get attention :)
As a 3rd party FOSS funding platform, you have to provide exceptional quality service and added value. FOSS projects already have their "Donate" pages. You have to convince them and their users that your service is somehow superior. Hence, you need to build a super valuable network of funders through marketing of some kind, be it viral or direct.
Of course, that's.... marketing.
I think a lot of the problem is the idea that MIT/BSD-licensing is the ideal solution because it promotes freedom the most. Clearly, using restrictively licensed components under currently existing restrictive licenses often isn't practical for businesses, but that doesn't mean that having everything be MIT/BSD is the end stage in the evolution of open source licensing.
MIT/BSD-licensing promotes freedom for businesses, but hurts open source developers by requiring them to trust that they can be adequately compensated for their work by a reputation economy that's subordinate to a corporate system that we don't ultimately control.
What if the open source community adopted a norm of dual-licensing open source libraries with the choice of a restrictive non-commercial open source license (basically, AGPL with an added non-commercial restriction) or a license that permits commercial use if you pay?
The key would be that this dual-license would require that any derivative software also be licensed under the same dual-license.
Wouldn't that preserve freedom as in free, while ensuring that open source developers are compensated for their work at levels that ensure and incentivize an optimally robust open source software base?
The devil would be in the details but I bet there's a way to do this that preserves everything that's good about FOSS now and incentivizes better software.
http://www.riverbankcomputing.co.uk/software/pyqt/intro may be a software example, seems to be one developer.
Adopting some complicated dual license sounds like a surefire way to stop people from using software I write, which runs contrary to my goal.
Just a standard GPL+commercial or AGPL+commercial dual-licensing route also works for some companies, without having to add on an explicit "non-commercial" restriction. Depends on the software and the market. MySQL made money doing that for years, for example. Qt also does something like that, although they further enhance the commercial version with closed-source features in the Enterprise tier (another common way of differentiating).
There are basically 3 cases of successful FOSS projects:
1. Ideologically-driven, e.g. Emacs, GNU, etc. These tend to have licenses in the copyleft family
2. Commercially-driven, e.g. WebKit, Docker, etc. These are projects that are strategically important to one or several companies. They tend to have licenses in the MIT/Apache family
3. "Lone Wolf" or "indie developer". While a lot of FOSS is this by volume, what you discover is that by the time projects become popular they have generally evolved into one of the first two types, although they often preserve their creation story as part of the marketing material
The problem with charging money for code is that it's really a bad deal for the first two types. The ideology camp doesn't want non-commercial licenses because it's a "restriction on a field of use" which they have a philosophical objection about that you can google. In the second camp, the corporate masters derive some kind of strategic advantage from having a popular open-source project and charging money necessarily means the project would be less popular and so of less strategic value.
What this necessarily means is that if there's any legs to this plan, positioning it as "open source" or to the "open source community" is exactly the wrong approach, because basically all the people who are successful in that community will find it a nonstarter. Instead you have to hypothesize that there's some completely different set of people that can benefit from this system, writing completely new software (or releasing pre-written software that isn't currently considered 'open source', e.g., proprietary software). So your positioning needs to be something like "proprietary 2.0" or even "third way" rather than being connected with open source.
The real problem with this system is that I'm not sure there's a market on the buying side. Developers are used to getting things for free, and even if somebody wrote a source-visible-but-pay-$1k-to-use-it high-quality TLS library I'm not convinced that people wouldn't just keep wrestling with OpenSSL because it's free.
I have a whole blog post I'm drafting on this topic, if anyone reading this comment is interested, give me a shout and I'll give you a preprint.
As an example, a military is a useful thing to have for protection, but paying for it as some sort of subscription or "per-invasion" billing is obviously not a realistic solution. So we fun it publicly, as a tax, which generally works[1]. Similarly, it might be useful to make a publicly-funded service that is charged with creating software infrastructure such as TLS or even libc that are difficult to fund directly.
There are a few advantages to using public funds: unlike traditional Free Software, as it uses public funds, the output would be public domain, and usable by anybody, commercial uses included. Also, as it doesn't have to worry about VC money drying up or "maximizing shareholder value", it would be easier to stick to a mandate that emphasizes quality instead of time-to-market.
On the other hand, problems with this idea would be the general concerns about corruption due to political meddling, and how to keep the NSA from pulling a BULLRUN on it like they did to NIST.
<speculation> Perhaps a "dept. of software infrastructure" could take over the "defense" side that the NSA seems to be neglecting recently. Moving all industry interaction (and trust) over to the new, open group so the NSA was known as spying-only might improve the relationship a bit... </speculation>
I'm not sure if this is a particularly good solution to the problem, but it's worth considering.
[1] Of course, there are details to argue over and bugs in the system to fix, just like any complicated project.
Regarding "free-riders", consider compatibility and interoperability. Some amount of "free riding" may be desired if it means you don't have to spend as much time and effort making things work together. These benefits may not be as important at the application level, but for infrastructure, these can be very important features.
Moreover, (far) fewer developers would base another complimentary project (open source or commercial) on that new $1K-to-use TLS library, because now their new project would be encumbered by a $1K hurdle that brought them neither revenue nor glory. So, they'd continue to wrestle OpenSSL in order to further the adoption of their own package.
This means that good open source projects almost by definition rely on being produced in someone's free time, or as a side effect of something else (such as Rails), because any company funding something they don't directly use will have some extraction motive which will eventually lead the project into a quagmire.
What's interesting is that you can actually make pledging a dominant strategy, if you find someone willing to put up enough capital. Roughly speaking, dominant assurance contracts work along the lines of "Everyone who pledges will receive X amount of money if the fundraising fails to hit the appropriate threshold." For anyone who would stand to gain from public good, the outcomes are now "Pledge: either the project will be funded or I will get money vs Don't Pledge: either the project will be funded or I will get no money"
It's still interesting, to be sure.
A company has a whole stable full of developers, but if they are all using the average of 8.9 open source "components" in their stacks, really there is a huge software development "organization" that is essential to their business, larger than their paid employee base, that is both absent from the building and outside of their control.
Think about that. Its bad enough when your middle managers don't know how the sausage is made, what about your engineers? And what are you paying the engineers for anyway? And why are they getting paid essentially to put into action stuff that other people wrote? Its a very interesting question for me to think about.
That said, I'd note that I'm a more than a little concerned that it would be done horribly wrong if attempted.
However, there is definitely something to be said for the idea of knowing (at least to some useful degree) how the whole thing works if you're going to rely on it.
Right now I think the industry as a whole is beset with far too much new code and "innovation" for its own sake. An obvious counter would be a radical push for simplicity, but I don't see that happening.
Or even worse, no organization. We're all using a bunch of unmaintained software (e.g. bash) and it never occurred to us to notice that fact.
Isn't that true of almost every tool in a modern economy with division of labour, including something as simple as a pencil[1] that you use to jot down notes?
Nobody goes back to raw materials for all needs, it's simply impossible. There's no reason it should be less so in software.
Many car companies chose to build their own engines, but not all of them do. I'm pretty sure that among those who do, they still don't manufacture all of their own engine components, or even the bolts used to assemble the engine, or the wires used to hook up the engine electronics, and so on.
In some companies, using OSS or even commercial tools that solve problems is frowned on if it seems like a better idea to roll a tool in-house. NIH is huge in many sectors (fighting against this myself at work), and a lot of the same folks who are reluctant to let other people's code into their work are also reluctant to give back to the community from which it came.
In certain places, using OSS is a colossal pain in the neck. Certain enterprise problems are completely unaddressed in various ecosystems, and when they are addressed (say, Ruby's support of Kerberos and LDAP) they are usually just addressing the one or two pain points that that dev had at the time. People are usually not willing to properly solve a problem given limited time and resources.
Even if they are willing to exert effort, many ecosystems can be completely unhelpful and unwilling to give people with domain expertise the support they need to make meaningful contributions. As an example of this, working on a small math library for the new language Elixir, I had at least one person (in an otherwise amazing and friendly IRC channel) continually asking "Wait, why are you doing any type of numerical stuff in Elixir?". Now, imagine that kind of reaction to enterprise features (much harder to get right!) in a different language, and you start to see why things are the way they are.
I don't know if there are any ways of fixing this other than just doing it for the sheer joy of helping other programmers and knowing that, someday somewhere in some ledger, your effort will be rewarded--or at least marked as legacy some other sod has to work around. :)
They are solving their own problems. It is bad enough when people are shoveling snow for everyone else for free, to think they would do it while their car is not stuck would be ludicrous.
In that context, the only incentive that works is compensation for ones labors. If they want Rubys support of authentication protocols to improve, they have to do it themselves, or pledge some money and hope enough companies do it to pay for it to be done.
> imagine that kind of reaction to enterprise features
At least in the context of numericals, I think it is more "dont make a new snowdrift where there isn't one already, and we have already mostly gotten rid of a similar one in the numpy ecosystem". When free software developer resources are already incredibly scarce, them being wasted on project duplication sucks. Albeit, implementing features for certain programming languages is one of the least bad duplicated efforts.
> someday somewhere in some ledger, your effort will be rewarded
The whole point of the article is that being listed in the contributors file is not enough for 99% of developers and the 1% that do volunteer like that are being (voluntarily) exploited for their labor as a result, and software a a whole cannot sustain like that.
Clojure's a nice example: it's been hugely successful, but I have a hard time imagining anyone raising two years' worth of salary up front to work on their idea for an idiosyncratic Lisp implementation. It looks like he had to fund that work himself; how much more innovation would you see if this kind of extended project was common?
I don't see how this could be adapted short of formally contracting software developers for a period of multiple years and forcing the developer to pay a large amount of money should they break the contract early. I don't imagine many top developers would like the restrictions this imposed.
My take: solid idea, terrible name and URL, and also it won't succeed unless some big, respected FOSS names endorse it.
I think it 1) invokes "things piling up", 2) references relevant game theory in two ways, and 3) draws attention to the fact we're organized as a cooperative. All of which seem a good fit for what we're doing.
I think the economics of software commons has been stunningly successful. It's substantially lowered the bar of entry for a large class of businesses and non-profit organisations.
It's great that people are experimenting with financial reward systems that are between free and fully commercial. The more the better as it's not at all obvious which ones will stick. I think it has the propensity to increase the number of people actively involved in this work.
Even better it may open up new types of activity e.g. independent open source software auditing.
But I don't feel that Heartbleed etc demonstrate a systemic failure in economics. The seismic shifting in attitudes to privacy/security that have happened over the last few years appear to be largely orthogonal to the funding models.
Expertise on the administrative aspects of open source also makes me more valuable as an employee, because I can help my employer to consume and contribute to FOSS safely and efficiently. I recommend that anyone with the knack get involved.
Lots of under- and unfunded software is of poor quality and is ignored. Why is some of it (like OpenSSL) not ignored?
I don’t even think there is a market argument here, it’s much more pedestrian: a lot of people, based on social proof, use OpenSSL – which, short of becoming a crypto expert oneself, is entirely reasonable.
The longstanding solution to this problem is government support. This might not be a sexy solution on HN, but it is the obvious one.
Who decides how much the Postgres guys get, or if its worth to support yet another NoSQL store? Involving politics seems like a surefire way into mediocrity. How to get around that?
In your example the new NoSQL store should prove itself before being funded.
Think of all the javascript frameworks appearing nowadays. How many will have a significant user base in 5 years or even still be maintained ?
You should get gov money once you are a reference in your field. Postgres and OpenSSL certainly are.
Obviously the government would create a class of acceptable organizations to donate too, rather than designating a single platform / portal. In this way it would be just like the new crowd equity system.
If there was a way to do so without complicating my tax filings, that would be even better.
Government support works when you can get a majority of the people to agree they want something enough to pay for it. It works less well when the public good primarily serves the interest of a minority. In principle, even if government support was effectively tackling all the things it was appropriate for, there could be room for Snowdrift.coop in coordinating more niche things.
This is why the bigger projects start up complicated 501c organizations, which from my research appear to be quite burdensome to administer and also place restrictions on the project itself as to what circumstances money can be accepted.
I would expect a tax-funded OpenSSL to be developed mostly in secret, in cooperation with the NSA, to be extremely expensive to develop/maintain, and to most definitely have backdoors.
Another way to tackle the problem might be to ensure that people who want to make public software have the time to do so, because that's usually the main limiting factor with any sort of volunteering.
Sure, it could be going faster if someone threw more money at the problem. But right now there are thousands of top-tier developers working on tooling for the rest of us. Intel, Redhat, Apple, Microsoft, Google, and many others pay full time developers to work on important open source projects. Things are looking pretty good, we just need more time.
Also, I contribute to open source because I intensely enjoy it - far more than writing software I was paid to write.
Also you could use with the fact that at the beginning of a campaign, your pledge doesn't have much multiplicative power but doesn't cost you much while at the end it costs you the full amount but you get huge multiplicative power.
Furthermore, I think this is a place where we need outreach to more than coders. This is a good start, but getting donations, and doing all the bookkeeping can be a pain if you're a non-profit. So having accountants willing to sit down with projects and getting things in order so they can set up as a non profit will make companies more willing to donate because they can write it off on their taxes; being a 501(c)3 from the beginning makes that process a lot easier.
Concept: The people who developed the libraries are part of my team. Just like the people who contribute code to my project.
If we look at it that way, it becomes a lot easier to determine how OSS should be funded.
If my project gets a donation from a satisfied user or company, wouldn’t it be morally correct to ‘forward’ a slice of that to some of the libraries which make my project possible ? It wouldn’t just be morally correct, it would be a great satisfaction to be able to share the user’s generosity with them.
In practice a lot of stuff seems to get funded by corporate sponsors or corporations just building stuff and making it open. Examples -
Rust - funded by Mozilla and perhaps the project most likely to lead to better SSL and similar?
Go, V8 etc - Google
OpenSSL - contributed to by Nokia, Huawei and others
Maybe Snowdrift can do better? Maybe not?
It is our ideas and virtues that have to change.
It's likely to work better for existing projects that need extra work, though, because it's not going to be easy to get people involved in something that doesn't even exist as a proof of concept.
I think in most cases technical talent that would care about these underlying issues would rather try to become open source developers themselves.
The crucial difference is sensitivity to ROI.
When not paid, every hour spent programming is an hour not spent with your family, not spent attending to your hobbies, not spent resting or sleeping. Thus you do your best to keep everything as lean as possible.
When being paid, keeping things lean is still a nice idea, but you don't care that much any more. After all, you are going to spend same amount of hours on the project whether you keep it lean or not.
A better solution for me would be to make the process of becoming a 501(c)3 much easier, so parties can donate easier, and tax-free. I've spoken to a few people who have gone through the process, and it is rather a pain in the butt to get all the requisite paperwork in place, especially if you're just starting out. Making that part easier would in effect do the same thing as fund with tax revenues, while working within the unfortunately byzantine tax system.
If you need funding for a project, go commercial or have a commercial counterpart. The market will decide which ones get funded and which ones don't.