Transparency is an inherent trait of open source projects, because licenses guarantee at least transparency of the source code. To what degree transparency extends to other aspects such as the development and planning process or to community activities varies, though. If done right transparency can lower barriers, make a project approachable, create trust, and provide predictability to its users and community.
The following stepping stones form the path of transparency. They are not in a specific order. Each project will pick and arrange them in a way that is suitable to them.
Releases are what makes open source projects real. Shipping is what brings the code to users. Most projects have more or less elaborate processes around technical production of a release. Releases are also a way to align a community around shared goals and an opportunity to celebrate results.
Transparency about release schedules, status, and expectations helps users to choose and plan. It makes projects predictable so people can rely on it. It also builds trust, if schedules and promises are kept.
- Ubuntu cadence
- VSCode development process
- LibreOffice release plan
- Kubernetes SIG release
- Ruby's Christmas release tradition
Explicit asynchronous throrough discussion of ideas can help to shape bigger changes. Having a process for that which allows for presentation and commenting of ideas and some kind of lifecycle to make it clear where proposals stand helps to discuss complex ideas in a distributed community.
- RFCs - the mother of all improvement proposals
- Python Enhancement proposal
- Rust RFCs
- Bitcoin Improvement Proposals
How can you know what has been discussed, what has been decided, and understand the base for past discussions. If you hold discussions in the open on a medium which archives these, such as mailing lists, you create this transparency. Invaluable for new people and for everybody to keep a shared context and not let things be forgotten, which are important to understand.
- Mailing lists
Documentation is crucial for any project which wants to be used, especially if it's addressing technical users and there are APIs and other technical structures and concepts you need to understand.
Bonus points if there is a straight-forward way how to contribute to contribution, also for the occasional reader.
- List of great READMEs
- README template
- API documentation
Badges are a condensed way to communicate certain traits about a project. Be it test status or coverage, code quality, release and licensing information, references to certain organizations or technology, etc. This can makes it easier for people to grasp a project and to find what they are interested in.
Following what is happening in an open source project can be overwhelming. It can be very helpful if people from the inside who have an overview condense their knowledge into reports for the outside. It can be seen as a form of marketing but also as a hook for collaboration.
This can cover technical content, for example what's currently happening in the code repositories, but can also cover non-technical content such as reports from board meetings, etc.
- Commit digests
- Annual reports