Link Search Menu Expand Document

Inner source

Within Storio Group we adhere to the principles of inner source. This document explains why and what the best practices are to enable inner source in your work.

If you would like to learn more about inner source, the Inner source commons has a lot of useful information.

What is inner source

Inner source is a development methodology that applies the principles behind open source software to internal software development. The core values of this methodology are:

  • Development happens in the open: Issues, code and reviews are visible to all developers.
  • Making code changes to repositories outside of your domain is enabled and encouraged.
  • Communication around the development process is open to everyone.

Why do we use inner source

The main arguments for inner source are simple: Improved code quality and collaboration make development faster and more fun. Developers are encouraged to make improvements where they see them, and can safely experiment with different technologies and domains. Inner source also encourages code sharing and best practices around introducing new code, which also benefits the development processes of individual teams.

Inner source at Storio Group

Storio Group uses various tools to implement inner source methods:

  • JIRA is used for issue tracking. Bug reports and feature requests can be created and discussed here.
  • Github is used for version control and to collaborate on code.
  • Slack is used for communication within the company. Many projects and teams have public channels where you can ask questions. Both Jira and Github are open for everyone to browse and contribute.

Applying inner source principles to your projects

JIRA tickets

The first part of the software engineering process is to decide what needs to be built, and that is also where the inner source starts. Make sure that your project has a JIRA board where issues are tracked, and keep it maintained to invite others to contribute. Having a clear format for issues helps others to create useful tickets. If a ticket is missing information or misplaced, discuss it during refinement and give feedback to the author. As always, the feedback should be constructive and aimed at getting the ticket towards a state where we can start work on it.

What can be especially helpful for bringing in external contributors is to maintain a set of issues that are easy to pick up for new. You can use a JIRA epic or labels to group these issues.

If you want to create a ticket for another team, it can help to communicate in advance through Slack. This ensures that the team is aware of the ticket, and they can help you format the ticket and add all relevant information.

Helping contributors

Once there is agreement on what needs to be built, the programming step can begin. A key factor for making it easy to work on your project is documentation. Of particular importance are:

  • Documenting how to install, run and test the project.
  • Clear guidelines on what a pull request should look like and include. Also be explicit about what is not acceptable (introducing new dependencies or not having tests for example).
  • Who is responsible for reviewing PRs, and when you can expect reviews to be done. At this point someone can start contributing to your repository. For bigger tasks it may be helpful to assign a mentor to the contributor. Communicating and giving feedback early prevents friction when the PR is eventually submitted. The code review guidelines apply here for author and reviewer. For external contributors, some extra care should be taken: discussion regarding the pull request should be visible to the contributor, and not be done internally. After their contribution is done, consider using 15five or the killer whale ceremony to thank them for their contribution.

Contributing guidelines

  • Communicate before you code! Send a heads-up before you start working to validate whether your contribution is in the right place and to get some pointers.
  • Contributors are expected to adhere to the (coding) standards of the repository. Make sure those standards are clear and preferably automatically validated in CI/CD.