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?
Idea: Tax Amazon at, say, a tenth the rate I pay, then provide grants to the open source projects they are using for free.
Society solved this kind of problem long ago, we have just forgotten the solutions. Treat open source software as the infrastructure that it is.
I got user burnout, after having the bugs I reported either brushed away or marked WONTFIX.
We need another status field in OSS bug trackers. Something like WILLFIXFOR_???$.
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.