To paraphrase the problem: 'Lots of people are relying on volunteer created code running for free. How do we fund the development of useful tools and software collectively?'
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.
The basic difficulty inherent in monetizing digital goods is affecting all reaches of the software industry, in a bad way. From websites being forced to rely on advertising to system software developers being forced to rely on donations or patronage--the digital goods economy is here, and frankly it's pretty disappointing.
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.
Honestly I think the answer is micropayments. Large companies should get together to fund the creation and running of a centralized payment system with no fees. They could move tiny sums of money around to developers. Apps could charge $0.05/month to $1/month to monetize themselves. The user would be given a trial period and then asked to pay.
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.
That's basically what the author is pushing. Snowdrift.coop[1] is a platform for making small payments to open source projects, with the additional twist of a matching donation mechanism. It's like Patreon with a twist. They plan to fun the platform as a project on the platform, rather than charging a percentage of each transaction like KickStarter does.
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.
You might want to take a quick cruise around http://patreon.com . It may shake your confidence in that pronouncement. I'm a patron for far fluffier things right now.
The answer I think is "make it simple". Create some central clearinghouse/website the business side of these big companies can give a check too, in return they get an account, the techies/programmers from the company use said account to fill in what technologies/projects they're using, the cash gets distributed between said projects, the clearing house handles all that.
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.
I don't really think that Google's problem is the inconvenience of having to cut a bunch of checks to the people they want to support, as if they were desperately short of people with administrative skills.
Spot on. It’s the same as the Apple/iTunes micropayment model. I buy lots of little things from Apple because I don’t have to go through payment process each time.
Companies often want strategic influence on OSS software, as well as maintenance. This would be difficult to run through a clearinghouse. When a project is larger, it can be part of an existing OSS foundation, where there is more experience with arbitrating such conflicts between donors.
Big donors, yes. But firms with this motivation are already involved. I think the problem is how to engage the long tail of small / medium firms that rely on OSS but aren't sufficiently engaged to try to shape them.
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
FLOSS currently gets extra scrutiny ("BOLO", which usually means "no") when applying for 501c3 status. The reasoning is to avoid a situation like the following:
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 built a site for crowdfunding of OSS based on these two observations: (a) businesses have the most money to spend (as you point out), and (b) most money spent on software development goes toward maintenance and continued development of existing systems.
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.
> 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.
I found Patreon when artists I liked announced their participation. The marketing can simply be "hey <big OSS project>, make a profile and put a banner on your site!"
An alternative solution could be to innovate in licenses.
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.
Having spent some time on the problem I agree generally with your approach, but the problem is it doesn't appreciate the history and context in which the current system has arisen and continues to exist.
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.
This kind of situation where there is a common need for something, but there isn't a reasonable way to pay for it in individual transactions has a traditional solution: make the project publicly funded.
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.
There's a free-rider problem if the funding is from a national funding body. Since software is generally useful globally, the funding body would have to be international.
Some sort of international version would be a good idea, if some reasonable plan could be created.
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.
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.
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.
I realease all of my open source work under copyfree licenses and I've never heen "hurt" by it. I don't have to trust anyone---I write code that solves problems of interest to me and I put it out there for others to use if they want to.
Adopting some complicated dual license sounds like a surefire way to stop people from using software I write, which runs contrary to my goal.
That's a fairly traditional approach for academic software: source made available but under a non-commercial/research-purposes style license, and a commercial license sold for commercial uses. It's been successful in some cases, mainly when active effort is made to sell the commercial product (e.g. through a spinoff company).
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).
The mission of Snowdrift.coop, the site mentioned in the original article is to fund things specifically without relying on artificial restrictions like proprietary licensing.
The bigger problem is open source software as a business model incentivises making the software over complicated, as if it just worked properly there would be no need for value added services. This is what lies at the core of the Docker/Rocket fiasco. (And possibly systemd too).
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.
That's true of current open-source business models, but is a part of what Snowdrift.coop hopes to assuage. It's money for improving the product, from a community who wants to see the product improved.
Looks like a system to setup up assurance contracts for funding software. Glad to see more people trying to make this sort of thing work.
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"
I think this is a badly needed capability. But the SSL bug (which is highlighted) and the Netflix bug, really brought home an interesting question, "Who is writing your software?"
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.
At this point it would be pretty difficult NOT to rely on enormous stacks of other people's software, from OS's to compiler/interpreter runtimes et. al., library code, frameworks, etc.
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.
> why are they getting paid essentially to put into action stuff that other people wrote
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?
I may not know how to make a pencil, but I know precisely how a pencil works. I can be reasonably confident that it is not going to start writing in ink one day, because an upstream maintainer thought it would be a cool feature.
But that "problem" has to be equally true in any field of engineering you can care to mention.
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.
I was under the impression that bash is maintained. The internets suggest currently by Chet Ramey, and it looks like there have been tens of patches this year.
Yeah. I hope software management gets less comfortable with these answers and put their money toward real sustainability such that we see the commercial sides of FOSS projects grow in quality and quantity, with sustainable business models around sponsored features, bug bounties, support engagement, etc. and no need to stoop to licensing the software itself for money (neither restrictively free/commercial dual licenses or enterprise/community feature splits).
One thing that might be able to help is to improve the incentives around security. If some more liability for misuse of systems fell on those who deployed those systems, then people would push harder for quality or pay for indemnification, and either way that puts more dollars toward stability.
That said, I'd note that I'm a more than a little concerned that it would be done horribly wrong if attempted.
How far down the stack are you willing to go? Firmware? Hardware? Hardware components? Processing of natural resources required to create those hardware components? Methods for extracting natural resources? The geological reasons why those natural resources occurred in the first place?
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. :)
> People are usually not willing to properly solve a problem given limited time and resources.
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.
It always seemed to me like the academic-style sabbatical was a nice solution to this. Instead of trying to convince a bunch of people that what you're going to do is going to be worthwhile, you develop a culture where capable people are regularly given time to work on whatever they think is important.
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?
An academic-style sabbatical would not work in the current software development ecosystem because, unlike tenured professors, top software developers cannot be trusted to stay with the same organization after the sabbatical. Universities can get away with this because a tenured professor has already contributed a lot of value to the university (a requirement for getting tenure) and can be trusted to return.
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.
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.
I find it rewarding to volunteer at one of the big open source software foundations because the time I put in working on project governance, licensing, policy and so on ripples out through hundreds of projects and into the broader FOSS ecosystem. We're way better at what we do than we were even a few years ago, and one result is that there are far more people getting paid to work on FOSS.
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.
The software commons has succeeded for upstream / backend software for things that end up as user-subjugating proprietary downstream products. The economics are very poor in terms of providing freedom and openness to the best general-public software. In other words, today's business model still relies and obnoxious ads and artificial restrictions at the end of the day.
Asking why popular software isn’t well funded is backwards. The question is, why is underfunded software popular?
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.
This is the same economic problem that affects basic research. Open source software is a 'public good' - its usefulness is not diminished when it is used by others, and you can't prevent others from using it.
The longstanding solution to this problem is government support. This might not be a sexy solution on HN, but it is the obvious one.
Unfortunately, while government can mostly wrap its head around science though consultation with academia, the state of the art of software is so ethereal and moves so fast that I imagine seeking funding for software will be even more of a farce than it is in the sciences.
Incidentally, Snowdrift.coop is happy to have projects doing scientific research. The basic criteria are that 1) the project is producing some non-rival good, and 2) that good will be made freely available under an appropriate license (which basically boils down to the equivalent of one of CC0, CC-BY, or CC-BY-SA).
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.
I agree it would make sense, but is the real problem not how to allocate that money?
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?
Maybe the government could provide the funding as a Tax Credit for donations to platforms like snowdrift.coop, just like donating to other non-profits works. Companies / Individuals would make their own decisions about what to support, and the government would foot the bill through them.
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.
It's tough for companies to fund individual open source developers using "contribution" kinds of models, because now they are essentially paying someone for services in such a way that is entirely outside the bounds of the usual employment agreements, either at-will, full time employment or via a contractor agreement. It opens them up for a variety of legal liabilities.
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.
A thought occurs to me that maybe public software could be funded by the public, via taxation. I don't think that would be any kind of panacea, because you can see what happens with other publicly funded things, but it's worth consideration - especially if public software is considered vital to the rest of the economy.
Great idea in theory, but as you fear I think this would quickly be bastardized into more private military-industrial complex funding.
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.
Yes, I think you're right. It is probably better for most public software to be independently produced, outside of the context of companies or governments.
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.
You could think of the proposal behind Snowdrift.coop as being the closest we could get to effect purely-voluntary taxation… Of course, if we had better real democracy to set better tax law, well…
I don't believe we have failed. We have simply not yet succeeded. It's not like things used to be great, and then got screwed up. The tools and libraries we have now are so much better than they were ten years ago, and infinitely better than they were twenty years ago. We have been making steady progress and will continue to do so.
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.
Indeed, and everyone thanks you for it, but others enjoy freeriding. I think the actual game-theory is clearly simplistic. You could think of it more as being at home and having work to do rather than go shovel, so it costs you in other ways. It's not just shovel or be passive and wait.
This is cool. You can then phrase your plea for donations as something like: "Every 10 dollars you pledge makes others give us up to $100, your donation has 10x power!"
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.
I think this is the beginning of an interesting idea, however, the specific funding aspect seems like we could end up with the same dilemma, where people fund flashiness instead of the boring infrastructure projects. I'd rather see effort made for a sort of United Way for open source, where you give money, and their accountants audit projects, and give to groups based on need and value to the community.
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.
Most software that we write depends on one or more 'free' libraries that we embed into our projects (eg. express.js, libopenssl, CocoaLumberjack or jquery).
Maybe your project is impossible without a certain library or maybe it saved you weeks or months of work.
The fact is, we build on the work of others, who give it away for free. They make our ideas possible.
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.
Snowdrift.coop is an interesting idea but I'm not sure how well it would work in practice. If you consider his example of improving on open SSL I guess you'd get a bunch of companies saying we'll chip in say $10k as long as other companies do too. Then assuming that happens you'd have a
money to pay some developers but that might not actually result in a better SSL. Just raising money does not necessarily produce good software.
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
Ongoing donations helps with accountability. But otherwise, funding isn't a guarantee or anything. But if you look at where good software is, really good and robust, you don't find it from totally underfunded projects. Mozilla is way better funded than most other free/open software.
I don't think libre or open source is broken. I think some projects are broken. I think other projects are those people simply don't like, don't want to fund, and have to use because there are no other options. With some creativity and planning, open source projects can be self-sustaining, but they have about the same success rate as any other startup. The upside is that all progress doesn't evaporate when an open source project fails, it gets forked or consultants can transition people to new tools.
If our society values sharing and condemn selfish behavior everything would be ok. But at the moment our neo liberalism capitalism values none cooperative egoists.
One step at a time. Showing people that others also care is huge. It's easy when isolated to feel helpless. Big corporate multinationals are all connected and have strong business ties and networks and work to actively divide consumers so that we just choose what to buy when we go to the big box store or surf Amazon etc. That's why cooperatives are so important, and we need more of them on a large scale on the internet.
IMO the problem isn't that there are less resources dedicated to open source stuff than to commercial projects. The problem is that there is much less effort and especially polish dedicated to any not user facing aspescts of software. Internal libraries are almost certainly even more half-baked and full of shitty code than most open source projects.
Ideas like this have been around for a while, but never seemed to take off. Maybe in the era of kickstarter and similar things, it's more likely to succeed.
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 don't think I've ever read an opinion piece where I so completely disagree with every single point made or believed the author has completely inversely represented the reality he is trying to change. Interesting. Perhaps when I get home I shall expound on it.
It all depends on how you define "efficient." Vague proclamations about the market like this often hold utility in narrow contexts, but abstracted as a general rule rely on circular reasoning.
The social benefits from free software are positive externalities and thus not naturally dealt with by the free market. Compare with the negative externalities of air pollution, for example.
I don't think it's quadratic for individuals. Individuals give (base + incr * other_pledgers)... the total donated grows "quadratically", but for the pledgers it's just linear growth based on the number of other donators. Since pledges are bounded per-user, it's subquadratic as the project starts hitting the pledge limits of their users. (Which makes sense since of course all the accounts have to balance and users aren't going to be willing to write blank checks.)
Open source isn't entirely a labor of love, there are people that do get paid for their open source development. Unless you're ready to back up your claim with analysis of contribution quality based on employment status I could just as easily point to different properties of the open-source model as the driving factor.
No, I don't have statistical data, but I've experienced both sides in person.
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.
That becomes a very sticky situation very quickly. What sort of entity would qualify for such money? Would Microsoft qualify for some money for their various open source projects, like F#, or the newly opened .net projects? Would Oracle qualify for MySQL and BerkeleyDB, when they offer a closed-source version for those that can't abide by the open source copyrights?
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.
I disagree with this. There are only a handful of OSS projects that are acceptable and I don't trust anyone in government to make a decision on which ones to fund with my tax dollars.
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.
Academic research is funded through taxpayer money, and, as an academic, I can assure you that much of it has a much lower impact than many open source projects.
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.