I compiled this information based on the question, “How can we ensure our project doesn’t sit on the shelf and collect dust?” Some of the links are research into what failed open source projects have in common. Some of the information is around practices that help a project to be more robust and appealing to the community. Some of the points are my own thoughts and reflections as I read through the content. Like all Technicae novicus (TN) posts, it’s an exercise in clearing the cache and starting over. We would love to hear from the readers out there what your experiences with open source projects – for better or worse – have been.
Why Modern Open Source Projects Fail
- Survey of 414 devs 29% response rate
- Why open source projects fail?
- Usurped by competitor Environment 27
- Obsolete Project 20
- Lack of time Team 18
- Lack of interest Team 18
- Outdated technologies Project 14
- Low maintainability Project 7
- Conflicts among developers Team 3
- Legal problems Environment 2
- Acquisition Environment 1
- What practices impact success?
- Contributing guidelines (large impact)
- Continuous integration (medium impact)
- Licences, home pages, and issue templates (small impact)
- Strategies to overcome and unmaintained account
- Move to an org account
- “with this kind of account it would be easier to attract new maintainers and to manage permissions.”
- Transfer ownership [unsucccessful]
- “We tracked the activity of the new maintainers, until February, 2017. They did not perform significant contributions to the projects, despite minor commits”
- Accepting new core developers
- ”volunteers offered to help with the maintenance, as core developers”
- They were either turned away by the original owner or the owner requested a plan for development which the new core devs viewed as too high of a barrier to entry
- Move to an org account
http://opensourcesurvey.org/2017/
- Documentation helps orient newcomers: how to use a project, how to contribute back, the terms of use and contribution, and the standards of conduct in a community. Improving that documentation is an impactful way to contribute back to open source.
- When communicating on a project, use clear and accessible language for people who didn’t grow up speaking English, or read less-than-fluently.
- [My Thoughts] I wonder if, in creating the original documentation, we could 1) emphasize Karen’s vision for a tool used for the greater good and to protect the people and 2) interweave some feedback culture i.e. if you have a conflict, discuss in a private way rather than a public way. What would the downside to that be? Would it require private messaging? Is that a layer of complexity beyond? Would it be worth the investment? Could it be abused? Negative experiences impact project health
- Rudeness is the #1 negative behavior. How can that be somewhat negated upfront? State that part of the project credo is “Assume everyone is doing the best they can with what they know at that time?”
- [!!!!] The gender imbalance in open source remains profound: 95% of respondents are men; just 3% are women and 1% are non-binary.
- Half of contributors say that their open source work was somewhat or very important in getting their current role.
- Stability & security are top 2 in what users value in OS projects
- No matter which stage you decide to open source your project, every project should include the following documentation:
- Open source license
- README
- Contributing guidelines
- Code of conduct – https://opensource.guide/code-of-conduct/
- Name – What would it be called without the RIOT front end? http://ivantomic.com/projects/ospnc/
- How can we provide entry points for newbies to triage bugs/issues?
image: By Bundesarchiv, Bild 102-09312 / CC-BY-SA 3.0, CC BY-SA 3.0 de, https://commons.wikimedia.org/w/index.php?curid=5414490
