Guide on how to open-source projects
This article is marked as draft. It is not in its final form.
Define Target Audience
The course will be tailored to researchers, scientists, and companies with scientific roots, such as Dispertech .
The reason why someone would follow this course.
Actionable insights for someone who follows the course
What will people be able to do/know after following the course that was not able to do before the course:
- Avoiding common problems with open source projects
- Practical checklist to open-source succesfully
- Getting the code ready for publication (or as companion of a publication)
Knowledge gap to be addressed
- Why would you open source ? <- Important discussion for scientists
- Risks and opportunities of open-source are misjudged
- How to lay out a path to create a community around a project
- Standard patterns for open source projects
- Why would you learn how to open source projects ? <- Question is why learning, not why open-sourcing
Structure Of the Course
What does it mean to open-source a project?
Scientific open source
packages and tools such as:
- PyPylon, ODemis <- There's a company behind them
- ImageJ, CellProfiler <- Bigger projects, now well funded. Check their origins
- Examples of smaller packages with a following:
- What about Open Hardware ?
Examples of non-open programs:
- Gadget (Astronomy)
- Probably epidemiologic modeling
- I am sure there are plenty more, need to collect feedback
What is the goal of open-sourcing? <- You may have different goals!
- Scientific reproducibility
- Empowering a community
- Gaining attention
- Lowering the maintenance burden <- Is this true? Perhaps from a company perspective?
- Marketing strategy around a product
- Open source is a political act
Risks associated with open-source
- Researcher: Scooping of topics
- Single(indie)-developer: Someone builds a product on your work
- Company: Giving away resources to competitors
The question: Do benefits outweigh the risks?
- Or how do we mitigate the risks? <- Topic for later, since this is more technical
- Choosing the tools to open-source: #git has eaten the world. 3 options:
- This course is not an introduction to Git! <- Can I assume people already know git?
- Readme! Create a description of the project, what it does, how it can be installed. Also, important, how to reach out! Screenshots!
- Choosing a license: On what basis? Never lose track of the objectives you set up at the beginning. (In other words: Start with Why ;-)
- Do you want people to contribute? <- Create contributor guidelines. If not sure, check other projects.
- The code
- How to use the program <- Examples
- How to extend it <- Examples?
- Hosted (and beautiful documentation) on ReadTheDocs
- More technical: Releases <- Zenodo!
Maintenance of the project: Master/Develop/Feature branch. Don't do all in master or people will get frustrated.
- Pull requests?
- How to evaluate Development costs of open source software
- How to evaluate Maintenance costs of open source projects
How to create and maintain a community beyond the code
- Sync/Async communication
- Foster inclusiveness
These are the other notes that link to this one.