FOSS developers suffer burnouts that cause them to loose interest in their projects, and cause the projects to die.
Wondering about why this happens, we came to the conclusion that maintaining a project, especially on the issue tracker part, is felt as a burden and a really annoying thing. Most of FOSS development today is made around Github, which implements the issue tracker as part of the git repository. This and the fact that Github repos emphasises individual ownership of the repos (based on repos namespace) causes users to feel that issue management is the duty of developers, and that they are the only people responsible for it.
Developers may refrain to publish their work just because of this burden. When they do actually publish it, chances are they will lose interest after a few years and the project will enter a zombie state.
An alternative to that would be to separate code authorship from maintainance, and allow community to handle the maintainance.
Once a project has been created, there are a lot of different collobarator roles that emerge to keep the project alive, for example :
- extenders (people who add new code)
- convergers (people who review other people code and merge it)
- community gardeners (people who organize and manage issues)
- distributors (people who package projects and upload builds)
What tools could we build that would empower communities to take over those roles rather than expecting initial developers to be responsible for all of them?
It actually sounds like an ecosystem of tools, so we'll first here focus on the issue management part - but it'll have to be able to integrate with other tools.
Each individual may have different skills to contribute (social skills to answer issue submitters, writing skills to organize documentation, coding skills to fix bugs, etc). How can we make sure someone can contribute their skills without feeling a discouraging entry bareer? (like having to request permissions/rights)
Asking that, we should also wonder what level of ownership developers are willing to concede (all? part of it?). It's not uncommon a developer won't be satisfied with a PR and rewrite part of it because it's not "how they would have done it" : they have to be willing to concede on that.
The whole problem, here, is to find a way to allow community to collborate, without leaving anyone feeling alienated, including initial developers.
One thing we must think about when replacing a tool because of the problems we have with it is the problems this tool was solving. Some of those problems may not exist anymore (because the landscape may have changed), some may still exist. If we ignore them while replacing the tool, they may become the main problems of our new tool. So let's explore that: what problems having issues on Github repos is solving?
- issue tracking setup : a developer uploading code on Github has an issue tracker for free, no need to create a project somewhere else and to create accounts for devs to it
- discovery : if the code is on github, users know where to post issue without looking up
- cross-referencing : commits can reference and even close issues by referencing, simply by using their id, which suggest the issue name in an autocomplete style to easily find it
We need a tool that :
- empowers the community to contribute to issue management with their own skills
- still allows developers to contribute as they please
- integrates painlessly with other tools