InnerSourceCommons
Pattern idea: All Roads Lead to InnerSource (Contributions)
This is a placeholder to create a Draft Pull request. At this point I only worked on the Title and Problem.
The overall idea is to consider that all content related to a project, including the resulting deliverable, as a potential first touch point of consumers and stakeholders with the project, thus using this as an opportunity to inform and convert those into contributors, as well as raising their awareness of InnerSource as a practice. One of the solutions, for example, is that a user of an application should be able to easily find that this software is the result of an InnerSource project, that contributions are possible and how they can be done, directly form the software user interface.
Thank you for sharing this idea @dellagustin.
Do you already have a solution in mind for this? Some recipes that a project can relatively easy follow to get better at this?
It would be great to describe common examples of the public content/assets that an InnerSource project typically has, and how that content can be improved to increase the chance of converting users into contributors.
I was also wondering if there are assets that a project keeps private on purpose, and hence within these assets the team does not have to think about external parties as much.
Maybe part of the solution is to help the team switch mindset appropriately, depending on which asset they are working on?
Hi @spier , thank you for your comment (a good example of why transparency over work in progress is great for early feedback), some replies below.
On:
Do you already have a solution in mind for this? Some recipes that a project can relatively easy follow to get better at this?
It would be great to describe common examples of the public content/assets that an InnerSource project typically has, and how that content can be improved to increase the chance of converting users into contributors.
I have some examples of solutions to share, and one of them is referring to the pattern Standard Base Documentation and possibly others. I'm planning also to share some practical examples.
On:
I was also wondering if there are assets that a project keeps private on purpose, and hence within these assets the team does not have to think about external parties as much.
Unless it is confidential, I prefer to keep it public but with a disclaimer and a direction to the correct place, my philosophy is "as open as possible, as close as necessary".
Here I quote a small fraction of an internal content we have from the nice folks from our New Work Movement on Transparency and Open Communication:
"In traditional organizations, information is power. Progressive organizations leans towards radical transparency, where everything and anything going on in the organization is freely and openly shared. This shift is necessary because in complex systems, it’s hard to predict what information will be needed where, when, and by whom."
@dellagustin-sap thank you again for sharing your idea here. Would you like some help in adding more flesh to the pattern draft? What would be a good next step? Happy to help!
Hi @spier , thank you for the (necessary) reminder. I worked a little bit more on it and added a solution to the draft. Before moving forward I'll ask for some feedback on the patterns slack channel just to check if the problem/context/solution are understandable and make sense.
P.S.: while researching a bit for similar concepts, I think there are some synergies of this pattern with the concept of "customer journey mapping", that's something that might be worth exploring, adapting it to "contributor journey mapping".