There is a dynamic that arises when there is a growing difference between the amount of maintenance required and available developer time. The maintainers need help to keep up. Until then, they need to ensure that the essentials are maintained. That in turn makes it harder for others to contribute, because the maintainer cannot afford to take any risks that might trigger unexpected work sometime later. So the maintainers have less time to review, less time to help complete merge requests, etc 1/
This can turn into a downward spiral, because it can drive away contributors, making things worse. Then only the ones who really feel responsible for their user base will continue working on it. Then ultimately they can burnout and the thing goes down in flames. The #XZBackdoor is a version of this dynamic. The #XZUtils maintainer was caught in that dynamic and felt he could not keep up, and was desparate for help since so many essential pieces of software rely on it.
2/
Lots of hackers would love to go in an contribute to new projects. If there was a way that people could make a living doing that, we would greatly improve the #FreeSoftware ecosystem. Lots of devs want to improve the code they work on, but so many company ban employees from contributing to #FOSS. One promising new model is maintenance funding from governments and foundations, like @sovtechfund and #LinuxFoundation. Since 93% of codebases use #FOSS, this affects the entire software ecosystem
4/4
Great discussion on this at #rubyconfau yesterday.
Useful to distinguish types of contributors:
- Funded corporate contributors (mostly working don’t need funding)
- Tiny/new experimental/toy project makers (funding is not yet a goal or priority)
- Self funded contributors who start to wear an ongoing support workload (this is the focus group)
It’s self funded maintainers that start to carry this burden of support we’re taking about.
@richiekhoo @sovtechfund yes, self-funded maintainers are an essential target for this kind of funding. I would also include volunteer maintainers, which is not the same thing. Many maintainers of key software pieces do want funding for the work, but funding can still go to others writing patches, etc
There also needs to be help getting companies understand that it is in their own interest to let their developers contribute to any project they rely on, no matter how indirectly they rely on it.
This also happens in companies, but the dynamic functions a bit differently. The maintainers will start quitting their jobs, reducing the number of people who know the code. In a number of companies, I've seen this happen where the end result is an essential system that no present employee understands. So no one is allowed to touch it as long as it is working. This happens at mega corps and small companies alike. I experienced it at Merrill Lynch, a wealthy bank that was always cutting costs 3/