New pattern proposal: InnerSource Hackathon #700
Conversation
spriya-m
requested review from
lenucksi,
NewMexicoKid,
cewilliams,
spier,
robtuley and
yuhattor
as code owners
|
💖 Thanks for opening this pull request! 💖 The InnerSource Commons community really appreciates your time and effort to contribute to the project. Please make sure you have read our Contributing Guidelines. If you are submitting a new pattern, the following things will help get your pull request across the finish line! 🏁
This project has a small number of maintainers, volunteering their time to this project. So please be patient and we will get back to you as soon as we can. If we don't acknowledge this pull request after 7 days, feel free to chat to us about it in our Slack workspace. |
|
|
||
| ## Problem | ||
|
|
||
| The company wants to adopt InnerSource as software development methodology but only those familiar with open source principles or those who understand the benefits of InnerSource, adopt it. It results in just a handful of InnerSource projects and is difficult to scale beyond that. |
There was a problem hiding this comment.
Would you do that purely as a Hackthon targeted at learning about InnerSource best practices?
I'm asking because reading your suggested pattern, made me remember some of the very early InnerSource days at my employer: There was a yearly hackathon established already. Participating teams decided to try out InnerSource best practices there early on - come to think of it, that was one of the occasions where best practices spread across team boundaries.
There was a problem hiding this comment.
Yes, the goal is to make the engineering community learn about InnerSource best practices. When ISPO or sometimes OSPO (driving InnerSource as well) is not able to reach the entire engineering community, then such an event would help draw some attention.
Just out of curiosity, the yearly hackathon that you mentioned - was it specific to InnerSource? If so, can we quote it as a known instance?
There was a problem hiding this comment.
The one I mentioned wasn't specific to InnerSource - it had been established long before the InnerSource initiative.
What happened was that some Hackathon teams would naturally adopt InnerSource for those few days to try it out. As a result the practice was adopted by new teams afterwards.
I think this shows just how strong a Hackathon as a pattern is: Even if it is not focused 100% on spreading the practice of InnerSource it still helps teams adopt those new ways of working. We could extend the pattern such that there are two Hackathon options - those organised by ISPO/OSPO and 100% geared towards InnerSource exercises plus more generic Hackathons than we can of course include my employer as well.
|
|
||
| ## Patlet | ||
|
|
||
| In a company, initially only InnerSource enthusiasts are interested and practicing InnerSource during the early stages of InnerSource adoption; not all engineering teams are willing or have enough time and resources to adopt InnerSource. In this scenario, it is good to provide a safe space to try and adopt InnerSource through an InnerSource Hackathon event within the company. |
There was a problem hiding this comment.
I love this pattern because it ties into the crossing the chasm pattern: It's a lovely way to get people to practice instead of only learn or hear about best practices.
|
|
||
| Apart from the reasons listed in the Context section, there are other factors from different entities that prevent teams from adopting InnerSource like: | ||
|
|
||
| * From middle management: perception of no direct benefit to the team apart from team upskilling and individual growth; eventually resulting in no motivation by the middle management to the engineers in trying out InnerSource ways of working. |
There was a problem hiding this comment.
@spier we already have some patterns addressing push back like that - do you think it would make sense to link to those from here?
E.g.: Change middle management mindset, Developer incentive alignment, Incentivise voluntary contributions, Overcome time constraints?
There was a problem hiding this comment.
Nice thought! We certainly could link to some of these, yes.
Just note that those other patterns have not reached the "Structured" maturity level yet. i.e. they may have not bee confirmed by an organization that used these patterns.
There was a problem hiding this comment.
Oh, right. Is there another good place to track these links?
There was a problem hiding this comment.
Have no good yet, no.
Will just leave this conversation open, while already going ahead and merging the PR.
|
|
||
| ## Solution | ||
|
|
||
| Organize a company wide hackathon focused on InnerSource. An InnerSource hackathon provides a safe space for engineers to try and contribute to InnerSource projects without any presumption and prejudice. It could be a 1 or 2 day event. |
There was a problem hiding this comment.
Thinking of different organisational sizes - do you think there is a sweet spot where company wide makes sense vs. at which point it gets too large to be effective?
There was a problem hiding this comment.
I agree to your point - maybe it can be conducted as a business unit level in large organizations?
There was a problem hiding this comment.
Also depends on what you want to achieve with InnerSource in the first place.
e.g. if the purpose is to encourage re-use across department borders in a large multi-national org, then you would likely want the hackathon to span all those departments. Even if that means that the hackathon becomes larger.
Different hackathon formats and sizes have different pros and cons. But I think all of them can be effective. Sometimes you have to "encourage then good" e.g. for the prior example of the multi-national org, if you want cross-team collaboration to happen, then you can setup soft rules like "only teams that contain members from at least 2 different teams from 2 separate engineering offices are considered when choosing an overall winner".
|
|
||
| Organize a company wide hackathon focused on InnerSource. An InnerSource hackathon provides a safe space for engineers to try and contribute to InnerSource projects without any presumption and prejudice. It could be a 1 or 2 day event. | ||
|
|
||
| It can preferrable be organized by InnerSource Program Office (ISPO), if it exists in the organization or by the Open Source Program Office (OSPO), if OSPO also drives InnerSource within the company. It can also be organized by other common service organizations too, if need be. Basically a central team or a group of individuals, who believe in InnerSource, can organize the hackathon. |
There was a problem hiding this comment.
Would piggy-backing on an existing hackathon work as well?
There was a problem hiding this comment.
IMO, piggy-backing with another hackathon would dilute the focus on InnerSource. Having said that, it depends on each company too. For a company in early stages of InnerSource with not many InnerSource practitioners, it is better to have it focused just on InnerSource.
There was a problem hiding this comment.
Now that I read this: In my case, where piggy-packing did happen, it occured at a later stage where several engineers already had experience. Essentially we started with the "get started as an experiment", scaled in a sub org after that and crossed towards other departments through the hackathon.
So maybe the piggy-backed version of this pattern would then work better for companies that already have several practitioners to carry adoption further. Maybe also to carry learnings concerning the practice between teams.
|
@MaineC , thank you very much for your review and comments. Really appreciate it. |
spier
added
1-initial
There was a problem hiding this comment.
Great job @spriya-m. In its current form this is already such an amazingly strong pattern, and that even without receiving any other feedback from the community here, right? Really amazing!
I left some comments inline that I hope you will find helpful.
I am quite confident that we can get this merged rather quickly with a few rounds of feedback and smaller. improvements.
Again great job!
|
|
||
| ## Solution | ||
|
|
||
| Organize a company wide hackathon focused on InnerSource. An InnerSource hackathon provides a safe space for engineers to try and contribute to InnerSource projects without any presumption and prejudice. It could be a 1 or 2 day event. |
There was a problem hiding this comment.
Also depends on what you want to achieve with InnerSource in the first place.
e.g. if the purpose is to encourage re-use across department borders in a large multi-national org, then you would likely want the hackathon to span all those departments. Even if that means that the hackathon becomes larger.
Different hackathon formats and sizes have different pros and cons. But I think all of them can be effective. Sometimes you have to "encourage then good" e.g. for the prior example of the multi-national org, if you want cross-team collaboration to happen, then you can setup soft rules like "only teams that contain members from at least 2 different teams from 2 separate engineering offices are considered when choosing an overall winner".
| @@ -0,0 +1,80 @@ | |||
| ## Title | |||
|
|
|||
| InnerSource Hackathon | |||
There was a problem hiding this comment.
Just brainstorming:
If you could not use "InnerSource" in the title, how might you call this pattern?
There was a problem hiding this comment.
I am not sure. The closest I can think off is - 'Hackathon: Safe experiment space', but I feel it doesn't sound right. I took inspiration from other patterns - InnerSource Portal and InnerSource License, which give the user a good understanding of what to expect in the pattern, just by the title.
Please feel free to suggest one :)
There was a problem hiding this comment.
Naming things is hard, as we know ;)
I don't have a better idea right now idea.
I asked about this because all of these are InnerSource patterns, so naturally the word InnerSource will appear in a lot of places. Therefore we try to not overuse the word in the pattern titles, to distinguish the patterns from each other a bit more.
For now:
Let's just keep the title as is.
Once the patterns matures more through feedback from other organizations, maybe we have an idea for a different title.
There was a problem hiding this comment.
Maybe it would help to include something that the Hackathon achieves in the title?
Something that expresses the gained practical experience?
Though I can follow the argument of @spriya-m referring to InnerSource Portal and -License as examples.
Co-authored-by: Sebastian Spier <[email protected]>
|
@spier , thank you very much for your comments and review. I really appreciate it. Do you think it qualifies for 2-structured category of patterns? :) |
Co-authored-by: Sebastian Spier <[email protected]>
| @@ -0,0 +1,80 @@ | |||
| ## Title | |||
|
|
|||
| InnerSource Hackathon | |||
There was a problem hiding this comment.
Naming things is hard, as we know ;)
I don't have a better idea right now idea.
I asked about this because all of these are InnerSource patterns, so naturally the word InnerSource will appear in a lot of places. Therefore we try to not overuse the word in the pattern titles, to distinguish the patterns from each other a bit more.
For now:
Let's just keep the title as is.
Once the patterns matures more through feedback from other organizations, maybe we have an idea for a different title.
Hi @spriya-m. Technically the pattern would already qualify as 2-structured, as there is an (anonymous) known instances. However when new patterns are proposed, we do recommend that they stay in 1-initial for a while, allowing us to harden the quality over time by getting some more eyeballs from the community on it. I left some more comments. Just see if those are helpful. Also, could you check if you have allowed code contributions to your PR? I was trying to push a commit through git but could not do so. Thank you. I think we should try get this pattern merged pretty quickly, and do further improvements in future PRs. Iterations for the win :) |
Co-authored-by: Sebastian Spier <[email protected]>
Co-authored-by: Sebastian Spier <[email protected]>
Hi @spier , sure no problem. This pattern can be in 1-initial category for now. I have already enabled 'Allow edits by maintainers' and have now added you as a collaborator to the fork. I guess you should be able to commit changes now. Please let me know if anything needs to be updated in the content. Some of the comments are like discussion and I am not sure if I need to update the content. Please let me know. |
Strange, I can still not push to your branch. Possibly because that would mean making commits to your Either way, I can work around this. Will now merge this branch, and then make changes to the content in the upstream repo directly. |
|
|
|
Thank you @spriya-m for contributing the InnerSource Hackathon pattern :) The pattern is now available in the main repo here. I am leaving the discussion threads open on this pattern, so that we can review them again when upgrading this pattern to the next maturity level in the future. Feel free to share this pattern wherever you like. The more eyeballs we can get onto this, the better! Thanks again 💐 |
Hi, I would like to propose a new pattern called InnerSource Hackathon.
For organizations looking for scaling InnerSource or driving InnerSource ways of working among the engineering community, such an event would help to not only spread the word about InnerSource faster but also provide a safe environment to try out InnerSource ways of working.
Please let me know your comments.