This blog is Part II.a of a series on how to get started with Inner Sourcing within an organisation. In Part I we discussed how to select an Inner Source adoption model and how to go about choosing the first project to be inner sourced. This series is nothing but a guideline and will therefore not specify any specific tools that you must use. This you will have to figure out yourself based on the organisation that you are in.
Once you have an Inner Source project, it is paramount to have a project management plan of some sort in place. Since Inner Source is a different software development model from what most people are used to, managing an inner sourced project will therefore be different.
Let’s do a quick recap on what the goals of Inner Source are to determine how we would go about managing an Inner Sourced project.
Inner Source goals recap
These are some of the major goals and major benefits of the use of Inner Source (in no particular order):
- Improve reuse
- The openness allows for more reuse and hence faster development
- Quality assurance
- More eyes on code is always a good thing to ensure quality
- Standards emerge and can be easily enforced in a cross-cutting manner, ie. across the organisation’s landscape
- The main theme which enables every other aspect of Inner Source to work
- Enables open innovation
- Without it, Inner Source will definitely fail
- Knowledge sharing
- Broadening of expertise as there will be a larger developer pool acting as a community
- This is also an incentive to keep good engineers and developers
- A community of sharing knowledge creates an environment of great growth which in turn helps retain good engineers and developers
- The openness creates more accountability within the community of developers, and subsequently people bring out their best and grow
Now we can strategically think of a way to manage an Inner Sourced project.
Inner Source Project Management: The correct mindset
Just as Open Source is mostly about self-organising, so is Inner Sourcing. This means a hierarchical structure will most likely fail to accommodate an Inner Sourcing software development model. There has to be as little resistance as possible to allow developers/engineers to do what they have to do. Nonetheless it is paramount for an Inner Source Project to be managed.
- Process management
- Project planning
- Monitoring and actioning
- Human issues
Process management speaks to the process of the work to be developed, release management, the process of contributing to a project to basically set the standards. Project planning refers to the general concept of planning a project ie. estimating time for tasks, resources needed etc. Monitoring and actioning are about checking the progress of the project and making changes where required in order to meet expectations or set new ones (this is where quality is usually scrutinised). Human issues speak to communication, communication, communication.
There’s nothing worse than information overload, which is why I will only wrap up Inner Source project management in the second part of episode Part II.b. In this blog I will discuss in a more diagrammatic way how you could manage an Inner Sourced project with our goals and correct mindset described earlier in mind.
- PDF | Inner Source Project Management. Available from: https://www.researchgate.net/publication/267863737_Inner_Source_Project_Management.
by Mthokozisi Myeza