When software depends on a project thanklessly maintained by a random guy in Nebraska, is open source sustainable?
- Reference: 1620643507
- News link: https://www.theregister.co.uk/2021/05/10/untangling_open_sources_sustainability_problem/
- Source link:
Well, here's a vulnerability for you: what if the open-source project that powers your business software falls foul of a show-stopping functionality bug or security flaw? What if the project goes belly up altogether because the maintainer leaves?
Companies paying a commercial vendor for their software can typically pressure them for a bug fix, and it's unlikely that the commercial entity will vanish overnight. That's less true for open-source software (OSS) projects, which are often maintained single-handedly by a random person somewhere as a hobby.
Everything's held together with sticky tape
Commercial reliance on open-source software (OSS) is huge. Software integrity company Synopsys, which publishes a regular report on open-source security and risk, found that the number of open-source components per commercial application jumped from 84 in 2016 to 528 last year. Yet the money that open-source maintainers get for working on this software, often in their free time, hasn't grown much if at all.
[1]Give 'em SSPL, says Elastic. No thanks, say critics: 'Doubling down on open' not open at all
[2]Cross-platform Windows Presentation Framework, anyone? The short answer: yes. Unpacking Avalonia
[3]Open Source Vulnerabilities database: Nice idea but too many Google-shaped hoops to jump through at present
Funding for OSS projects is typically dire. In 2019, developer André Staltz collected data from Open Collective and GitHub to assess project revenues. Over 50 per cent of projects couldn't sustain their maintainers above the poverty line, while 31 per cent generated enough for a salary considered unacceptable in the industry.
The sample size was small (58), but that made these results even more illuminating. It comprised relatively large projects, most with at least one full-time contributor. For each of these, there are thousands of other projects that are smaller, but still critical for at least one company somewhere.
[4]
[5]
[6]
Projects foundational to the health of the internet are often alarmingly undersupported. In her 2016 report on open-source sustainability for the Ford Foundation, Nadia Eghbal documented the plight of the OpenSSL project, on which thousands of companies and applications rely.
It was earning no more than $2,000 in donations each year before its [7]Heartbleed security vulnerability surfaced in 2014, with most of the other funding coming from consulting and contract work. It also had just one full-time developer.
"Immediately after Heartbleed and for some years afterwards virtually all of our funding came from sponsorships/donations," says Matt Caswell, who sits on the OpenSSL Management Committee.
[8]
Donations to the project are still small today. The OpenSSL Software Foundation has just two supporters under its corporate sponsorship program, each committing around $5,000 each. It also picks up some donations via GitHub Sponsors.
Although Caswell won't reveal numbers, he says that virtually all of its funding comes from support contracts.
The organisation is in better health than it was in 2014 from a personnel perspective, now sporting four full-time developers. That's better, but still worrying when you remember how much of the internet depends on this software.
Project malfunction: Maintainer not responding
A lack of funding can exhaust the open-source maintainers responsible for keeping projects going, warns Geoff Huntley, senior development success engineer at online development tools company Gitpod and a long-time maintainer of open-source code.
"We start doing software because we like writing software, and then a community evolves. And all of a sudden, people start burning out," he says. "One of the things that causes the burnout is they're doing tasks and activities they don't like. The root cause of that is essentially that open source is built on free labour."
Increasing workloads
This can have profound effects on maintainers, who suddenly find themselves fixing bugs they don't care about, handling community politics, running QA on sloppy contributions, and dealing with toxic comments from people using their software for free. Things are so bad that Linux Conf AU, held in Huntley's native Australia, has taken to making a psychologist available for OSS devs on site.
In April, Gitpod carved out $30,000 for an Open Source Sustainability Fund to help developers. The company, which has also made Gitpod free for open-source communities, aims to give the money to open-source projects on which it relies.
[9]
Huntley is advising other companies to follow its example: generate a bill of materials for your commercial software to find out what components you use and then identify your unpaid vendors. Then mitigate your supply chain risks. The fund has a simple decision tree that he uses to determine whether his company can either fund the project, contribute in kind with code, or take a more active role as a maintainer.
While folks like Huntley step up, plenty of companies just use OSS without giving anything back. The problem stems from a misalignment in mindset, says Aaron Stannard. He's the CEO and founder of Petabridge, a company that ported Java concurrent application toolkit Akka to .NET as an open-source project.
"The consumers are incentivised to go ahead and just take and take and take and get free value, solve their problems, and move on," he says. "They're making money off of open source. Whereas the producers originally open-source the software for reasons that are typically not commercial."
Show me the money
How can open-source developers buck the trend and start getting paid for their time? People might turn to individual donations through platforms like Patreon or GitHub Sponsors, but some are sceptical. OSS developer Drew DeVault is the third most prolific contributor to wlroots, a set of modules for building compositors for the Wayland display server communications protocol. That project accepted donations, he says, but didn't deliver much.
"It was never even close to enough for even a single developer to make a living from," he says. "If you were doing that strategy, and you were hoping that you can make a living from it, you have to understand that that's extremely difficult." However, it did get him some fruitful consulting gigs, including with Valve, on building Linux-based support for virtual reality.
Business sense?
Like Huntley and Stannard, DeVault has turned his own open-source project into a business. He operates SourceHut, which combines various OSS development tools into a software development platform that can be self-hosted, or which SourceHut will host for you. The project is currently making around $10,000 per month, even though it is not yet forcing people to pay for accounts.
The mindset for building an open-source business is far different than the one you need for maintaining code, says DeVault. "You can make money in open source, but not by accident. You need a monetisation plan, a sales and marketing strategy. That entrepreneurial approach won't come easily to all developers."
"Your monetisation strategy will also change based on your OSS product," says Stannard. Some companies charge for a licence to use their source code, based on a variety of open-source licences from MIT's permissive licensing through to stricter ones like the GPL, depending on their business model.
Licensing the open-source software wasn't the right path for Petabridge. Its software is designed to be a foundation to build other things on. Licensing it to embed it in their own software raises adoption risk for clients, Stannard says. Instead, he makes the software free.
"The organisation can start buying in and building stuff and the more stuff they build on top of your free and permissive open source, the deeper the roots sink into it," he explains. Petabridge makes a lot of its money from training and consulting fees, but also sells proprietary add-ons for customers.
Another option for OSS developers to make money is a support licence that guarantees you'll fix a company's bugs, which is something Stannard's company also does. That doesn't mean he won't fix bugs submitted by a non-paying user if they make sense for the broader health of the project.
"You're not really buying our ability to go and fix bugs," he says. "What you're buying is our guarantee that we will fix the bugs when you need them fixed."
You might argue that it would make more sense for companies to just fix the bugs themselves and then commit them back to the project like good corporate citizens. Alas, there's a problem with that, explains Huntley. Often a company's employment contract will insist that it has complete ownership over all intellectual property that an employee creates, which doesn't sit well with open-source licences.
"Enabling a company to be friendly with open source involves going through and revising employment contracts to enable contribution to open source," he warns.
Make open source work for you
At the very least, some arrangements like these can help developers to support projects that have become valuable for the community without corporate customers strip-mining them. But some developers might not want to become business people. Other options include crowdfunding an open-source project, or taking corporate sponsorship. If you're going to take the sponsorship route, just be wary not to end up depending on one sponsor for the lion's share of your income, and steer away from sponsors that try to influence your development direction.
Several intermediary sites have emerged to help collect and disburse crowdsourced or corporate sponsorship funds, including the Linux Foundation's LFX Crowdfunding site and the Open Collective. The latter is an online platform that brings open-source projects and sponsors together via its legal entity, the Open Source Collective nonprofit. OSS projects aren't hierarchical or legal structures, explains Open Collective co-founder Pia Mancini. The collective isn't about supporting individuals so much as the community that builds up around an open-source project, she explains.
"We believe a community is most effective when it can survive its founders," she adds.
While providing open-source communities with a front-end interface to collect and distribute funds, the Open Collective also has tools for sponsors. Its Back Your Stack tool enables companies to analyse their open-source software dependencies, checking project manifests to produce the OSS bill of materials that Huntley described.
What about if you're a developer who'd just like to earn some money while working on open-source projects? Tools like Bountysource offer companies the chance to create bounties for specific features or bug fixes pertaining to open-source projects. Then individual developers can go in and fix them. DeVault also has a neat idea: run a short script to evaluate the domains who have committed to a project's repository in the last 100,000 commits. Then contact them to see if they'd be interested in a conversation. Just make sure you have a decent commit history already. Let a hundred million flowers bloom.
The very thing that makes open source so successful also contributes to its sustainability problem. It thrives on a low barrier to entry and attracts new developers eager to get involved, either for career advancement, self-education, community support, or simply to scratch their own itch. That has led to a massive proliferation of projects. GitHub had about 33,000 repositories in 2008. Ten years later, it celebrated as it passed 100 million.
Not all of those are code repos. Many of them are abandoned. But still, the numbers belie a chaotic segment in which many developers working alone could be working together, if only they could organise. That lack of cohesion makes open source as vibrant, interesting, and frustrating to manage as the internet itself. ®
Get our [10]Tech Resources
[1] http://www.theregister.com/2021/01/18/elastics_doubling_down_on_open/
[2] http://www.theregister.com/2021/03/30/crossplatform_wpf_anyone_unpacking_avolonia/
[3] http://www.theregister.com/2021/02/11/google_osv_database/
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2YJlYnV8xwIWEFEZGAY1ALgAAAAo&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[5] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44YJlYnV8xwIWEFEZGAY1ALgAAAAo&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[6] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33YJlYnV8xwIWEFEZGAY1ALgAAAAo&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[7] https://www.theregister.com/2014/04/10/many_clientside_vulns_in_heartbleed_says_sans/
[8] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44YJlYnV8xwIWEFEZGAY1ALgAAAAo&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[9] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33YJlYnV8xwIWEFEZGAY1ALgAAAAo&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[10] https://whitepapers.theregister.com/
The dominos fall
> it's unlikely that the commercial entity will vanish overnight
Yes. A massive assumption. There is a whole domino effect here.
An open source developer loses interest (or gets a partner / starts a family / gets a job). They simply stop working on a project. A commercial outfit that relied on it decides that their programmers aren't clever enough to deep-dive into the software and so declare their product as reaching end-of-life.
All their customers are recommended to use a commercial alternative at a much higher cost (due to the cost of support staff ... and profit)
"Apart from the bug being assumed to be a feature."
Or Oracle's approach, which is to only fix bugs in a future major release rather than in a minor version of the current release. In several cases that meant waiting literally years for a fixes.
"it's unlikely that the commercial entity will vanish overnight"
That seems like bollocks, but more importantly commercial entities abandon software all the time. If you build your business on a software/framework that a company discontinues you are out of luck. With OSS, you are in practice out of luck too, but you have the options of trying to maintain the software yourself, or trying to co-fund a developer to take on the project.
I am not denying there is a problem with OSS funding. But saying that relying on proprietary software is more stable appears to be a statement built upon bias rather than evidence. It depends on the context. We have seen RT linux outlive commercial soft realtime OSes like PharLap. But, that does not mean you should build your business about a GitHub project with a commit a month for the last 2 years (you could always hire the dev to keep the project alive). Context is everything.
Re: unlikely that the commercial entity will vanish overnight.
Thinks back to last redundancy, to most of the customers and staff a software company did just disappear overnight leaving several companies desperately looking for support/replacement for a critical system.
> Companies paying a commercial vendor for their software can typically pressure them for a bug fix, and it's unlikely that the commercial entity will vanish overnight. That's less true for open-source software (OSS) projects, which are often maintained single-handedly by a random person somewhere as a hobby.
This isn't an accurate representation of reality.
There's some commercial software we use where the team is 3 people, and support is via a mailing list. The only difference to an opensource project being that the code isn't opensource, which brings the added risk that we can't just fork the software if it goes under or the maintainers walk away etc.
The article paints it as "opensource vs proprietary" but actually the example it's given is "small dev team vs big software house".
Microsoft/Oracle etc are unlikely to vanish overnight, but then, nor is Redhat - the fact that MS/Oracle are closed source is incidental.
Whether it's open source or not, you should be doing some kind of a risk assessment on your dependancies. If something you depend on goes away or doesn't get a fix to a serious vulnerability, the initial impact is the same. Whether or not it's opensource might just decide whether you can continue on from that point or not.
I'm reminded of the situation where we had some commercial source code but not enough to compile the full application. After having the second Friday lunchtime interrupted by a bug in a weekly program run I spent the afternoon working through the code to find the bug. Even after reporting it to them, including how to fix it, it took a few weeks before we got the revised binary. I wouldn't be surprised if the same dodgy coding practices were hidden in more of their programs.
The article paints it as "opensource vs proprietary" but actually the example it's given is "small dev team vs big software house".
The example is small _unfunded_ dev team. That's the point.
In your example I assume you pay for your software maintained by a team of 3, I would hope they charge enough to fund development? If they do then even should they decide to jack it in they still have a commercially viable product that can be sold.
If an open source maintainer gives up because it's not fun and not worth their time, there's little you can do other than fork it.
Whether it's open source or not, you should be doing some kind of a risk assessment on your dependancies. If something you depend on goes away or doesn't get a fix to a serious vulnerability, the initial impact is the same. Whether or not it's opensource might just decide whether you can continue on from that point or not.
Yeah, pretty much this. :D
"If an open source maintainer gives up because it's not fun and not worth their time, there's little you can do other than fork it."
And the ability to do that is because it's open source. I remember looking at the description of some S/W, thought it might be useful to the business I worked for and then the company that wrote it got bought up by Microsoft and that was the last I ever heard of the product.
"Whether it's open source or not, you should be doing some kind of a risk assessment on your dependancies"
Spot on. If your business is not managing risks then you're a risky business.
@Ben Tasker
"Microsoft/Oracle etc are unlikely to vanish overnight"
No, but they can stop supporting software / hardware / combinations thereof & leave people in hassle.
.. one reason why many devs reluctant to jump onboard MS "latest & greatest" new shiny thing as they often end up discarded (SilverLight, windows mobile development (& huge incompatibility between versions) anyone?)
Proprietary software often has open source dependencies, and commercially supported open source is likely to have dependencies
Here is a list of open source components shipped with MS products: https://3rdpartysource.microsoft.com/
> what if the open-source project that powers your business software... goes belly up altogether because the maintainer leaves?
IT'S OPEN SOURCE STUPID.
You pull the code and fix it, duh. I've done it before and, no doubt, I will do it again.
Here's a question for you Danny Bradbury...
What if the closed-source project that powers your business goes belly up because the company behind it goes bankrupt? How are you going to fix THAT code?
"Fix it"...?
You are erroneously assuming, as a programmer/techie, that every business house had the ability in terms of technical wherewithal to just open up the source code and make it their own.
This is the major failing of understanding to the entire OSS / Linux community: the largest majority of those who interact with computers are plain-Jane users and are NOT technically advanced. The vast majority of the users sitting in front of their computers have NO idea how this thing works, let alone how to read a line of code.
"Just fix it" for these users is the equivalent of Musk calling them from SpaceX, "Our rocket has gone off course, we need a solution now!"
Re: "Fix it"...?
You are erroneously assuming, as a programmer/techie, that every business house had the ability in terms of technical wherewithal to just open up the source code and make it their own.
Even as a programmer I'd say that's a bold assumption. I work with some very talented people but that doesn't mean we could instantly pick up all the open source projects we use, either due to manpower or skillset.
Not every programmer can program everything in every language.
Re: "Fix it"...?
You are dodging the question - what would you do if a closed-source vendor went bust that is any better or even no worse?
"This is the major failing of understanding to the entire OSS / Linux community: the largest majority of those who interact with computers are plain-Jane users and are NOT technically advanced. "
What a load of crap. "This is the major failing of understanding to the entire proprietary software community: the largest majority of those who interact with computers are plain-Jane users and are NOT shareholders able to dictate the company's business practices."
It's just meaningless gibberish. What do these "plain-Jane" users do when they need a feature added to or improved in Word. What do they do about the fact that Outlook is a steaming turd of an email client? How does closing the source and paying a license fee to the company improve their experience in any way?
Re: Dodging the question
You are missing the real point: you are paying for both the software and support of said software.
Therefore there is a much larger chance that the software supplier will remain committed to maintaining the software and servicing its customers... because they have a direct financial interest in doing so . Staying in business, keeping that software rolling in support and updates, keeps food on their table.
It that guaranteed?? Not in 1 million years.
But where's the incentive, beyond pride, for the OSS programmer to continue on a project that has grown too complicated or demanding?? It's simply not there. They are not getting money from it - indeed, as this story proves, it is a drain on his / her personal resources. They continue on the project by the grace of their will.
Which can be terminated when he / she realizes that the project is just no longer worth the energy put into it.
Bullshit
If a F/LOSS project goes titsup and it matters, somebody else will step forward and carry the torch. You can even get off your arse and do that yourself. It has happened over and over again.
If a proprietary project goes titsup, whether by accident or (surprisingly often) design, you are FSCKED. It has happened over and over again. There is even a word for it: lockin .
Do you want to believe the lessons of history, or this pile of Trump-worthy animal excrement?
Re: Bullshit
CentOS?
Look what has happened with that........
Re: Bullshit
Forked. Now Rocky
"somebody else will step forward and carry the torch"
Wishful thinking - there's plenty of abandoned FOSS nobody stepped forward to maintain them - users just made what they would have done with commercial software - looked for and switched to an alternative.
Even little things.......
Many current laptops don't have CapsLock or NumLock lights on the keyboard.
For years now I've solved the problem (on Fedora/XFCE) with a little XFCE plugin (called xfce4-kbdleds-plugin).
Then last month Fedora 34 was released and this plugin wasn't updated and the F33 version wouldn't install.
*
Turns out that the original author touched the code last in 2011, and has long since decided to move on. No probs here with their decision!
But a huge surprise that this useful little utility worked fine for ten years with no maintenance.
*
I've written an XFCE notification which pops up if either keyboard lock is pressed.......not ideal, but better than nothing.
Re: Even little things.......
... original author touched the code last in 2011, and has long since decided to move on.
Indeed ...
Reminds me of the path taken by a very neat, simple and fully functional syncing application writen for Linux and Blackberry phones, Barry.
Yes, it's 2021 and I still use a 9320 but every so often have to fire up an XPSP3 VM and use RIM's awfully convoluted and (really) shitty software which didn't even include a desktop organizer application.
All kudos go to the chap who wrote jpilot (www.jpilot.org) for Linux and keeps it current.
Yes, it's 2021 and I still use a Palm E2 and a Palm T|X.
And I was using a Palm IIIxe (uses 2xNiMH AAA that do not explode) up to a couple of years ago, just thanks to him.
Only mothballed it because my eyesight is not what it used to be.
A.
"... it's unlikely that the commercial entity will vanish overnight ..."
You're wrong on that score. Places that I've worked at have seen vendors or their products suddenly disappear. A couple of examples. A pub-sub event system disappeared because a large dot com bought the vendor specifically for that product, made it solely for their internal use and suspended all existing licenses. In another case, the vendor was bought by a competitor and the new owners dropped one of the aquisition's products in favour of their own much more expensive, incompatible and less featured one.
Two thoughts
The first is that a company using something open source could, if they wanted, take on the bits that are no longer being developed by that one guy in Nebraska. That's part of the nature of open source.
The second thought is that not all long ago, the decayed corpse of MSIE6 was still kicking around because various corporate (and health service) things were written to work with IE6 and, well, they would only work with IE6 and something more modern simply didn't exist.
There's no guarantee at all (unless specifically written into a contact) that any commercial offering is more "secure" (in the sense of not vanishing or being abandoned) than an OSS offering. At least with OSS abandonware, The source is there. It can be fixed. It can be rewritten. It can be replaced with a three line shell script. Whatever, one can look at it and see how it does what it does. Commercial binary blob? Not so much...
Discussed previously on the Stack Overflow Podcast
And it's a problem that's bitten us (hence anon). The closest you're going to get to belt and braces mitigation is, I think, to be employing developers skilled enough to read through and change some potentially icky code, and that's expensive! Back when we started to really embrace open source I already had experience of what can happen when a bug blocks your way and sounded an appropriate warning. Fast forward a good few years and the whole world runs on the kindness of strangers. Consider my focus, web automation. I don't think there's a single entirely closed source solution and WebDriver can be somewhat mercurial bit of software. Thankfully, I've yet to encounter a problem that didn't have a workaround.
Edit: I should add that I trust a lot of big ticket open source software more than I'd trust closed source (e.g. Postgres over Oracle MS SQL any day of the week).
Happens with closed source.
Years ago we had a project that used Informix. They got bought out by IBM who dropped some of their products - including one that we required for our project. To "fix" our problem would have required a good chunk of funding and manpower - something that wasn't available. So the project got shelved and died.
Non sequitur alert
"it would make more sense for companies to just fix the bugs themselves and then commit them back to the project ... Often a company's employment contract will insist that it has complete ownership over all intellectual property that an employee creates."
There's absolutely nothing in the second part of that that stops the company committing back to the project. The company owns the IP and can do with it as it wishes.
There could, however, be a problem with companies who claim IP ownership of what employees do in their own time.
Elephant in the room
Is all the cloud vendors who simply rehost open source projects without contributing anything (Amazon, I'm looking at you!)
When I was a beginning engineer
The company for which I worked noted this problem and began to require all equipment vendors whose product included software - usually for microcontrollers - to lodge copies of their code with a third party, to be released if the company ceased trading or otherwise failed to support it.
This was in the days before desktop computers were in any way common. The company was big enough to be able to enforce this policy.
Somehow, I don't think they're enforcing it any more...
"Companies paying a commercial vendor for their software can typically pressure them for a bug fix, and it's unlikely that the commercial entity will vanish overnight."
That's a couple of fairly large assumptions. Apart from the bug being assumed to be a feature.