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.
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 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.
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.
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 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?
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.
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).
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.
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?
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.
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.
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.
[+] [-] johngalt|11 years ago|reply
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.
[+] [-] rayiner|11 years ago|reply
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.
[+] [-] jerf|11 years ago|reply
[+] [-] dageshi|11 years ago|reply
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.
[+] [-] ScottBurson|11 years ago|reply
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.
[+] [-] mwhite|11 years ago|reply
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.
[+] [-] drewcrawford|11 years ago|reply
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.
[+] [-] burntsushi|11 years ago|reply
Adopting some complicated dual license sounds like a surefire way to stop people from using software I write, which runs contrary to my goal.
[+] [-] _delirium|11 years ago|reply
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).
[+] [-] walterbell|11 years ago|reply
http://www.riverbankcomputing.co.uk/software/pyqt/intro may be a software example, seems to be one developer.
[+] [-] fidotron|11 years ago|reply
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.
[+] [-] walterbell|11 years ago|reply
[+] [-] dllthomas|11 years ago|reply
[+] [-] Totient|11 years ago|reply
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"
http://mason.gmu.edu/~atabarro/PrivateProvision.pdf
[+] [-] dllthomas|11 years ago|reply
It's still interesting, to be sure.
[+] [-] walterbell|11 years ago|reply
[+] [-] ChuckMcM|11 years ago|reply
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.
[+] [-] carapace|11 years ago|reply
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.
[+] [-] cubix|11 years ago|reply
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?
[1] http://en.wikipedia.org/wiki/I,_Pencil
[+] [-] unwind|11 years ago|reply
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.
[+] [-] wmf|11 years ago|reply
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.
[+] [-] lotyrin|11 years ago|reply
[+] [-] sbov|11 years ago|reply
[+] [-] angersock|11 years ago|reply
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. :)
[+] [-] zanny|11 years ago|reply
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.
[+] [-] bkirwi|11 years ago|reply
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?
[+] [-] tree_of_item|11 years ago|reply
[+] [-] john_b|11 years ago|reply
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.
[+] [-] javajosh|11 years ago|reply
My take: solid idea, terrible name and URL, and also it won't succeed unless some big, respected FOSS names endorse it.
[+] [-] dllthomas|11 years ago|reply
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.
[+] [-] quadrangle|11 years ago|reply
[+] [-] lucozade|11 years ago|reply
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.
[+] [-] rectang|11 years ago|reply
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.
[+] [-] mwsherman|11 years ago|reply
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.
[+] [-] thmcmahon|11 years ago|reply
The longstanding solution to this problem is government support. This might not be a sexy solution on HN, but it is the obvious one.
[+] [-] gargantian|11 years ago|reply
[+] [-] dllthomas|11 years ago|reply
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.
[+] [-] MrBuddyCasino|11 years ago|reply
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?
[+] [-] quadrangle|11 years ago|reply
[+] [-] zzzeek|11 years ago|reply
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.
[+] [-] motters|11 years ago|reply
[+] [-] gargantian|11 years ago|reply
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.
[+] [-] quadrangle|11 years ago|reply
[+] [-] oofabz|11 years ago|reply
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.
[+] [-] WalterBright|11 years ago|reply
Also, I contribute to open source because I intensely enjoy it - far more than writing software I was paid to write.
[+] [-] unknown|11 years ago|reply
[deleted]
[+] [-] BenoitEssiambre|11 years ago|reply
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.
[+] [-] phillmv|11 years ago|reply
[+] [-] ssivark|11 years ago|reply
[+] [-] Sanddancer|11 years ago|reply
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.