Open Source Sustainability is Really a People Problem (infoworld.com) 58
Matt Asay, a former COO of Canonical now working at AWS, argues that the question of open source sustainability "is really a people problem."
But to make the case, he cites comments by Tobie Langel, formerly W3C's testing lead (and a former member of Facebook's Open Source and Web Standards Team) who's now founded an open-source strategies consulting firm whose clients include Mozilla, Intell, Google, and Microsoft. Much of the "open source sustainability" discussion has focused on the one thing that really needs no help being sustained: software. As Tobie Langel rightly points out, "Open source code isn't a scarce resource. It's the exact opposite, actually: It's infinitely reproducible at zero cost to the user and to the ecosystem." Nor is sustainability really a matter of funding, though this gets closer to the truth.
No, open source sustainability is really a people problem. Or, as Langel highlights, "In open source, the maintainers working on the source code are the scarce resource that needs to be protected and nurtured."
Over the past several weeks, I've interviewed a number of maintainers for popular open source projects. In every case, they talked about how they contribute because it's fun, but also acknowledged that some aspects of open source development can make it decidedly "un-fun" (e.g., demanding users who complain about missing features or existing bugs but don't contribute code or fixes). Most have found ways to turn their passion into financial independence, but Langel stresses that cash is critical to keeping open source humming along... "Without revenue, there is no maintenance, and without maintenance, the commons becomes toxic very quickly... As new security issues are discovered, open source code that isn't updated becomes a security risk..."
Langel is absolutely correct to argue, "In an ecosystem with infinite resources, the attention needs to be on the people taking care of and maintaining that resource, because that's where the bottleneck is." Again, that's partly a question of money, but it's even more a question of treating people with dignity and respect, while making open source communities a fun, welcoming place.
But to make the case, he cites comments by Tobie Langel, formerly W3C's testing lead (and a former member of Facebook's Open Source and Web Standards Team) who's now founded an open-source strategies consulting firm whose clients include Mozilla, Intell, Google, and Microsoft. Much of the "open source sustainability" discussion has focused on the one thing that really needs no help being sustained: software. As Tobie Langel rightly points out, "Open source code isn't a scarce resource. It's the exact opposite, actually: It's infinitely reproducible at zero cost to the user and to the ecosystem." Nor is sustainability really a matter of funding, though this gets closer to the truth.
No, open source sustainability is really a people problem. Or, as Langel highlights, "In open source, the maintainers working on the source code are the scarce resource that needs to be protected and nurtured."
Over the past several weeks, I've interviewed a number of maintainers for popular open source projects. In every case, they talked about how they contribute because it's fun, but also acknowledged that some aspects of open source development can make it decidedly "un-fun" (e.g., demanding users who complain about missing features or existing bugs but don't contribute code or fixes). Most have found ways to turn their passion into financial independence, but Langel stresses that cash is critical to keeping open source humming along... "Without revenue, there is no maintenance, and without maintenance, the commons becomes toxic very quickly... As new security issues are discovered, open source code that isn't updated becomes a security risk..."
Langel is absolutely correct to argue, "In an ecosystem with infinite resources, the attention needs to be on the people taking care of and maintaining that resource, because that's where the bottleneck is." Again, that's partly a question of money, but it's even more a question of treating people with dignity and respect, while making open source communities a fun, welcoming place.
No shit, Sherlock. (Score:2)
Beyond "I have this problem and I'm going to solve it with a program I write" maintaining quality FOSS requires sustained quality work. Maybe not much, but regularly. It should be possible to sustain financing of a FOSS project by its users by some universal subscription system. I make my money programming in PHP. I should be able to get a membership in the official "PHP society" or something, with reduced prices for quality certification, docs and training with that money going directly to maintaining PHP.
Re: (Score:3)
Re: No shit, Sherlock. (Score:2)
Tidelift (https://tidelift.com/) is trying something like this.
Which link (Score:3)
Would it be so hard to write "In this article Matt Asay" with "this article" being the link?
Re:Which link (Score:4, Funny)
The money problem (Score:5, Interesting)
I said this before and I'll say it again. If an open-source software struggles with funding, they need to learn lessons from the Blender foundation. I didn't spend more money on software than I did on Blender, a free application. Why? They have a lot of creative ways of asking for money. They created open-movies which people can fund and get credit for at the end of the film. They sold usb-sticks with an extra margin that funds development. They sell merch. They have the Blender cloud subscription service which connects you with professionals. Now they have the development fund system, and they're very open with how the money is spent and which features will be funded. I can go on and on, but the vast majority of open-source software foundations don't make an effort to attract money beyond the Donate button.
I, and I imagine many others, love the idea of funding free software. You're paying an entity for the betterment of everyone who makes use of the software, even students or people in poor countries who can't possible afford big megacorp-backed software. I just wish they at least make an effort to ask for it. How will the money be used? Which developer will be willing to work on that specific feature I want when they're funded? How much does the open-source foundation needs to hire a full-time developer? How about sell merch, printed guides or training DVDs? Do something other than the Donate button please, and I will be the first person to contribute.
Re:The money problem (Score:5, Insightful)
The problem lies between the big projects like Blender that can generate decent income and the small hobby projects. Software in that zone needs more time than many people can donate to it but also isn't popular enough to fund someone working on it full time.
Since most people can't tell their employer they want to work 4 days a week so on the 5th day they can work on something else it's all-or-nothing, they either need to raise enough to pay a full salary or they money won't really help.
Re:The money problem (Score:5, Insightful)
This is very much on point.
For the small-time open source developer (like myself), donations aren't actually useful. I already have a well-paid full-time job. I'm not short of money, but I am short on free time. The money can't create extra personal time for me. Until you get to the point where you could hire another developer on a part-time or contractual basis, that's a big gap to cross. I'm not going to start working part-time just to contribute to free software projects, I'm afraid.
The other part I question is where the donation money gets spent, and how donations are requested. Asking for donations to a project is easy, but it's also really lazy. Like Blender has done, it's better to actually provide a real value-add and get people to pay money in exchange for tangible products or outcomes, but it requires inventiveness and effort. Many of us wouldn't have the time to set all that up, let alone deliver it. On top of that, many big projects collect lots of money and then squander it on pointless stuff. Look at what GNOME, Debian and other big projects do with their accumulated assets. A lot gets wasted on community outreach, conference travel and other activities which don't directly produce value for their userbase. Not that these things are "bad", but free jollies to international conferences could have paid for several full time staff, and the conferences could all have been done by videoconferencing. There is of course value in personal meetings; I'm just questioning whether it's the best use of money if other things might have delivered more value.
Re:The money problem (Score:4, Interesting)
I actually refuse donations because when it's just someone giving me a tenner they often seem to expect a lot, e.g they want me to work on features they want it provide tech support.
Re: (Score:2)
I actually refuse donations because when it's just someone giving me a tenner they often seem to expect a lot, e.g they want me to work on features they want it provide tech support.
Exactly. Donate translates to "I paid for this software so I expect support" in many people's minds.
Re: (Score:2)
Well, why wouldn't paying for something mean "I expect support"?
Re: The money problem (Score:1)
Because it's described as a donation. Donations do not create an expectation of improved service. I don't expect a soup kitchen to bring me catered food after I donate.
Re: (Score:3)
Because if you donate a tenner, that's used up in the time taken to read the subject line of the support email you just sent.
If you want support you need to pay a multiple of a developer's hourly rate, just like any other consulting system.
Re: (Score:2)
Re: (Score:2)
Actually in reality, it is a government problem. Governments are too cough cough corruptly stupid to invest in the local development of open source software to save on thrown away licence fees, yeah they are being stupid on purpose because of corruption.
The greater the number of closed source proprietary software licences a government pays for, the greater the incentive should be to invest in open source software, it is straight up the logical thing to do. They defy logic and make the stupid choice because
Re: (Score:2)
Re: (Score:2)
The thing with Blender though, is its what the kids now call a "content creation" tool. So its perfectly suited to being able to value add that free product with things like 3D assets, premade materials, and the like.
If the open source product is something less glamorous like a DNS server or some sort of database utility, then theres distinctly less opportubuties to value add
Re: (Score:1)
Re: (Score:1)
I am going to reply to this just to formulate my thoughts on this subject. I run a company, it is growing and turning a profit but before it could grow and before it turned a profit it took a number of years (over 5 years actually) when it was paying the bare minimum to cover some of the bills and before those 5 years it was 3-4 years when I was just coding and there was no income at all. Over these years I tried my solutions in a number of fields, mostly retail and logistics of some sort (shipping for ex
Any moron can write code (Score:2)
The exceptional ones provide support and updates after the fact. Projects like Calibre or Kodi come to mind.
If people aren't willing to pay, (yeah I'm the cheapest bastard on the Internet, but I still manage to toss some money at worthwhile projects) then you'll get what you pay for.
where have I seen this before? (Score:3)
So, like Slashdot then?
Matt Asay, much talking, not much doing (Score:2)
I met the guy circa 2000 in a certain embedded Linux company in Utah he joined a few years after I did. He was the archetypcal useless company officer: high salary and not much added value.
I see not much has changed.
Subtitle (Score:5, Insightful)
In case you overlooked it (and because it's not clickable):
xkcd.com/2347/ [xkcd.com]
Re: (Score:1)
Arghh.. I myself overlooked that 1st link in the summary was to xkcd, not to an actual article. Stupid me (or perhaps: stupid editor of the summary?).
Re: (Score:2)
NTP springs to mind. Considering its basically one guy it's crazy that we don't just fund it as critical infrastructure. The EU could adopt it though CERN or something, they already have Kicad and a load of other open source stuff.
Maintainers are problems, too (Score:2, Informative)
I've contributed bug-fixes and features to several projects over the years and the experience as a contributor is quite variable. Some projects, like Marlin, accept contributions gladly and the maintainer is happy to help you fix things or even fix them himself before merging in. Other projects, like Mozilla's Firefox, are a bunch of drama queens and often shoot down contributors for daring to fin
Re: (Score:3)
I've contributed bug-fixes and features to several projects over the years and the experience as a contributor is quite variable. Some projects, like Marlin, accept contributions gladly and the maintainer is happy to help you fix things or even fix them himself before merging in. Other projects, like Mozilla's Firefox, are a bunch of drama queens and often shoot down contributors for daring to find fault with their golden tower.
I've encountered similar: maintainers who will be happy for the change, agree with it's usefulness, then reject it on the grounds of not following their unique process precisely, spending 3+ days learning and tweaking things for their submission process, then giving up and letting a pull request stay open forever because the maintainer is playing low level manager hack instead of writing or maintaining software.
More of a "system problem" than a "people problem" (Score:4, Interesting)
Open source software is evidence that the principle "from each according to their abilities, to each according to their needs" works – at least in the software sector, even if just to some extent. People make use of what they need, and they contribute what they feel inclined to contribute, without the detour over a "market" for either direction. Great stuff came into existence that way, and great stuff continues to be created that way.
The problem is that contributing to open source doesn't earn people's living, except for the very few for which it does. Because the rest of the economy is not run by that principle. People usually still have to work full-time to earn their living beside everything they do to contribute to open source. Which makes their contributions even more valuable and honorable than the sheer value of their contributed lines of code or even the importance of the projects they're working on would suggest. Their contributions are nothing that could really be expected from them. They would be fully entitled to do nothing at all, or anything else, with the limited time they have; after all, gainful work usually takes up the largest part of our awake lifetime until we can retire. That they do contribute is the exception, not the rule. And thanking those who do more often and making open source communities a welcoming place, while of course a good idea, won't change that.
For things to change, said principle would need to be implemented for everything, most importantly the things we need for our living. The principles of open source would need to be applied to the physical world, worldwide. There are already quite thoroughly thought-through concepts for this which transfer the concept of "peer production" on the physical world and extend it to replace the current economy. It is possible that only a few absolutely necessary things would remain without enough people volunteering for them, and just a few hours per week for everyone – at most – should be enough to get them done.
And I guess it's not just the future of open source software that would make such a transition a good thing.
Well.. (Score:2)
One argument people use when talking about open source is that it's free. I guess it's a bit hard to convince people to donate money (specially periodically) when the main reason they started to use those applications is that they are free.
Dependability (Score:3)
Suppose you are maintaining your own little open source or free software project. Dependencies can be a real problem. Other projects you depend on may suddenly become unmaintained, or the few maintainers those projects have are too busy with other things. You report a bug to them and it gets ignored. You fix the bug yourself, and the pull request or patch you provide just sits there collecting dust. Some library you use may one day deprecate or drop some functionality that you really need. Or they may decide to make some source incompatible changes to their API. This happens all the time.
This is why I try to keep dependencies to a minimum.
One example: TagLib. So many projects depend on that, but it doesn't seem to have an active maintainer right now. Its last release was almost 4 years ago, and it has collected lots of unreleased changes since. But there is no one to actually make a release. Last commit was 5 months ago. And it has 20 pull requests waiting to get merged.
There is no easy solution for this. People are busy. Maintaining a project can be a thankless job. People need to get food on the table, and maintaining an open source project in your free time does not do that. Working on an open source project can be fun, but it also has its boring parts. And life can get in the way of things.
So I agree that it is a people problem.
leon bmabrick still applies (Score:1)
if you line up 10 developers probably 8 of them will vote to add a dependency in order to accomplish some feature add request.
very few people understand in order to stay an actually working, usable product, that doesnt have show stopping bugs, you have to resist this desire to add dependencies. because the most important feature is 'does it actually work or not'. i.e. simplicity and dependability are features in and of themselves which can only be gotten by refusing to add complexity.
especially when depden
The bug reports drive you fucking crazy. (Score:2)
Title: URGENT!
Body: I have an urgent issue with your product that only happens when I wear a sweater to Yankee Stadium. I need this fixed ASAP!
Re: (Score:2)
Digny and Respect? No. (Score:4, Interesting)
Re: Digny and Respect? No. (Score:1)
Re: (Score:2)
I believe GPL was mean to address part of this problem (the exploitation aspect). At least with GPL you know companies aren't profiting off of your code without contributing back (unless they're unethical)
Pro tip: they all are.
Re: Digny and Respect? No. (Score:2)
Open source is the recognition that software is meant to serve a purpose. There's no reason for two companies to make two libraries that do the same thing. Most software is written by companies who are not in the software industry. There's no reason for every company to re-invent the wheel.
Re: (Score:2)
Open source is the recognition that software is meant to serve a purpose. There's no reason for two companies to make two libraries that do the same thing. Most software is written by companies who are not in the software industry. There's no reason for every company to re-invent the wheel.
Absolutely false. There are lots of reasons to have two libraries doing the same thing, ranging from implementation methods on different hardware to antithetical design paradigms which always tend to cascade downstream to developers utilizing those libraries. Similarly, for licensing issues there's absolutely a reason to re-invent the wheel from a legal standpoint (or at least, there would be if anyone actually respected licenses in closed source code instead of just pirating from open source libraries.)
Re: Digny and Respect? No. (Score:2)
I imagine lots of people - even most - ARE getting paid to work on open source. The vast majority of my contributions were done while being paid to do my job. Linus gets paid to work on Linux as another example. Lots of companies are paying for this work already.
Re: (Score:2)
I imagine lots of people - even most - ARE getting paid to work on open source. The vast majority of my contributions were done while being paid to do my job. Linus gets paid to work on Linux as another example. Lots of companies are paying for this work already.
This only applies to massive projects. The bulk of projects corporations steal code from are not big enough to have people behind them who can successfully track down people taking their code. Even in cases of large projects with very active maintainers things are rarely structured in a modern subscription paradigm, open source is geared heavily toward what amounts to a job shop billing method even in the best of cases, save for a few very rare exceptions.
Re: Digny and Respect? No. (Score:2)
The stuff I'm working on is usually small libraries and utilities. If we encounter a bug or misfeature with dependency, I'll go in and fix the bug or add the feature we need.
Sounds like your anecdotes don't match my reality.
Re: (Score:2)
Sounds like your anecdotes don't match my reality.
Really? Are you getting paid for the work by everyone using them for commercial purposes? Your own anecdotes don't appear to match your suggested reality, or you've simply got a reading comprehension problem. Which is it?
Re: Digny and Respect? No. (Score:2)
I'm getting paid my employer, who is commercially using their software. Not sure what you're asking.
Platform Cooperatives (Score:1)
Open source life cycle (Score:2)
(Applicable for the vast majority of open source projects. Yes yes, there are a few notable exceptions. They don't disprove the cycle)
Coder is annoyed by a problem, creates program / project to fix it.
Project fixes problem that was annoying others, some join to help out.
Project grows, gets more users.
More users start finding bugs and requesting features.
Project improves software and grows, attracting more users.
Eventually project crosses user critical mass, more support and code development is needed than
Re: (Score:2)
Popular projects are not the problem. As # of users increases, so does # of developers (and you don't need 10x more developers if userbase increases 10-fold). If a developer goes away, there will usually be someone to fill in the gap.
The problem is smaller projects. In case of a 1 person show, if developer / maintainer goes away, project goes stale unless another maintainer picks up the slack. But even in a small team, eg. a lead developer leaving can have a big impact.
All sustainability prolbems... (Score:3)
All sustainability problems are people problems. Why would this be any different?
Trump-era assholes increaded exponentially... (Score:1)
The caller left a sarcastic msg to NOT call back as he was expecting a real person to take his call hand provide service.
I have no idea what service he was looking for, nor who he was looking for, nor who he is. Just a long msg on how I have offended him by not answering.
This is a common attitude I have recently encountered with new clients as well.
What do you think makes them
Expecting users to contribute is the problem (Score:2)
Expecting mere users to become developers and start contributing patches, instead of routinely inquire when the bug they reported will be fixed, is the real problem. That rejection of users is what's toxic. This is how most users end up giving up on FLOSS and going back to commercial software.
Re: (Score:1)
Re: (Score:1)