OSPOlogy Germany: InnerSource Roundtables - Summary Notes #377
Replies: 4 comments 2 replies
-
|
Amazing amount of detail in these notes @dellagustin-sap! |
Beta Was this translation helpful? Give feedback.
-
|
@dellagustin-sap is there more that you can share about "the current state of the InnerSource journey of their companies"? I am especially interested in:
|
Beta Was this translation helpful? Give feedback.
-
|
Hello @spier , there is not much to add to what I already shared. As I guess is the norm on this roudtables, we discussed more about challenges than solutions 😄 . There was on interesting practice that was shared there: automatically creating a DRAFT empty PR assigned to issue reporters, to give it a little push so that a solution is contributed. That requires some automation to send reminders and close stale PRs after some time. |
Beta Was this translation helpful? Give feedback.
-
|
Hehe yeah I know, we all love problems and forget what already works, don't we? :) That "auto empty DRAFT PR" sounds interesting. Of course even better in they can join the InnerSource Commons Slack, to chat with us there :) |
Beta Was this translation helpful? Give feedback.
-
|
Thank you! ❤️ Added to the OSPOlogyLive knowledge archive: https://github.com/todogroup/ospology/blob/main/ospology-live/2023-october-germany/README.md |
Beta Was this translation helpful? Give feedback.
-
|
This is great - thanks @dellagustin-sap . Some content here to augment our patterns and books in the InnerSource Commons for sure. |
Beta Was this translation helpful? Give feedback.
-
We recently had the OSPOlogy Live event in Frankfurt, and I moderated two roundtables about InnerSource.
We had a diverse set of participants and had some very interesting discussions. The format was very much freestyle, but we began each roundtable with an introduction round where each participant was also encouraged to share the current state of the InnerSource journey of their companies.
Among the topics we had:
I'll try to put some more words on each of the topics.
Frozen Middle
One of the problems here is that often the support of executives does not come with concrete incentives. Even when InnerSource is desired, it is possible that the incentives and KPIs cascaded through the middle management would not support its adoption (e.g., maintaining siloes and individual goals).
One reference for a company that adjusted its incentive structure to support collaboration is Microsoft, who reportedly has 1/3 of their goals tied to collaboration (the reference I have for this information is https://dev.to/betatalks/8-github-innersource-and-the-benefits-of-an-asynchronous-and-knowledge-sharing-culture-with-martin-woodward).
Adapting the existing KPIs and incentive structures is not an easy task, so it may be interesting to look at other alternatives in parallel that could produce results earlier, such as dedicated InnerSource awards.
One idea that came to my mind afterwards is to create dedicated material for developers to talk about InnerSource with their managers (e.g., highlighting the benefits) and later run a campaign to foster these talks.
Tax and Transfer pricing
This is a topic that affects InnerSource programs differently. We could see in our conversations that some programs are challenged with it early on, where others don't consider this an InnerSource problem.
When is it not considered an InnerSource problem? When companies already had some form of cross legal entity reuse and collaboration prior to InnerSource. Well, it is still an InnerSource problem, but one that is not introduced by InnerSource, so some InnerSource programs assume that this is solved due to previous conditions.
It is a challenging topic that is not yet solved for many, and also, existing solutions were mostly not "battle tested".
It adds up to the challenge that this is considered a sensitive topic and companies are not always willing to share their solutions, possibly, because there is a lot of uncertainty surrounding the topic.
Discoverability and Tooling
This is an evolving topic. We have some well known tools to tackle it, as SAP's InnerSource Projects portal and backstage, but none is a definitive solution (see the InnerSource Commons pattern InnerSource Portal). SAP's solution is a good reference implementation and works reasonably well for a limited number of projects, but it would not scale to a large number. Additionally, it is not being actively enhanced at the moment. Backstage is reportedly hard to adopt and use for this purpose, requiring a lot of effort to adopt and maintain. It should be noted that it is not a tool dedicated exclusively to this purpose.
How to scale InnerSource
There are many dimensions here. One thing we discussed is that depending on the company's environment and culture, a sustained effort to drive InnerSource adoption is required, as quitting this effort could easily lead to regression.
We also discussed that often we try to shape the journey of a contributor to go directly from "use" to "contribute", but it would be good to also ensure that there is a "participate" step in between, largely related to becoming part of a community. This would ease the journey to contribution and also generate value on its own. Being able to participate on the project's community, or even observe it, could ease the fears of openly communicating and sharing. This also goes into the direction of creating an environment of psychological safety and reduction of cognitive load, making it as easy and safe to contribute as possible.
Source code visibility
This is again a topic that is quite diverse. For some companies, this is even related to the "Tax and Transfer pricing" topic, where there is "gate" before being able to publish code (internally) to safeguard from compliance issues. Other companies have a "public first" guidance. There are also companies that are on a "limbo" meaning that code visibility follows an emergent pattern that comes from existing policies (not necessarily created with InnerSource in mind), development culture and default system setup, but are at risk of sudden changes due to lack of global policy or strategy dedicate to the topic.
Here, the InnerSource Commons Pattern Balancing Openness and Security (Maturity Level 1: Initial) can be a good starting point for this topic.
Additionally, there is an open Pull Request to the book "Managing Inner Source Projects" (InnerSourceCommons/managing-innersource-projects#22) which contains an interesting write up on the Security vs InnerSource dilemma (https://github.com/InnerSourceCommons/managing-inner-source-projects/blob/792bab6cf07510f9a00fa34008a2568ab79e5ad0/tooling/github-strategy.md)
Metrics
When we discussed metrics, the focus was on identifying and measuring InnerSource contributions.
This supported different goals:
One of the difficulties of identifying such contributions is that there is no standard way of identifying contributors and maintainership (or ownership) of a given project.
One option would be to use LDAP information, but that could still require some heuristic. Historical data (top contributor was part of the maintainers, but not anymore) may not be available.
Any solution here that requires project maintainers to manually maintain information about who is or isn't a maintainer/core team member, besides the required technical setup in their source code system, should give back some value to the maintainers themselves. Otherwise, this information is likely be unreliable.
To identify projects receiving InnerSource contributions, one option could be to use a "proxy metric", like for instance number of contributors divided by the number of commits or code lines, where a higher number likely indicates a higher number of InnerSource contributions.
Misc and closing words
It should go without saying, but many participants were members of the InnerSource Commons community, so ISC work, especially patterns, was often referenced and recommended in our discussions.
This was a great opportunity to meet face to face and we had an open and lively discussion.
I'm sure I only captured here a tiny fraction of all the aspects we discussed, but the knowledge and experience sharing were just invaluable.
I'll invite everyone else who participated to complement these notes and share their impressions, or even correct me if I misunderstood something.
I hope to see you all again soon!
Beta Was this translation helpful? Give feedback.
All reactions