From 12b38c12ae59fdac943969790471b4eb1cb484fd Mon Sep 17 00:00:00 2001 From: Shanmugapriya M Date: Thu, 27 Jun 2024 11:16:17 +0200 Subject: [PATCH 01/15] create innersource-hackathon.md --- patterns/1-initial/innersource-hackathon.md | 76 +++++++++++++++++++++ 1 file changed, 76 insertions(+) create mode 100644 patterns/1-initial/innersource-hackathon.md diff --git a/patterns/1-initial/innersource-hackathon.md b/patterns/1-initial/innersource-hackathon.md new file mode 100644 index 000000000..1565b0749 --- /dev/null +++ b/patterns/1-initial/innersource-hackathon.md @@ -0,0 +1,76 @@ +## Title + +InnerSource Hackathon + +## 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. + +## 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. + +## Context + +Scenario 1: +The senior leadership believes in InnerSource and wants to drive it throughout the company. The engineers who are familiar with open source principles and/or understand the benefits of InnerSource are the early adopters. There is success with these initial pilot project and teams. Now the next step is to drive it across the company. There might be reluctance from engineering teams due to various factors like: +- not familiar with InnerSource and being ignorant to know about it +- not enough time to prioritize InnerSource, given the regular work deliverables +- relunctance to changing ways of working when everything works well already +- perception that InnerSource requires more work and responsibilities + +Scenario 2: +Teams slowly start adopting InnerSource and open up their repositories. Some new projects are started as InnerSource projects from the start (that is open for contributions). However, there are not many contributors. It is also challenging to build a community around those projects, in spite of publishing the projects in an InnerSource Portal. This could be due to various reasons like: +- engineers do not have time to explore new InnerSource projects and contribute, outside regular work deliverables +- no additional incentive to this effort apart from being acknowledged +- lack of motivation by middle management + +## Forces + +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. +- From engineers: investing time to try new ways of working when there is already time and resource constraint for regular work deliverables; it is also challenging to balance both and show outcomes in both; this curbs motivation from the engineers as there is little safe space to experiment. +- From senior leadership: not prioritizing investment in InnerSource ways of working such as it being part of long term goals or OKRs. + +For those new to InnerSource or any technology/methodology, there is a need for safe space to try and experiment without definite outcomes in the initial stages. These factors and forces hinder such an experiment ground. + +## 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. + +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. + +All engineers in the organization can participate in the hackathon. The participants can be new to InnerSource, or InnerSource practitioners already. They can participate individually or as a team. Participating as a team also provides a safe environment, for example, those are new to InnerSource can team up InnerSource practitioners. + +There could be one or more categories to participate as follows: +- Start a new InnerSource project: It could be either starting a new project from scratch as InnerSource or making a existing project InnerSource ready. +- Contribute to the existing InnerSource project: InnerSource project owners can list down the features in GitHub issues as a pre-requisite before the hackathon and the participants can contribute to it during the hackathon. +- Participate as an InnerSource mentor: Participants can also mentor new InnerSource practitioners and provide knowledge transfer or coaching during the event. + +The event could be held virtually or physically in different locations in the organization based on the cost and budget involved. A virtual event will have best ROI but it could depend on each organization. + +The winners and participants should be recognized and acknowledged in a company wide forum at the end of the hackathon. This is important as it keeps motivating them and more engineers to adopt and practice InnerSource going forward. + +Such an event provides a safe space for the engineers who want to adopt or contribute to InnerSource but didn't have the time and motivation to do it or for those who kept deprioritizing due to high priority work deliverables. From middle management point of view, 1 or 2 days for such an event is not much of an ask and hence they are more likely to accept. + +## Resulting Context + +- There is increased adoption of InnerSource by providing such a safe platform to try and experiment combined with recognition and support by the senior leadership and middle management. +- It results in more projects being made InnerSource ready and innersourced, and also results in more InnerSource contributions and start building community around existing InnerSource projects. +- This happens not only during the event but continues after the event too, with the hackathon participants acting as InnerSource ambassadors in their teams. +- It also helps ISPO and OSPO spread awareness about InnerSource best practices quickly, across the whole engineering community in the organization. +- Such an event also helps discover some cool hobby projects that were developed to solve the needs of a specific team but turns out that many teams have similar requirements. + +All these help scale InnerSource in the organization. + +## Known Instances + +- Retail company in northern Europe + +## Status + +* Initial + +## Author + +* Shanmugapriya Manoharan From e095c2e24c8e74bbbc3039539be9f4675b555c54 Mon Sep 17 00:00:00 2001 From: Shanmugapriya M Date: Thu, 27 Jun 2024 12:15:45 +0200 Subject: [PATCH 02/15] fix lint issues --- patterns/1-initial/innersource-hackathon.md | 38 ++++++++++----------- 1 file changed, 19 insertions(+), 19 deletions(-) diff --git a/patterns/1-initial/innersource-hackathon.md b/patterns/1-initial/innersource-hackathon.md index 1565b0749..17a8d44c7 100644 --- a/patterns/1-initial/innersource-hackathon.md +++ b/patterns/1-initial/innersource-hackathon.md @@ -4,7 +4,7 @@ InnerSource Hackathon ## 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. +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. ## Problem @@ -12,56 +12,56 @@ The company wants to adopt InnerSource as software development methodology but o ## Context -Scenario 1: +Scenario 1: The senior leadership believes in InnerSource and wants to drive it throughout the company. The engineers who are familiar with open source principles and/or understand the benefits of InnerSource are the early adopters. There is success with these initial pilot project and teams. Now the next step is to drive it across the company. There might be reluctance from engineering teams due to various factors like: - not familiar with InnerSource and being ignorant to know about it - not enough time to prioritize InnerSource, given the regular work deliverables - relunctance to changing ways of working when everything works well already - perception that InnerSource requires more work and responsibilities -Scenario 2: -Teams slowly start adopting InnerSource and open up their repositories. Some new projects are started as InnerSource projects from the start (that is open for contributions). However, there are not many contributors. It is also challenging to build a community around those projects, in spite of publishing the projects in an InnerSource Portal. This could be due to various reasons like: +Scenario 2: +Teams slowly start adopting InnerSource and open up their repositories. Some new projects are started as InnerSource projects from the start (that is open for contributions). However, there are not many contributors. It is also challenging to build a community around those projects, in spite of publishing the projects in an InnerSource Portal. This could be due to various reasons like: - engineers do not have time to explore new InnerSource projects and contribute, outside regular work deliverables - no additional incentive to this effort apart from being acknowledged - lack of motivation by middle management ## Forces -Apart from the reasons listed in the Context section, there are other factors from different entities that prevent teams from adopting InnerSource like: +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. -- From engineers: investing time to try new ways of working when there is already time and resource constraint for regular work deliverables; it is also challenging to balance both and show outcomes in both; this curbs motivation from the engineers as there is little safe space to experiment. +- From engineers: investing time to try new ways of working when there is already time and resource constraint for regular work deliverables; it is also challenging to balance both and show outcomes in both; this curbs motivation from the engineers as there is little safe space to experiment. - From senior leadership: not prioritizing investment in InnerSource ways of working such as it being part of long term goals or OKRs. -For those new to InnerSource or any technology/methodology, there is a need for safe space to try and experiment without definite outcomes in the initial stages. These factors and forces hinder such an experiment ground. +For those new to InnerSource or any technology/methodology, there is a need for safe space to try and experiment without definite outcomes in the initial stages. These factors and forces hinder such an experiment ground. ## 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. +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. +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. All engineers in the organization can participate in the hackathon. The participants can be new to InnerSource, or InnerSource practitioners already. They can participate individually or as a team. Participating as a team also provides a safe environment, for example, those are new to InnerSource can team up InnerSource practitioners. -There could be one or more categories to participate as follows: -- Start a new InnerSource project: It could be either starting a new project from scratch as InnerSource or making a existing project InnerSource ready. -- Contribute to the existing InnerSource project: InnerSource project owners can list down the features in GitHub issues as a pre-requisite before the hackathon and the participants can contribute to it during the hackathon. +There could be one or more categories to participate as follows: +- Start a new InnerSource project: It could be either starting a new project from scratch as InnerSource or making a existing project InnerSource ready. +- Contribute to the existing InnerSource project: InnerSource project owners can list down the features in GitHub issues as a pre-requisite before the hackathon and the participants can contribute to it during the hackathon. - Participate as an InnerSource mentor: Participants can also mentor new InnerSource practitioners and provide knowledge transfer or coaching during the event. -The event could be held virtually or physically in different locations in the organization based on the cost and budget involved. A virtual event will have best ROI but it could depend on each organization. +The event could be held virtually or physically in different locations in the organization based on the cost and budget involved. A virtual event will have best ROI but it could depend on each organization. -The winners and participants should be recognized and acknowledged in a company wide forum at the end of the hackathon. This is important as it keeps motivating them and more engineers to adopt and practice InnerSource going forward. +The winners and participants should be recognized and acknowledged in a company wide forum at the end of the hackathon. This is important as it keeps motivating them and more engineers to adopt and practice InnerSource going forward. -Such an event provides a safe space for the engineers who want to adopt or contribute to InnerSource but didn't have the time and motivation to do it or for those who kept deprioritizing due to high priority work deliverables. From middle management point of view, 1 or 2 days for such an event is not much of an ask and hence they are more likely to accept. +Such an event provides a safe space for the engineers who want to adopt or contribute to InnerSource but didn't have the time and motivation to do it or for those who kept deprioritizing due to high priority work deliverables. From middle management point of view, 1 or 2 days for such an event is not much of an ask and hence they are more likely to accept. ## Resulting Context - There is increased adoption of InnerSource by providing such a safe platform to try and experiment combined with recognition and support by the senior leadership and middle management. - It results in more projects being made InnerSource ready and innersourced, and also results in more InnerSource contributions and start building community around existing InnerSource projects. -- This happens not only during the event but continues after the event too, with the hackathon participants acting as InnerSource ambassadors in their teams. +- This happens not only during the event but continues after the event too, with the hackathon participants acting as InnerSource ambassadors in their teams. - It also helps ISPO and OSPO spread awareness about InnerSource best practices quickly, across the whole engineering community in the organization. -- Such an event also helps discover some cool hobby projects that were developed to solve the needs of a specific team but turns out that many teams have similar requirements. +- Such an event also helps discover some cool hobby projects that were developed to solve the needs of a specific team but turns out that many teams have similar requirements. -All these help scale InnerSource in the organization. +All these help scale InnerSource in the organization. ## Known Instances @@ -73,4 +73,4 @@ All these help scale InnerSource in the organization. ## Author -* Shanmugapriya Manoharan +* Shanmugapriya Manoharan \ No newline at end of file From b35000fbfb6a12812658cc2d887f507213ad5927 Mon Sep 17 00:00:00 2001 From: Shanmugapriya M <97021994+spriya-m@users.noreply.github.com> Date: Thu, 27 Jun 2024 12:26:00 +0200 Subject: [PATCH 03/15] fix markdown lint issues --- patterns/1-initial/innersource-hackathon.md | 40 ++++++++++----------- 1 file changed, 20 insertions(+), 20 deletions(-) diff --git a/patterns/1-initial/innersource-hackathon.md b/patterns/1-initial/innersource-hackathon.md index 17a8d44c7..e32501bd7 100644 --- a/patterns/1-initial/innersource-hackathon.md +++ b/patterns/1-initial/innersource-hackathon.md @@ -14,23 +14,23 @@ The company wants to adopt InnerSource as software development methodology but o Scenario 1: The senior leadership believes in InnerSource and wants to drive it throughout the company. The engineers who are familiar with open source principles and/or understand the benefits of InnerSource are the early adopters. There is success with these initial pilot project and teams. Now the next step is to drive it across the company. There might be reluctance from engineering teams due to various factors like: -- not familiar with InnerSource and being ignorant to know about it -- not enough time to prioritize InnerSource, given the regular work deliverables -- relunctance to changing ways of working when everything works well already -- perception that InnerSource requires more work and responsibilities +* not familiar with InnerSource and being ignorant to know about it +* not enough time to prioritize InnerSource, given the regular work deliverables +* relunctance to changing ways of working when everything works well already +* perception that InnerSource requires more work and responsibilities Scenario 2: Teams slowly start adopting InnerSource and open up their repositories. Some new projects are started as InnerSource projects from the start (that is open for contributions). However, there are not many contributors. It is also challenging to build a community around those projects, in spite of publishing the projects in an InnerSource Portal. This could be due to various reasons like: -- engineers do not have time to explore new InnerSource projects and contribute, outside regular work deliverables -- no additional incentive to this effort apart from being acknowledged -- lack of motivation by middle management +* engineers do not have time to explore new InnerSource projects and contribute, outside regular work deliverables +* no additional incentive to this effort apart from being acknowledged +* lack of motivation by middle management ## Forces 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. -- From engineers: investing time to try new ways of working when there is already time and resource constraint for regular work deliverables; it is also challenging to balance both and show outcomes in both; this curbs motivation from the engineers as there is little safe space to experiment. -- From senior leadership: not prioritizing investment in InnerSource ways of working such as it being part of long term goals or OKRs. +* 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. +* From engineers: investing time to try new ways of working when there is already time and resource constraint for regular work deliverables; it is also challenging to balance both and show outcomes in both; this curbs motivation from the engineers as there is little safe space to experiment. +* From senior leadership: not prioritizing investment in InnerSource ways of working such as it being part of long term goals or OKRs. For those new to InnerSource or any technology/methodology, there is a need for safe space to try and experiment without definite outcomes in the initial stages. These factors and forces hinder such an experiment ground. @@ -43,9 +43,9 @@ It can preferrable be organized by InnerSource Program Office (ISPO), if it exis All engineers in the organization can participate in the hackathon. The participants can be new to InnerSource, or InnerSource practitioners already. They can participate individually or as a team. Participating as a team also provides a safe environment, for example, those are new to InnerSource can team up InnerSource practitioners. There could be one or more categories to participate as follows: -- Start a new InnerSource project: It could be either starting a new project from scratch as InnerSource or making a existing project InnerSource ready. -- Contribute to the existing InnerSource project: InnerSource project owners can list down the features in GitHub issues as a pre-requisite before the hackathon and the participants can contribute to it during the hackathon. -- Participate as an InnerSource mentor: Participants can also mentor new InnerSource practitioners and provide knowledge transfer or coaching during the event. +* Start a new InnerSource project: It could be either starting a new project from scratch as InnerSource or making a existing project InnerSource ready. +* Contribute to the existing InnerSource project: InnerSource project owners can list down the features in GitHub issues as a pre-requisite before the hackathon and the participants can contribute to it during the hackathon. +* Participate as an InnerSource mentor: Participants can also mentor new InnerSource practitioners and provide knowledge transfer or coaching during the event. The event could be held virtually or physically in different locations in the organization based on the cost and budget involved. A virtual event will have best ROI but it could depend on each organization. @@ -55,17 +55,17 @@ Such an event provides a safe space for the engineers who want to adopt or contr ## Resulting Context -- There is increased adoption of InnerSource by providing such a safe platform to try and experiment combined with recognition and support by the senior leadership and middle management. -- It results in more projects being made InnerSource ready and innersourced, and also results in more InnerSource contributions and start building community around existing InnerSource projects. -- This happens not only during the event but continues after the event too, with the hackathon participants acting as InnerSource ambassadors in their teams. -- It also helps ISPO and OSPO spread awareness about InnerSource best practices quickly, across the whole engineering community in the organization. -- Such an event also helps discover some cool hobby projects that were developed to solve the needs of a specific team but turns out that many teams have similar requirements. +* There is increased adoption of InnerSource by providing such a safe platform to try and experiment combined with recognition and support by the senior leadership and middle management. +* It results in more projects being made InnerSource ready and innersourced, and also results in more InnerSource contributions and start building community around existing InnerSource projects. +* This happens not only during the event but continues after the event too, with the hackathon participants acting as InnerSource ambassadors in their teams. +* It also helps ISPO and OSPO spread awareness about InnerSource best practices quickly, across the whole engineering community in the organization. +* Such an event also helps discover some cool hobby projects that were developed to solve the needs of a specific team but turns out that many teams have similar requirements. All these help scale InnerSource in the organization. ## Known Instances -- Retail company in northern Europe +* Retail company in northern Europe ## Status @@ -73,4 +73,4 @@ All these help scale InnerSource in the organization. ## Author -* Shanmugapriya Manoharan \ No newline at end of file +* Shanmugapriya Manoharan From 8e00bad6673c8ca72de0021da38ab79f291c9e66 Mon Sep 17 00:00:00 2001 From: Shanmugapriya M <97021994+spriya-m@users.noreply.github.com> Date: Thu, 27 Jun 2024 12:28:35 +0200 Subject: [PATCH 04/15] fix markdown lint issues --- patterns/1-initial/innersource-hackathon.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/patterns/1-initial/innersource-hackathon.md b/patterns/1-initial/innersource-hackathon.md index e32501bd7..756f1501e 100644 --- a/patterns/1-initial/innersource-hackathon.md +++ b/patterns/1-initial/innersource-hackathon.md @@ -14,6 +14,7 @@ The company wants to adopt InnerSource as software development methodology but o Scenario 1: The senior leadership believes in InnerSource and wants to drive it throughout the company. The engineers who are familiar with open source principles and/or understand the benefits of InnerSource are the early adopters. There is success with these initial pilot project and teams. Now the next step is to drive it across the company. There might be reluctance from engineering teams due to various factors like: + * not familiar with InnerSource and being ignorant to know about it * not enough time to prioritize InnerSource, given the regular work deliverables * relunctance to changing ways of working when everything works well already @@ -21,6 +22,7 @@ The senior leadership believes in InnerSource and wants to drive it throughout t Scenario 2: Teams slowly start adopting InnerSource and open up their repositories. Some new projects are started as InnerSource projects from the start (that is open for contributions). However, there are not many contributors. It is also challenging to build a community around those projects, in spite of publishing the projects in an InnerSource Portal. This could be due to various reasons like: + * engineers do not have time to explore new InnerSource projects and contribute, outside regular work deliverables * no additional incentive to this effort apart from being acknowledged * lack of motivation by middle management @@ -28,6 +30,7 @@ Teams slowly start adopting InnerSource and open up their repositories. Some new ## Forces 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. * From engineers: investing time to try new ways of working when there is already time and resource constraint for regular work deliverables; it is also challenging to balance both and show outcomes in both; this curbs motivation from the engineers as there is little safe space to experiment. * From senior leadership: not prioritizing investment in InnerSource ways of working such as it being part of long term goals or OKRs. @@ -43,6 +46,7 @@ It can preferrable be organized by InnerSource Program Office (ISPO), if it exis All engineers in the organization can participate in the hackathon. The participants can be new to InnerSource, or InnerSource practitioners already. They can participate individually or as a team. Participating as a team also provides a safe environment, for example, those are new to InnerSource can team up InnerSource practitioners. There could be one or more categories to participate as follows: + * Start a new InnerSource project: It could be either starting a new project from scratch as InnerSource or making a existing project InnerSource ready. * Contribute to the existing InnerSource project: InnerSource project owners can list down the features in GitHub issues as a pre-requisite before the hackathon and the participants can contribute to it during the hackathon. * Participate as an InnerSource mentor: Participants can also mentor new InnerSource practitioners and provide knowledge transfer or coaching during the event. From 04bee50db56203a2588ad3092a5086c63dba1873 Mon Sep 17 00:00:00 2001 From: Shanmugapriya M <97021994+spriya-m@users.noreply.github.com> Date: Sat, 29 Jun 2024 10:23:39 +0200 Subject: [PATCH 05/15] update patterns/1-initial/innersource-hackathon.md Co-authored-by: Sebastian Spier --- patterns/1-initial/innersource-hackathon.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/patterns/1-initial/innersource-hackathon.md b/patterns/1-initial/innersource-hackathon.md index 756f1501e..1b365a5d9 100644 --- a/patterns/1-initial/innersource-hackathon.md +++ b/patterns/1-initial/innersource-hackathon.md @@ -39,7 +39,7 @@ For those new to InnerSource or any technology/methodology, there is a need for ## 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. +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. From 380725d84741508c0bbd47d275fce75895b65c07 Mon Sep 17 00:00:00 2001 From: Shanmugapriya M <97021994+spriya-m@users.noreply.github.com> Date: Sat, 29 Jun 2024 11:15:42 +0200 Subject: [PATCH 06/15] update patterns/1-initial/innersource-hackathon.md Co-authored-by: Sebastian Spier --- patterns/1-initial/innersource-hackathon.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/patterns/1-initial/innersource-hackathon.md b/patterns/1-initial/innersource-hackathon.md index 1b365a5d9..d478d73a5 100644 --- a/patterns/1-initial/innersource-hackathon.md +++ b/patterns/1-initial/innersource-hackathon.md @@ -53,7 +53,7 @@ There could be one or more categories to participate as follows: The event could be held virtually or physically in different locations in the organization based on the cost and budget involved. A virtual event will have best ROI but it could depend on each organization. -The winners and participants should be recognized and acknowledged in a company wide forum at the end of the hackathon. This is important as it keeps motivating them and more engineers to adopt and practice InnerSource going forward. +The winners and participants should be recognized and acknowledged in a company-wide forum at the end of the hackathon. This is important as it keeps motivating them and more engineers to adopt and practice InnerSource going forward. Such an event provides a safe space for the engineers who want to adopt or contribute to InnerSource but didn't have the time and motivation to do it or for those who kept deprioritizing due to high priority work deliverables. From middle management point of view, 1 or 2 days for such an event is not much of an ask and hence they are more likely to accept. From c989135235213232c9083d8853d57ff892c5f02d Mon Sep 17 00:00:00 2001 From: Shanmugapriya M <97021994+spriya-m@users.noreply.github.com> Date: Mon, 1 Jul 2024 18:22:05 +0200 Subject: [PATCH 07/15] Update patterns/1-initial/innersource-hackathon.md Co-authored-by: Sebastian Spier --- patterns/1-initial/innersource-hackathon.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/patterns/1-initial/innersource-hackathon.md b/patterns/1-initial/innersource-hackathon.md index d478d73a5..6e3d17582 100644 --- a/patterns/1-initial/innersource-hackathon.md +++ b/patterns/1-initial/innersource-hackathon.md @@ -60,7 +60,9 @@ Such an event provides a safe space for the engineers who want to adopt or contr ## Resulting Context * There is increased adoption of InnerSource by providing such a safe platform to try and experiment combined with recognition and support by the senior leadership and middle management. -* It results in more projects being made InnerSource ready and innersourced, and also results in more InnerSource contributions and start building community around existing InnerSource projects. +* More InnerSource projects are published within the company. +* The InnerSource projects receive more contributions. +* Communities start to form around these InnerSource projects. * This happens not only during the event but continues after the event too, with the hackathon participants acting as InnerSource ambassadors in their teams. * It also helps ISPO and OSPO spread awareness about InnerSource best practices quickly, across the whole engineering community in the organization. * Such an event also helps discover some cool hobby projects that were developed to solve the needs of a specific team but turns out that many teams have similar requirements. From f0c4f93fac1eca60cd10950a92781fa5b12b8d7e Mon Sep 17 00:00:00 2001 From: Shanmugapriya M <97021994+spriya-m@users.noreply.github.com> Date: Mon, 1 Jul 2024 18:37:51 +0200 Subject: [PATCH 08/15] Update patterns/1-initial/innersource-hackathon.md Co-authored-by: Sebastian Spier --- patterns/1-initial/innersource-hackathon.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/patterns/1-initial/innersource-hackathon.md b/patterns/1-initial/innersource-hackathon.md index 6e3d17582..a51ae3f58 100644 --- a/patterns/1-initial/innersource-hackathon.md +++ b/patterns/1-initial/innersource-hackathon.md @@ -65,7 +65,7 @@ Such an event provides a safe space for the engineers who want to adopt or contr * Communities start to form around these InnerSource projects. * This happens not only during the event but continues after the event too, with the hackathon participants acting as InnerSource ambassadors in their teams. * It also helps ISPO and OSPO spread awareness about InnerSource best practices quickly, across the whole engineering community in the organization. -* Such an event also helps discover some cool hobby projects that were developed to solve the needs of a specific team but turns out that many teams have similar requirements. +* Such an event also gives more exposure to projects that were developed to solve the needs of a specific team but turns out that many teams have similar requirements. All these help scale InnerSource in the organization. From 01db7de3f879552424bd35e983adc485c5f8a8d1 Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Mon, 1 Jul 2024 21:49:41 +0200 Subject: [PATCH 09/15] Expand subsection headers --- patterns/1-initial/innersource-hackathon.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/patterns/1-initial/innersource-hackathon.md b/patterns/1-initial/innersource-hackathon.md index a51ae3f58..3532ab18f 100644 --- a/patterns/1-initial/innersource-hackathon.md +++ b/patterns/1-initial/innersource-hackathon.md @@ -20,7 +20,8 @@ The senior leadership believes in InnerSource and wants to drive it throughout t * relunctance to changing ways of working when everything works well already * perception that InnerSource requires more work and responsibilities -Scenario 2: +### Scenario 2: Challenges in getting contributions and building community around InnerSource projects + Teams slowly start adopting InnerSource and open up their repositories. Some new projects are started as InnerSource projects from the start (that is open for contributions). However, there are not many contributors. It is also challenging to build a community around those projects, in spite of publishing the projects in an InnerSource Portal. This could be due to various reasons like: * engineers do not have time to explore new InnerSource projects and contribute, outside regular work deliverables From 130e45faa4b1294936be59f8ac78eb2c21f6bb1b Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Mon, 1 Jul 2024 21:50:11 +0200 Subject: [PATCH 10/15] Expand subsection headers --- patterns/1-initial/innersource-hackathon.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/patterns/1-initial/innersource-hackathon.md b/patterns/1-initial/innersource-hackathon.md index 3532ab18f..d1af739e8 100644 --- a/patterns/1-initial/innersource-hackathon.md +++ b/patterns/1-initial/innersource-hackathon.md @@ -12,7 +12,8 @@ The company wants to adopt InnerSource as software development methodology but o ## Context -Scenario 1: +### Scenario 1: Challenges in scaling beyond the early adopters + The senior leadership believes in InnerSource and wants to drive it throughout the company. The engineers who are familiar with open source principles and/or understand the benefits of InnerSource are the early adopters. There is success with these initial pilot project and teams. Now the next step is to drive it across the company. There might be reluctance from engineering teams due to various factors like: * not familiar with InnerSource and being ignorant to know about it From 6343833ab9329ba145a95410ad5cb62fb1823aaa Mon Sep 17 00:00:00 2001 From: Shanmugapriya M <97021994+spriya-m@users.noreply.github.com> Date: Mon, 7 Oct 2024 16:08:49 +0200 Subject: [PATCH 11/15] Update innersource-hackathon.md --- patterns/1-initial/innersource-hackathon.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/patterns/1-initial/innersource-hackathon.md b/patterns/1-initial/innersource-hackathon.md index d1af739e8..2416088c5 100644 --- a/patterns/1-initial/innersource-hackathon.md +++ b/patterns/1-initial/innersource-hackathon.md @@ -16,10 +16,10 @@ The company wants to adopt InnerSource as software development methodology but o The senior leadership believes in InnerSource and wants to drive it throughout the company. The engineers who are familiar with open source principles and/or understand the benefits of InnerSource are the early adopters. There is success with these initial pilot project and teams. Now the next step is to drive it across the company. There might be reluctance from engineering teams due to various factors like: -* not familiar with InnerSource and being ignorant to know about it +* not familiar with InnerSource and not aware about it * not enough time to prioritize InnerSource, given the regular work deliverables * relunctance to changing ways of working when everything works well already -* perception that InnerSource requires more work and responsibilities +* unclear ROI for the upfront setup innersourcing takes ### Scenario 2: Challenges in getting contributions and building community around InnerSource projects From 800705a877ded752fe9e58df1e59e5799ca9cb71 Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Wed, 9 Oct 2024 18:47:14 +0200 Subject: [PATCH 12/15] Fixing typo - reluctance --- patterns/1-initial/innersource-hackathon.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/patterns/1-initial/innersource-hackathon.md b/patterns/1-initial/innersource-hackathon.md index 2416088c5..cc21cb272 100644 --- a/patterns/1-initial/innersource-hackathon.md +++ b/patterns/1-initial/innersource-hackathon.md @@ -18,7 +18,7 @@ The senior leadership believes in InnerSource and wants to drive it throughout t * not familiar with InnerSource and not aware about it * not enough time to prioritize InnerSource, given the regular work deliverables -* relunctance to changing ways of working when everything works well already +* reluctance to changing ways of working when everything works well already * unclear ROI for the upfront setup innersourcing takes ### Scenario 2: Challenges in getting contributions and building community around InnerSource projects From 3cbae594a1909680d1ef72bb95c1745573d61c5d Mon Sep 17 00:00:00 2001 From: Shanmugapriya M <97021994+spriya-m@users.noreply.github.com> Date: Mon, 4 Nov 2024 15:19:14 +0100 Subject: [PATCH 13/15] update patterns/1-initial/innersource-hackathon.md Co-authored-by: Sebastian Spier --- patterns/1-initial/innersource-hackathon.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/patterns/1-initial/innersource-hackathon.md b/patterns/1-initial/innersource-hackathon.md index cc21cb272..b39fc9746 100644 --- a/patterns/1-initial/innersource-hackathon.md +++ b/patterns/1-initial/innersource-hackathon.md @@ -19,7 +19,7 @@ The senior leadership believes in InnerSource and wants to drive it throughout t * not familiar with InnerSource and not aware about it * not enough time to prioritize InnerSource, given the regular work deliverables * reluctance to changing ways of working when everything works well already -* unclear ROI for the upfront setup innersourcing takes +* unclear return on investment for the upfront setup costs that an InnerSource project takes ### Scenario 2: Challenges in getting contributions and building community around InnerSource projects From ea572a0df8b6b6abdfc9cc500c4917cf5d761018 Mon Sep 17 00:00:00 2001 From: Shanmugapriya M <97021994+spriya-m@users.noreply.github.com> Date: Mon, 4 Nov 2024 15:19:45 +0100 Subject: [PATCH 14/15] update patterns/1-initial/innersource-hackathon.md Co-authored-by: Sebastian Spier --- patterns/1-initial/innersource-hackathon.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/patterns/1-initial/innersource-hackathon.md b/patterns/1-initial/innersource-hackathon.md index b39fc9746..5cde3fd74 100644 --- a/patterns/1-initial/innersource-hackathon.md +++ b/patterns/1-initial/innersource-hackathon.md @@ -14,7 +14,9 @@ The company wants to adopt InnerSource as software development methodology but o ### Scenario 1: Challenges in scaling beyond the early adopters -The senior leadership believes in InnerSource and wants to drive it throughout the company. The engineers who are familiar with open source principles and/or understand the benefits of InnerSource are the early adopters. There is success with these initial pilot project and teams. Now the next step is to drive it across the company. There might be reluctance from engineering teams due to various factors like: +The senior leadership believes in InnerSource and wants to drive it throughout the company. The engineers who are familiar with open source principles and/or understand the benefits of InnerSource are the early adopters. There is success with these initial pilot project and teams. + +Now the next step is to drive it across the company. There might be reluctance from engineering teams due to various factors like: * not familiar with InnerSource and not aware about it * not enough time to prioritize InnerSource, given the regular work deliverables From c0844f5d156c32d777772f852e1ca7b9ca066411 Mon Sep 17 00:00:00 2001 From: Shanmugapriya M <97021994+spriya-m@users.noreply.github.com> Date: Mon, 4 Nov 2024 15:21:03 +0100 Subject: [PATCH 15/15] update innersource-hackathon.md --- patterns/1-initial/innersource-hackathon.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/patterns/1-initial/innersource-hackathon.md b/patterns/1-initial/innersource-hackathon.md index 5cde3fd74..c1884954b 100644 --- a/patterns/1-initial/innersource-hackathon.md +++ b/patterns/1-initial/innersource-hackathon.md @@ -18,7 +18,7 @@ The senior leadership believes in InnerSource and wants to drive it throughout t Now the next step is to drive it across the company. There might be reluctance from engineering teams due to various factors like: -* not familiar with InnerSource and not aware about it +* not familiar with InnerSource or open source practices * not enough time to prioritize InnerSource, given the regular work deliverables * reluctance to changing ways of working when everything works well already * unclear return on investment for the upfront setup costs that an InnerSource project takes