Feedback to PR #481 - Introduction - Is InnerSource Right for My Project
Closed this issue · 12 comments
Hello, I'd like to leave some feedback for #481.
An InnerSource approach only makes sense if contributions are expected from the project's users.
I often advocate that an InnerSource approach makes sense even if the maintainers of a project do not expect contributions, as adopting InnerSource practices have other positive side-effects/byproducts, besides contributions (specially when speaking of code contributions):
- Shaping a project to receive external contributions also makes it easier to onboard new team members, as it lowers the bar to start working on the project
- Adopting the practice of keeping an open, well documented and-up-to-date backlog and transparent and traceable means of communication could help improve the trust from stakeholders and also encourage stakeholders to get involved into ongoing discussions and provide early feedback (where otherwise this would not be possible)
- Learning, knowledge sharing and handover - adopting the practice mentioned on the previous bullet, in combination with a well documented project (in terms of architecture, business requirements and development processes) makes the project a reference for learning and knowledge sharing, and also facilites handing over the project if needed, creating a more flexible workforce setup
Also, I like to promote the idea of "Agile InnerSource Adoption" (just created the name) - in other words, adopting InnerSource is done in small value-adding steps that are tracked as part of the project backlog (i.e., document onboarding steps, document development processes, open up backlog, adopt, start accepting contributions from the outward in - e.g. docu first, then client libs, then service, etc...).
With that in mind, I think InnerSource is only not suitable for confidential projects. Even then there are ways of adopting some of the practices (referring here to the CLOSED and RESTRICTED repos on the Balancing Opennes and Security pattern).
All the rest is pretty good.
Thanks, @dellagustin-sap ❗ I feel like your could be its own article - called something like "InnerSource Everywhere!" That article can advocate for running everything as InnerSource without any qualification.
I think it's OK for different articles to contradict one another as long as each is focused, clear, and consistent on its own. Then people can mix and match out of our cadre of articles with InnerSource advice.
Maybe over time we can come up with different tags to help people navigate and find which articles are useful to them based on attributes and surrounding context or culture or goals that is present in their business environment.
Hello @rrrutledge , one aspect of my feedback - I did not take the context of where the text would be into consideration - I tried to find back then where it was published, but could not find in the website - where is this article published? That can help me understand it better - I like the idea this "InnerSource Everywhere!" article.
Maybe over time we can come up with different tags to help people navigate and find which articles are useful to them based on attributes and surrounding context or culture or goals that is present in their business environment.
In that regard of a structure: I think the Mindmap concept Feiwan contributed to the patterns WG might possibly be worth considering here too.
where is this article published?
@dellagustin-sap it isn't published, yet, but we'll plan to have it as a companion to these articles: https://innersourcecommons.org/learn/learning-path/introduction/
Would you be interested in working on an "InnerSource Everywhere!" article?
I'm interested, are there any deadlines or can I do it on my pace?
No deadlines! I created the issue InnerSource Everywhere! Article to track and sent you an invite to join the project.
The issue shows up on our Kanban board so we will track and support it in that way.
I, myself, will probably need this segment at my day job anyway and so will be happy to review it with you.
@rrrutledge great, thanks, could you please also add my other GitHub user, @dellagustin? I use two separate users so that I can have a clear separation between on-the-job contributions and spare time contributions.
With that, I'll close this issue, as from my point of view the topic will be followed up on #494.
Sounds great - thank you!
Closing this as future work will be tracked in #494. Thank you for sharing your ideas @dellagustin-sap! Looking forward to seeing the new content.