Slashdot Mirror
The Complicated Economy of Open Source Software (vice.com)
An excerpt from a report, which looks at the complicated business of funding open source software development: On the surface, the open source software community has never been better. Companies and governments are adopting open source software at rates that would've been unfathomable 20 years ago, and a whole new generation of programmers are cutting their teeth on developing software in plain sight and making it freely available for anyone to use. Go a little deeper, however, and the cracks start to show. The ascendancy of open source has placed a mounting burden on the maintainers of popular software, who now handle more bug reports, feature requests, code reviews, and code commits than ever before.
At the same time, open source developers must also deal with an influx of corporate users who are unfamiliar with community norms when it comes to producing and consuming open source software. This leads to developer burnout and a growing feeling of resentment toward the companies that rely on free labor to produce software that is folded into products and sold back to consumers for huge profits. From this perspective, Heartbleed wasn't an isolated example of developer burnout and lack of funding, but an outgrowth of a systemic disease that had been festering in the open source software community for years. Identifying the symptoms and causes of this disease was the easy part; finding a cure is more difficult. Further reading: How Does Heartbleed Alter the 'Open Source Is Safer' Discussion?
At the same time, open source developers must also deal with an influx of corporate users who are unfamiliar with community norms when it comes to producing and consuming open source software. This leads to developer burnout and a growing feeling of resentment toward the companies that rely on free labor to produce software that is folded into products and sold back to consumers for huge profits. From this perspective, Heartbleed wasn't an isolated example of developer burnout and lack of funding, but an outgrowth of a systemic disease that had been festering in the open source software community for years. Identifying the symptoms and causes of this disease was the easy part; finding a cure is more difficult. Further reading: How Does Heartbleed Alter the 'Open Source Is Safer' Discussion?
I've been working on a project for almost 20 years at this point, and I definitely feel the same as what's reported here. As the project has gotten more popular and more users come on board, there is now much more demand on our team. And some companies have noticed the usefulness of the project and used it in commercial products. Not that I'm against that (as that's what the GPL basically encourages), but it would be nice at times if there was more contributions back from those that benefit from it.
And I don't necessarily mean money either. Extra help in coding, testing, etc would be nice too. But I suspect that people get used to a product being free, and then asking for anything more once it becomes popular is out of the question for them. But in the long run, it really leads to developer burnout, as more people want more and more, and can't (or won't) contribute. I know I am personally feeling the burden and looking at burnout soon.
Anyway, long story short; I can sympathize with developers in a similar situation.
"I thank you for your feedback, but I wanted to let you know this project is not actively maintained. This is a hobby project for which I do not get paid, and unfortunately I do not have the time to address all the feedback it receives. If you'd like to contact me about paid support or services, please send an email to..."
Setup an autoresponder. Burnout is stupid.
The summary mentions that the corporate world doesn't understand the OSS norms. Just as likely, in my opinion, the OSS volunteers don't have a good understanding of the corporate participants. We all appreciate OSS volunteers and the wonderful software they create. That said, it should be no surprise to anyone, least of which the person who put the license on the software, that corporations are going to do anything lawful they can to make money. If that means creating terrible patches and not integrating with the flow of the OSS project itself, they may do that. Those engineers at those companies are not the ones profiting in most cases. They are merely being asked to do more with less, as that seems to be the trend. The choice may be to attempt to get changes harmonized with the community or just publish whatever they come up with at the end. I suspect that there's a latent annoyance about this particular thing coming from the OSS volunteers. But, if you have given the company this right in the license (to use the software as long as changes are published), you can't be surprised that they're not doing a good job of helping you merge them into the mainline. They're doing the least they can get away with. To tie it all together, I think it's no coincidence that one of the largest, most successful OSS projects, Linux, was driven by a man who literally had no shame about giving the middle finger to an uncooperative company. (https://arstechnica.com/information-technology/2012/06/linus-torvalds-says-f-k-you-to-nvidia/). He understands the dance, and it's not an easy one. These companies will walk all over you. Let's not accidentally encourage naivety and call it a virtue.
Just one dev's opinion, but whether they're paid or not isn't the biggest issue. It's developer and community involvement - with devs ACTIVELY working on fixes, regardless of compensation (money, pride, prestige, etc.)
And that doesn't mean the original creator/author and one other person/spouse/friend. This means a minimum of 6-10 devs that are actively working on it. When one can't respond, another can pick up the slack.
End users turn their backs on projects that get the, "I'm too busy to do this," self-defense treatment from overworked developers/maintainers. That kills trust, which in turn kills the community of users and shrinks the possible pool of other devs who will bother to offer help.
(Worse yet, the "I'm too busy devs," sometimes ghost their own project outright - while retaining the keys to the project and keep others from taking over or even applying patches. For example, I've seen this in the Drupal community many times (abandoned add-ons/modules/themes with years of no new releases with fixes despite the list of offered (and community reviewed) patches that rot on the vine). Git forks and such can help alleviate some of this, but It is a real PITA having to recompile patches into increasingly fragile build processes and maintain them ourselves when a simple release of control over the project when it's been abandoned for a certain period of time - allowing for new releases - would fix the problem.)
Advice to OSS devs: 1) Be kind to contributors - even bug reporters. They just don't understand. 2) Don't waste time engaging jerks. Shun them. 3) Accept good help when offered, and KINDLY reject bad help. 4) Ask for compensation when necessary (for requests that don't really help the project or are one-off features). 5) Give up control ASAP when you're "done". Don't strangle your baby by holding on too long. 6) Commit to warning end users if the project is going to be shut down. Not doing this is devastating to popular project end users.
Advice to all end users:
1) Don't be a community leech! Donate in relation to how much you use a project.
2) Don't just have a problem -- try to have a solution. You'll get back what you put into it.
If you're an individual end user:
a) Be kind and professional in your requests and effusive (but short) in your thanks for anything done (even a WONTFIX).
b) Help out a little wherever you can (even simple, end-user friendly documentation for non-brainiacs; Almost all devs can use a heaping helping of help on.)
If you're an organization with a budget:
a) Donate any resources when possible to help it keep going. ($$$ is good, in-house dev hours is better, and both is best.)
b) Know when to get out - usually when the community leaders disappear and the FIRST sign of tickets not being responded to. Jumping too early hurts your org, but waiting too long is even worse.
Contributions are only expected in proportion to demand for more work.
If millions of users take the project as it is, use it in its current form, possibly tweak it for themselves, take it apart, add new features for their own use, or do whatever they want with it within the license terms, that's fine - no contribution required. (Although it is always appreciated!)
However, if users start demanding new features, and customizations, and bug fixes, and support requests, on strict timelines, without offering anything back in return for their heightened expectations, that is when the project team starts to expect the users to contribute to the community beyond just issuing demands.
It is unreasonable for the users to expect and demand that the project team do work for the users benefit for free with no contribution back from those users to the community.
"Go to CNN [for a] spell-checked, fact-checked summary" -- CmdrTaco