Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feedback to PR #481 - Introduction - Is InnerSource Right for My Project #489

Closed
dellagustin-sap opened this issue Aug 10, 2022 · 12 comments

Comments

@dellagustin-sap
Copy link
Collaborator

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.

@dellagustin-sap dellagustin-sap changed the title Feedback to PR #481 Feedback to PR #481 - Introduction - Is InnerSource Right for My Project Aug 10, 2022
@rrrutledge
Copy link
Contributor

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.

@rrrutledge
Copy link
Contributor

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.

@rrrutledge
Copy link
Contributor

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.

@dellagustin-sap
Copy link
Collaborator Author

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.

@lenucksi
Copy link
Member

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.

@rrrutledge
Copy link
Contributor

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?

@dellagustin-sap
Copy link
Collaborator Author

I'm interested, are there any deadlines or can I do it on my pace?

@rrrutledge
Copy link
Contributor

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.

@dellagustin-sap
Copy link
Collaborator Author

dellagustin-sap commented Aug 31, 2022

@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.

@dellagustin-sap
Copy link
Collaborator Author

With that, I'll close this issue, as from my point of view the topic will be followed up on #494.

@rrrutledge
Copy link
Contributor

Sounds great - thank you!

@tsadler1988
Copy link
Collaborator

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants