From e769d39168f14120e989f9d86b14135ed202b30b Mon Sep 17 00:00:00 2001 From: rrrutledge Date: Tue, 16 May 2023 10:45:55 -0500 Subject: [PATCH] Project Leader section (#554) * Project Leader section * Converted from Product section * Project leader files --- product/01-introduction.md | 34 --- product/02-innersource-and-agile.md | 136 ----------- product/03-capacity-planning.md | 62 ----- product/05-shared-ownership.md | 113 --------- product/06-relation-to-open-source.md | 56 ----- project-leader/01-introduction.asciidoc | 52 ++++ .../02-innersource-and-agile.asciidoc | 222 ++++++++++++++++++ project-leader/03-capacity-planning.asciidoc | 87 +++++++ .../04-negotiation.asciidoc | 11 +- project-leader/05-shared-ownership.asciidoc | 181 ++++++++++++++ .../06-relation-to-open-source.asciidoc | 106 +++++++++ project-leader/index.md | 4 + {product => project-leader}/outline.md | 0 scripts/generate_learning_path_markdown.js | 19 +- scripts/section_data.json | 8 + 15 files changed, 676 insertions(+), 415 deletions(-) delete mode 100644 product/01-introduction.md delete mode 100644 product/02-innersource-and-agile.md delete mode 100644 product/03-capacity-planning.md delete mode 100644 product/05-shared-ownership.md delete mode 100644 product/06-relation-to-open-source.md create mode 100644 project-leader/01-introduction.asciidoc create mode 100644 project-leader/02-innersource-and-agile.asciidoc create mode 100644 project-leader/03-capacity-planning.asciidoc rename product/04-negotiation.md => project-leader/04-negotiation.asciidoc (98%) create mode 100644 project-leader/05-shared-ownership.asciidoc create mode 100644 project-leader/06-relation-to-open-source.asciidoc create mode 100644 project-leader/index.md rename {product => project-leader}/outline.md (100%) diff --git a/product/01-introduction.md b/product/01-introduction.md deleted file mode 100644 index 5e282912..00000000 --- a/product/01-introduction.md +++ /dev/null @@ -1,34 +0,0 @@ -Welcome to the learning path section for product managers. - -After completing this segment, you will have a better understanding of how InnerSource speeds up product development. -We will also cover how it relates to Agile development best practices. - -To achieve agility, organizations strive for autonomous teams. -However, in a complex, interconnected world, some dependencies cannot be avoided. -InnerSource [provides an alternative](https://innersourcecommons.org/learn/learning-path/introduction/02/) to "wait it out", "build workarounds" and "escalate": Teams that need modifications in their dependencies can offer a helping hand. -InnerSource facilitates cross team collaboration. -Through its focus on written communication, it is well suited even for remote-first mode. - -In this section, you will learn where Agile development and InnerSource use similar terminology and even technology - but differ substantially in the details. -Instead of running into common misunderstandings, you will benefit from knowing the differences in culture but also in purpose of tools used. - -You will understand the impact of InnerSource on capacity planning. Also with InnerSource there is no free lunch - host teams need time for mentoring contributors. -We will also look at the additional negotiation possibilities that InnerSource brings - keeping the balance of Give and Take. - -But let us start with a brief example. -Imagine you are building a lovely new music app. -In order to understand how your users are interacting with the app you start collecting some interaction logs. -Over time, you dig deeper when analysing those, feeding your learnings back into development. -Now, imagine another team bringing content into your application also has a few needs - they may want to reward content creators based on how many users they reached. -So them, too they start using your collected logs. -But they need some additional analysis steps that you hadn't thought of at first. -They are now faced with a challenge: Build a workaround, or go through your backlog to get their request prioritized. -With InnerSource they will have a third option: Make the changes themselves - with your help. -Sure, that may be slower than if you had made the changes. -But it will still be faster than waiting for you to get around to making the modifications. - -In an ideal InnerSource organisation you can scale that up even further: -Remember the last time you had to make cross cutting concern modifications across your entire platform? -When going the "put it into the backlog of each team" this often feels like it's dragging on forever. -On the other hand, it speeds things up substantialy to provide those teams with a patch that implements the modification. -The complexity of modifications in that approach depends on the maturity of the organisation and the maintainability/modularity of the code produced. diff --git a/product/02-innersource-and-agile.md b/product/02-innersource-and-agile.md deleted file mode 100644 index 77c9406e..00000000 --- a/product/02-innersource-and-agile.md +++ /dev/null @@ -1,136 +0,0 @@ -# InnerSource and Agile - -You want to improve your product and deliver faster to customers. -You want to make stakeholders happy. -InnerSource helps your team deliver value and maintain autonomy in a highly interconnected world. - - -## Autonomous teams in an interconnected world - -Organisations try to deliver value to customers quickly. -One common cause for delays are dependencies in the delivery process. -As a result organisations prefer cross functional teams covering customer communication, design, implementation, testing and operations thus eliminating costly handovers. -To achieve high performance, teams eliminate waste and re-use existing components. -From a team perspective each reused component adds another dependency outside of the control of that team. -The negative side of this optimisation is clear: The team depends on another team if they need changes in the component used. -To be able to implement those often lengthy roadmap discussions are scheduled, sometimes leading to the need to optimize detailed priorities globally. -In complex situations as much as in large organisations this leads to an increase in time needed to adjust to changing business needs. -For very popular central components often there are so many requests coming in that one central component team runs out of capacity to implement all of the requested changes. - -In traditional organizations there are only [two ways of making changes to dependencies](https://innersourcecommons.org/learn/learning-path/introduction/02/): -* Submit a feature request/ bug report and wait for the other team to prioritize that change and implement it. -* Build a workaround to avoid the bug or locally provide the functionality needed. - -If none of those options is successful typically the issue is being escalated and decided at a higher hierarchy level. - -Neither solution is particularly satisfying. -Looking at Open Source though there is an obvious solution: A team depending on a component becomes a contributing team and provides a helping hand to the host team. - -Now you may ask yourself: "Doesn't that lead to complete chaos where people randomly write into code repositories of teams they are not a member of?" -InnerSource comes with a set of roles and processes that bring clarity to what otherwise would indeed lead to chaos: -* Each InnerSource project has a set of Trusted Committers with clear accountabilities that go beyond simply reviewing code. -Trusted Committers set the rules for contributions. -* Contributions happen in a structured way: - * Contribution intent is shared early to make sure the contribution fits within the Host projects' vision and scope. - * Progess is shared early so the host team has a chance to mentor the contributor and guide them on the path to a desired design and architecture. - That way frustration due to having to decline a contribution late in the process is avoided. - * Decisions and vital communication happens asynchronously to be able to work around differing meeting schedules of people in different teams. -As a result contributing teams gain autonomy to fix upstream artifacts without sacrificing the quality of the component that is being contributed to. - -As a side effect InnerSource provides teams with best practices that make working in a remote first culture easy. - -## Advantages of an InnerSource approach - -Instead of working in silos InnerSource fosters collaboration between teams. -Much as in Open Source that means standing on the shoulders of giants: Instead of building every component locally InnerSource fosters reuse. -It reduces the cost of reuse by providing a clear path to supporting the upstream team with the work of fixing bugs and implementing features. - -Much like in Open Source InnerSource fosters a thinking of combined forces: Components that all business units and product teams need as a foundation can be built together. -As a result all the boats are rising together: Innovation created in one part of the organization can create benefits all over the entire corporation. -With teams that are familiar with InnerSource the load to move this type of innovation forward can be shared by all teams that benefit from and depend on the resulting components and services. - -InnerSource gives your team the initiative and tooling to fix issues that block shipping features to customers. -When done right maintenance of core components and services can be shared in a well structured way by a "virtual InnerSource team" that is larger than any specific product team. - -In advanced settings those involved understand the value of contributors working on simpler features that may not directly benefit their customers - under the condition that it frees the host team to work on more complex changes that contributors have a business need for. - - -## Does InnerSource replace Agile? - -Short answer: No, not at all. -Instead the two complement each other: - -Well factored and well tested code is one goal of any agile team. -In an InnerSource setting on-ramp times for team members but also for team-external contributors get shorter. - -Teams familiar with collaboration who avoid assigning tasks are in a good position to also deal with external contributions in a flexible manner. -They also bring a mindset and communication style that works well for motivating contributors over whose priority they have no direct influence. -Working with intrinsic motivation instead of directing work means that host teams have the tools to successfully collaborate with contributors. - -Teams pairing to work on problems are already comfortable with sharing progress early. -There are two challenges moving to InnerSource from a pairing only culture: -The host team needs to make time for supporting contributors and schedule that into their planned work. -In addition when crossing team boundaries it is often hard to find time slots for pairing - in those cases it should be complemented with asynchronous collaboration. -To avoid frequent disruption, host team members often need to intentially plan their day more rigorously in InnerSource settings. -Often it is simplest to set aside certain hours in the day or a day a week for mentoring contributions. -Making that explicit at the team level takes a lot of pressure off the engineers trying to fulfil their own team goals but also helping out contributors. -Another challenge with pairing is that it allows pairs to move very quickly together - often at the expense of writing important information down for the rest of the team. -In an InnerSource setting it does take training to remember to bring all relevant decisions back to shared communication channels for both, host team and contributors. -From a product perspective that does bring a lot more transparency to the development process. -It also means that decisions that otherwise may have been taken at the engineering level only are now visible for everyone involved. - -Remember last time you insisted that your product be well tested, preferably with automated tests so deployments can happen frequently and without human intervention? -This goal now helps with InnerSource as well: Contributions are much easier if contributors can check locally if their changes are safe. -Tests also ensure that the host team remembers to keep the contributed functionality if they are reminded of the reason for it by a failing test. - -Remember last time you insisted on your team spending time to follow the goal of "leave code in a better shape than you found it"? -That mindset helps in the InnerSource model: It makes sure that quality and cohesion of code remains high even when there are multiple contributions from different sources. - - -## Common misunderstandings when coming from agile teams - -InnerSource and Agile uses some of the same tooling - for different purposes. - -### Impact of overlapping language - -Issue trackers: In agile teams user stories are a conversation with the customer. -Often the are put as sticky notes on a whiteboard. -But also often they are stored in an issue tracker. -As a result issue trackers are mainly perceived as planning tools, essentially a replacement for sticky notes on a whiteboard. -In InnerSource, issue trackers serve for a conversation with the customer, but also for communication between members of a team of trusted committers and contributors working on one common InnerSource component. -Issues in InnerSource become much more lengthy and wordy than in your average organisation. -They also track the implementation history and detailed design decisions for a change. - -Code Reviews: In traditional organisations code reviews often serve auditing purposes. - -They are done when development is finished. -In InnerSource code changes are shared very early in the process, sometimes when nothing more than a rough sketch is done. -The goal is to seek early feedback and mentoring. -This is particularly helpful for teams that are on diverse schedules and cannot find any time for pair programming. -Often teams have the aspiration that nobody walks alone - in reality though this often isn't much more than an aspiration never achieved. -In particular where contributions cross team boundaries. - -Tools used in InnerSource can formalize this ask for more than one human to be involved with any change. - -Focus on written communication: The goal with InnerSource is for the project to be transparent enough so that developers who are not part of the team can understand project decisions and follow along the process of software creation. -As a result all communication needs to be in a place that everyone interested in the conversation can follow along: written, public, searchable and linkable. -The goal is not to reduce distractions to others - the goal is to make all project conversations transparent. - -As a result direct messages and mails are to be avoided. -In order to make following conversations easier for everyone, messages related to one InnerSource project should be tracked in one separate communication channel: The goal is not to reach every person in the team of the InnerSource project. -The goal is to find a common shared room for everyone involved with the project where they can have discussions focused on that InnerSource project. - -Focus on written communication does not mean verbal communication is disallowed. -There still needs to be time for a shared cup of coffee. -Also solving problems together, pairing with others or in person hackathons are valuable to find solutions quickly. -The team needs to make sure though that all project relevant decisions are kept in channels that everyone has access to. -That also may mean to postpone important project decisions until everyone is back from vacation or waiting for another day or two if those working in another country are now on holiday. -This is not only relevant for coding decisions, but also relates to general project mission, roadmap and direction. -Without that information contributors will have a hard time understanding which contributions will have a good chance of getting accepted. - -### Impact of trust - -All discussions in InnerSource projects are visible to everyone in the company. -Blaming people for their errors, ridiculing them for their mistakes, talking behind their backs about what they did wrong is a sure fire way to kill that trust and leads to the failure of that InnerSource project. -This is particularly important for anyone in a leadership or role model position. - diff --git a/product/03-capacity-planning.md b/product/03-capacity-planning.md deleted file mode 100644 index b8c75c58..00000000 --- a/product/03-capacity-planning.md +++ /dev/null @@ -1,62 +0,0 @@ -# InnerSource and planning - -Planning plays a role in InnerSource in two important situations: - -Contributing teams need to understand that working on upstream code typically does need more time than making comparable changes to their own codebase that they are well familiar with. -They need to be aware of the fact that even if the host team does not have to implement the change they still need to be available for mentoring and reviewing. -The time needed for that increases with the size of the change required. -As a result early communication with the host team is important in particular in cases of larger changes. - -Host teams also need to be aware of the time needed for mentoring and reviewing. -Simply telling contributing teams that they can submit changes as patches does not reduce the time to make the change to zero for the host team. -In addition host teams can find themselves in the rare situation where they are flooded with pull requests. -For that event there needs to be a clear understanding of business priorities for the projects sending these pull requests. -When overwhelmed with patches it is often time to think about sharing ownership of the component. -In particular contributors that are coming back regularly and have earned trust of the host team are good candidates to receive the title Trusted Committer. - -Some friction due to slightly different work culture cannot be avoided though. -For these cases it is important to explicitly set expectations. - - -## Setting expectations - -Imagine the following situation: -As a contributor you finally made the change needed - likely with a little help from the host team. -You proudly submit the pull request. -Then - nothing happens. -A day later - still no reaction. -You start wondering if the host team has seen your patch. -You wonder where to best ping the team about an update. -This silence is very frustrating in particular for first time contributors. -There are several remedies to this situation - remedies that need no coding knowledge, but require at least some basic communication skills: -* Make reaction times that can be expected of the host team explicit - e.g. in the contributing documentation. -* As soon as a pull request is received communicate the expected time it will take to receive substantial feedback instead of letting contributors wait. -* Communicate ways for contributors to get in touch with the host team and watch communication there. - -Neither of these tasks needs code writing skills. -This underscores the need for people beyond those who have programming knowledge. -It is good practice to consider people covering these tasks as committed to the InnerSource project and include them as Trusted Committers as well. - -## Small vs. large changes - -Small changes and patches are easy to handle - they are quick to review and often do not carry a lot of risk when merged. -One way to help host teams is to make time for splitting changes into smaller chunks. -Make sure to communicate the wider context these changes belong to though. - -Often making larger changes requires communicating intent and purpose early. -It can also be benefitial to make sure contributing team and host team have enough time set aside for working on the change together. -This means that people setting team priorities need to think beyond their own team when prioritizing changes. -However coordination can still happen fairly independently as typically only the pair of contributing and host team are involved. - - -## Increasing the team around your InnerSource projects - -Rarely host teams run into the challenge of receiving too many patches from contributing teams. -In that case it helps thinking about moving trusted contributors to the Trusted Committer role. -In addition to simply help with reviews, new Trusted Committers can help with issue triage, mentoring new contributors and the like. - -When faced with a lot of interest in contributions one additional factor to consider when prioritising mentoring help for contributors can be interest of the contributors in a long term relationship with the host team. -The more time is needed for mentoring, the more likely it should be for contributors to stick around longer. - -In practice sharing ownership of the component with very active contributors has proven to keep the newly minted Trusted Committers engaged with the project over a longer period of time. -Typically they help keep the component up to date and mentor new contributors long after the initial motivation for the contribution has been addressed. diff --git a/product/05-shared-ownership.md b/product/05-shared-ownership.md deleted file mode 100644 index 3bf755d2..00000000 --- a/product/05-shared-ownership.md +++ /dev/null @@ -1,113 +0,0 @@ -# Options for shared ownership - -"If everyone owns it, nobody is accountable." -Traditional organisations perfer to have a single point of contact in case of issues. -On the other hand allowing simply everyone to make changes surely will result in a mess that can no longer be maintained. - -Based on that observation each InnerSource project has a dedicated team of Trusted Committers. -Interest in maintaining an InnerSource project often is motivated by enlightened self interest: A team understanding that they themselves need the InnerSource project to fullfill their customers' needs and understanding that opening the project up for contributions can spread the workload to move the project forward. -Opening a project up for contibutions though doesn't mean that Trusted Committers have to accept all submissions. -It is the team of Trusted Committers that sets the mission and goals for the project. -They are then in a postition to set direction and decide on change acceptance accordingly. - -## Ownership misconceptions - -"Trusted committers are responsible for an InnerSource project. -They review submissions and mentor contributors." - -This is a very simplistic summary of what the role of a Trusted Committer looks like. -In reality one of the first questions often revolves around the need to accept each and every contribution. -In particular where contributors have already invested a lot of time in the contributions can become frustrated when hearing that their work was in vain. -Communication skills are important to make sure that contributors know roughly what the roadmap of the InnerSource project looks like. -They are also needed to make sure that contributors know to share intent and progress very early on to avoid spending a lot of work without results. -Last but not least rejecting contributions needs very good communication skills. -To cut a long story short: Even if you are not writing source code yourself, your support is needed to clearly communicate the vision of the InnerSource project, to potentially help when contributions need to be rejected. -Another aspect that becomes more important as the InnerSource project becomes more popular: Review and mentoring become more time intensive and over time need to be scheduled into the day explicitly. -This does have impact on general capacity planning and should not happen "under the radar". - -On the other hand for contributors it is important that code review is not a last stage quality gate. -Instead it is a way for continuously guiding contributors through the code development process ideally leading to better results faster. -For that to work out in practice there needs to be time and space for team building - but across traditional team boundaries. -Having at least a vague understanding of the different cultures in teams makes misunderstandings much less likely and the contribution process much more smooth. - -In particular when host teams are flooded with contributions product managers that otherwise focus only on their local team need to take a more global perspective: -* Help the team understand different priorities for incoming contributions depending on overall company strategy. -Often not all contributions are equally urgent. -* Another way to help the team is to take over tasks like issue triage, handling initial responses to contributors and guiding larger contributions through the process. -You can help your team by communicating to contributors if integration of the change takes a bit longer. -* When faced with larger contribution requests teams can benefit from help negotiating with other teams the best time to work on these contributions. -Often that is still way faster than your team doing all the work on their own. -In particular first time contributors may need some hand holding - in particular for larger changes. -Coordinating the timing around that mentoring can be a big help for your team. - - -"But we could simply fork permanently" ... a misconception where potential guest teams believe that simply copying the code would be faster. - -In the short term that is true. -In the long run it means added maintenance. -As a product person you can help your team understand why contributing changes to the project you depend on is in the best interest of the business: Less work overall. -Maintenance for the long term is taken on by the host team. - -## InnerSource governance levels - -"We are using pull requests to develop our component - so we are using InnerSource on a daily basis". -While using pull requests and reviews is a crucial component, it is just the baseline for InnerSource projects. -Just because two projects you depend on use pull requests on a daily basis does not mean that their openess to team-external contributions is the same. - -InnerSource comes with different best practices. -In order to avoid confusion and frustration for contributors it is important for host teams to define for their InnerSource project which governance model they want to adopt. -Much like in Open Source these governance levels can differ substantially. - -In the InnerSource Commons we provide an InnerSource pattern that defines at least three governance levels: -* Source code is visible to everyone - but the team has no time to mentor contributors. -From the outside this may look like your everyday InnerSource project. -Making the refusal to mentor and accept contributions explicit though avoids confusion from colleagues trying to interact with the project through InnerSource means. -Instead this communicates to those depending on the project that only feature requests and bug reports can be handled by the team. -Essentially that means falling back to a regular traditional software development project. -* Source code is visible to everyone - plus the team of Trusted Committers has set aside time for mentoring contributors. -For these projects patches and pull requests are welcome. -The team of Trusted Committers makes sure that project relevant communication happens in a written, archived, searchable and linkable channel. -The team also makes sure that project relevant decisions are taken where contributors can see and follow them. -Final decision making though rests with the team of Trusted Committers - and becoming a Trusted Committer of the project is tied to working for the initial project team. -* As above - but the team of Trusted Committers is open to the idea of sharing write access. -This approach requires a process for building enough trust with contributors for the team of Trusted Committers to share write access. -This is particularly helpful where there is a long term relationship with contributors. -Shared write access can remove the review bottle neck. -* In the final stage the team of Trusted Committers is also ready to share control over who gets write access next as well as project vision and mission. -While this will often result in the highest level of committment from contributors it also requires a high level of coordination crossing team boundaries. -It also requires the highest level of transparency when making decisions about the project. - - -To summarize each governance level needs a different approach to collaboration and coordination: -* Increased sharing increases the need for communication and co-ordination, -* Increased shared accountabilities can slow down decision making. - - -## Explicit pointers for contribution - -What is implicitly clear for team members is best made explicit and documented if the project would like to encourage contributions. -Topics like -* Response times to expect when submitting changes, -* communication channels to use when getting in touch with the team of Trusted Committers, -* communication channels to use when trying to follow the project as a contributor, -* governance levels to expect from the project -are all topics that the entire host team has to agree and communicate to contributors. - -## Impact on leadership - -Increased sharing of accountabilities for InnerSource projects also has an impact on performance reviews. -In hierarchical settings those often consider contributions local to the team. -InnerSource contributors however are starting to have an impact outside of their own teams. -InnerSource Trusted Committers have an impact on teams that can be outside of the scope of their own team. -That means direct line managers are losing a certain level of control. -They are also losing direct oversight. -As a result, performance feedback from potentially remote teams should to be taken into account. - -## "You build it, you run it" in settings with high sharing levels - -A common best practice for cross functional teams is a "you build it, you run it" setup. -With contributions potentially coming from downstream users this best practice seems to break. -There are several ways to use InnerSource in that context as well: -* Option number one is to move to greater modularization and collaborate only on the parts that are the same across teams and keep operations local. -* Alternatively work with contract tests to avoid API breakages. -* Work with internal service level agreements, make contributors sign up to warranty periods to remove the fear of the host team that contributions break production systems. diff --git a/product/06-relation-to-open-source.md b/product/06-relation-to-open-source.md deleted file mode 100644 index fc6ecaa2..00000000 --- a/product/06-relation-to-open-source.md +++ /dev/null @@ -1,56 +0,0 @@ -# Relation to Open Source - -InnerSource is the application of Open Source collaboration best practices inside of the confines of corporations. -This makes understanding two aspects of Open Source easier for teams through parallels with InnerSource: - -## Governance levels - -Much like in InnerSource, Open Source projects have different governance levels. -Not all Open Source projects are created equal: While some groups only publish the source code, expecting no interaction, others want downstream users to become active and submit patches. -Other projects have processes set up to allow for sharing impact on the Open Source project. -Understanding these governance levels means that deciding which open source project to use in house will take Open Source governance into consideration as well. -A downstream user of an InnerSource project will have learnt to correctly evaluate the balance between moving fast but being unable to influence a project vs. moving at a slower pace but being able to influence a project together. - -## Building a platform together - -Working in InnerSource projects helps teams practice what it means to share the cost and effort to build platforms together. -Sharing the work across teams helps innovate faster overall: Product teams with different focus areas can join forces to develop a needed base platform faster and share the resulting maintenance load. - -The same dynamic drives several Open Source projects as well. -Understanding it means that participation in these projects is natural for any team that has experience with InnerSource. -Knowing that dynamic from practical experience also makes it easier for teams to recognise which open source projects are being developed according to these principles. -Typically this understanding subsequently also has an impact on which Open Source projects teams decide to use internally. - -Platform features that many teams need can then be created by collaborating instead of re-implementing them locally over and over. -That makes it easier to understand the concept of how sharing effort can help to make the pie bigger for everyone and how it can help drive industry standards if done in an open source way instead of only internally. - -## InnerSource? Or Open Source? - -In terms of mechanics both practices are very similar. -The major difference is the visibility of projects: For InnerSource that is limited to the corporation, for Open Source they are public. - -What sounds like a tiny difference on paper is a huge difference in practice. -Going Open Source means that each and every message is publicly visible and potentially archived forever. -This implication can be very uncomfortable in particular for employees not used to that way of working. -In addition all actions being public means they are also available for public scrutiny - no longer can every move be vetted by corporate communication experts. -Similarly produced artifacts are available for public scrutiny wrt. license compliance, security and the like - e.g. for competitors, for potential future new hires, for customers. - -On the other hand it also opens the door to collaboration with others outside of the walls of one corporation - taken to the extreme that can result in co-opetition where competitors join forces to build a common technical platform, innovating and competing against one another on top of that. - -Going open source also reduces the tax implications of collaborating across the boundaries of legal entities. -While transfer prizing as a hot topic for many InnerSource effort it is irrelevant for any Open Source project. - - -## Participate upstream - gain by sharing - -While "what about publishing projects as Open Source" often is the first thought when talking about becoming active in the Open Source space. -When experienced with InnerSource it becomes clear that publishing entire projects is only one way of being active in the open source space. - -Instead it is much more natural to adopt an enlightened self interest point of view: -* Where teams use certain Open Source dependencies in vital parts of their components it is important to ensure being involved upstream - even if the only goal is to understand the future roadmap of the project. -* Where teams have a need for changes in open source projects they depend on, experience with InnerSource makes the advantages of participating upstream obvious: Clearly it is not only about a "sharing is caring" mindset - but it does have clear economic benefits where contributing teams have a highly reduced maintenance overhead if their changes are integrated upstream. - -Taking another step back even the decision of which Open Source project to adopt and use internally will be influenced by the InnerSource experience of a team: -* InnerSource trains teams to understand what to look out for in terms of ways of collaborating and communicating - from personal experience they will understand why it's important for project to have clear, archived, searchable communication channels. -They will also understand why it's important that every major project decision is taken on these communication channels. -* Understanding the different governance levels in InnerSource teams are well prepared to understand the implications of Open Source projects operating according to different levels of openness. diff --git a/project-leader/01-introduction.asciidoc b/project-leader/01-introduction.asciidoc new file mode 100644 index 00000000..1893d3f1 --- /dev/null +++ b/project-leader/01-introduction.asciidoc @@ -0,0 +1,52 @@ +== InnerSource for Project Leaders + +After completing this segment, you will have a better understanding of +how InnerSource speeds up product development. We will also cover how it +relates to Agile development best practices. + +To achieve agility, organizations strive for autonomous teams. However, +in a complex, interconnected world, some dependencies cannot be avoided. +InnerSource +https://innersourcecommons.org/learn/learning-path/introduction/02/[provides +an alternative] to "wait it out", "build workarounds" and +"escalate": Teams that need modifications in their dependencies can +offer a helping hand. InnerSource facilitates cross team collaboration. +Through its focus on written communication, it is well suited even for +remote-first mode. + +In this section, you will learn where Agile development and InnerSource +use similar terminology and even technology - but differ substantially +in the details. Instead of running into common misunderstandings, you +will benefit from knowing the differences in culture but also in purpose +of tools used. + +You will understand the impact of InnerSource on capacity planning. Also +with InnerSource there is no free lunch - host teams need time for +mentoring contributors. We will also look at the additional negotiation +possibilities that InnerSource brings - keeping the balance of Give and +Take. + +But let us start with a brief example. Imagine you are building a lovely +new music app. In order to understand how your users are interacting +with the app you start collecting some interaction logs. Over time, you +dig deeper when analysing those, feeding your learnings back into +development. Now, imagine another team bringing content into your +application also has a few needs - they may want to reward content +creators based on how many users they reached. So them, too they start +using your collected logs. But they need some additional analysis steps +that you hadn't thought of at first. They are now faced with a +challenge: Build a workaround, or go through your backlog to get their +request prioritized. With InnerSource they will have a third option: +Make the changes themselves - with your help. Sure, that may be slower +than if you had made the changes. But it will still be faster than +waiting for you to get around to making the modifications. + +In an ideal InnerSource organisation you can scale that up even further: +Remember the last time you had to make cross cutting concern +modifications across your entire platform? When going the "put it into +the backlog of each team" this often feels like it's dragging on +forever. On the other hand, it speeds things up substantialy to provide +those teams with a patch that implements the modification. The +complexity of modifications in that approach depends on the maturity of +the organisation and the maintainability/modularity of the code +produced. diff --git a/project-leader/02-innersource-and-agile.asciidoc b/project-leader/02-innersource-and-agile.asciidoc new file mode 100644 index 00000000..17a163c2 --- /dev/null +++ b/project-leader/02-innersource-and-agile.asciidoc @@ -0,0 +1,222 @@ +== InnerSource and Agile + +You want to improve your product and deliver faster to customers. You +want to make stakeholders happy. InnerSource helps your team deliver +value and maintain autonomy in a highly interconnected world. + +=== Autonomous teams in an interconnected world + +Organisations try to deliver value to customers quickly. One common +cause for delays are dependencies in the delivery process. As a result +organisations prefer cross functional teams covering customer +communication, design, implementation, testing and operations thus +eliminating costly handovers. To achieve high performance, teams +eliminate waste and re-use existing components. From a team perspective +each reused component adds another dependency outside of the control of +that team. The negative side of this optimisation is clear: The team +depends on another team if they need changes in the component used. To +be able to implement those often lengthy roadmap discussions are +scheduled, sometimes leading to the need to optimize detailed priorities +globally. In complex situations as much as in large organisations this +leads to an increase in time needed to adjust to changing business +needs. For very popular central components often there are so many +requests coming in that one central component team runs out of capacity +to implement all of the requested changes. + +In traditional organizations there are only +https://innersourcecommons.org/learn/learning-path/introduction/02/[two +ways of making changes to dependencies]: + +* Submit a feature request/ bug +report and wait for the other team to prioritize that change and +implement it. +* Build a workaround to avoid the bug or locally provide +the functionality needed. + +If none of those options is successful typically the issue is being +escalated and decided at a higher hierarchy level. + +Neither solution is particularly satisfying. Looking at Open Source +though there is an obvious solution: A team depending on a component +becomes a contributing team and provides a helping hand to the host +team. + +Now you may ask yourself: "Doesn't that lead to complete chaos where +people randomly write into code repositories of teams they are not a +member of?" InnerSource comes with a set of roles and processes that +bring clarity to what otherwise would indeed lead to chaos: + +* Each +InnerSource project has a set of Trusted Committers with clear +accountabilities that go beyond simply reviewing code. Trusted +Committers set the rules for contributions. +* Contributions happen in a +structured way: +** Contribution intent is shared early to make sure the +contribution fits within the Host projects' vision and scope. +** Progess +is shared early so the host team has a chance to mentor the contributor +and guide them on the path to a desired design and architecture. That +way frustration due to having to decline a contribution late in the +process is avoided. +** Decisions and vital communication happens +asynchronously to be able to work around differing meeting schedules of +people in different teams. As a result contributing teams gain autonomy +to fix upstream artifacts without sacrificing the quality of the +component that is being contributed to. + +As a side effect InnerSource provides teams with best practices that +make working in a remote first culture easy. + +=== Advantages of an InnerSource approach + +Instead of working in silos InnerSource fosters collaboration between +teams. Much as in Open Source that means standing on the shoulders of +giants: Instead of building every component locally InnerSource fosters +reuse. It reduces the cost of reuse by providing a clear path to +supporting the upstream team with the work of fixing bugs and +implementing features. + +Much like in Open Source InnerSource fosters a thinking of combined +forces: Components that all business units and product teams need as a +foundation can be built together. As a result all the boats are rising +together: Innovation created in one part of the organization can create +benefits all over the entire corporation. With teams that are familiar +with InnerSource the load to move this type of innovation forward can be +shared by all teams that benefit from and depend on the resulting +components and services. + +InnerSource gives your team the initiative and tooling to fix issues +that block shipping features to customers. When done right maintenance +of core components and services can be shared in a well structured way +by a "virtual InnerSource team" that is larger than any specific +product team. + +In advanced settings those involved understand the value of contributors +working on simpler features that may not directly benefit their +customers - under the condition that it frees the host team to work on +more complex changes that contributors have a business need for. + +=== Does InnerSource replace Agile? + +Short answer: No, not at all. Instead the two complement each other: + +Well factored and well tested code is one goal of any agile team. In an +InnerSource setting on-ramp times for team members but also for +team-external contributors get shorter. + +Teams familiar with collaboration who avoid assigning tasks are in a +good position to also deal with external contributions in a flexible +manner. They also bring a mindset and communication style that works +well for motivating contributors over whose priority they have no direct +influence. Working with intrinsic motivation instead of directing work +means that host teams have the tools to successfully collaborate with +contributors. + +Teams pairing to work on problems are already comfortable with sharing +progress early. There are two challenges moving to InnerSource from a +pairing only culture: The host team needs to make time for supporting +contributors and schedule that into their planned work. In addition when +crossing team boundaries it is often hard to find time slots for pairing +- in those cases it should be complemented with asynchronous +collaboration. To avoid frequent disruption, host team members often +need to intentially plan their day more rigorously in InnerSource +settings. Often it is simplest to set aside certain hours in the day or +a day a week for mentoring contributions. Making that explicit at the +team level takes a lot of pressure off the engineers trying to fulfil +their own team goals but also helping out contributors. Another +challenge with pairing is that it allows pairs to move very quickly +together - often at the expense of writing important information down +for the rest of the team. In an InnerSource setting it does take +training to remember to bring all relevant decisions back to shared +communication channels for both, host team and contributors. From a +product perspective that does bring a lot more transparency to the +development process. It also means that decisions that otherwise may +have been taken at the engineering level only are now visible for +everyone involved. + +Remember last time you insisted that your product be well tested, +preferably with automated tests so deployments can happen frequently and +without human intervention? This goal now helps with InnerSource as +well: Contributions are much easier if contributors can check locally if +their changes are safe. Tests also ensure that the host team remembers +to keep the contributed functionality if they are reminded of the reason +for it by a failing test. + +Remember last time you insisted on your team spending time to follow the +goal of "leave code in a better shape than you found it"? That mindset +helps in the InnerSource model: It makes sure that quality and cohesion +of code remains high even when there are multiple contributions from +different sources. + +=== Common misunderstandings when coming from agile teams + +InnerSource and Agile uses some of the same tooling - for different +purposes. + +==== Impact of overlapping language + +Issue trackers: In agile teams user stories are a conversation with the +customer. Often the are put as sticky notes on a whiteboard. But also +often they are stored in an issue tracker. As a result issue trackers +are mainly perceived as planning tools, essentially a replacement for +sticky notes on a whiteboard. In InnerSource, issue trackers serve for a +conversation with the customer, but also for communication between +members of a team of trusted committers and contributors working on one +common InnerSource component. Issues in InnerSource become much more +lengthy and wordy than in your average organisation. They also track the +implementation history and detailed design decisions for a change. + +Code Reviews: In traditional organisations code reviews often serve +auditing purposes. + +They are done when development is finished. In InnerSource code changes +are shared very early in the process, sometimes when nothing more than a +rough sketch is done. The goal is to seek early feedback and mentoring. +This is particularly helpful for teams that are on diverse schedules and +cannot find any time for pair programming. Often teams have the +aspiration that nobody walks alone - in reality though this often isn't +much more than an aspiration never achieved. In particular where +contributions cross team boundaries. + +Tools used in InnerSource can formalize this ask for more than one human +to be involved with any change. + +Focus on written communication: The goal with InnerSource is for the +project to be transparent enough so that developers who are not part of +the team can understand project decisions and follow along the process +of software creation. As a result all communication needs to be in a +place that everyone interested in the conversation can follow along: +written, public, searchable and linkable. The goal is not to reduce +distractions to others - the goal is to make all project conversations +transparent. + +As a result direct messages and mails are to be avoided. In order to +make following conversations easier for everyone, messages related to +one InnerSource project should be tracked in one separate communication +channel: The goal is not to reach every person in the team of the +InnerSource project. The goal is to find a common shared room for +everyone involved with the project where they can have discussions +focused on that InnerSource project. + +Focus on written communication does not mean verbal communication is +disallowed. There still needs to be time for a shared cup of coffee. +Also solving problems together, pairing with others or in person +hackathons are valuable to find solutions quickly. The team needs to +make sure though that all project relevant decisions are kept in +channels that everyone has access to. That also may mean to postpone +important project decisions until everyone is back from vacation or +waiting for another day or two if those working in another country are +now on holiday. This is not only relevant for coding decisions, but also +relates to general project mission, roadmap and direction. Without that +information contributors will have a hard time understanding which +contributions will have a good chance of getting accepted. + +==== Impact of trust + +All discussions in InnerSource projects are visible to everyone in the +company. Blaming people for their errors, ridiculing them for their +mistakes, talking behind their backs about what they did wrong is a sure +fire way to kill that trust and leads to the failure of that InnerSource +project. This is particularly important for anyone in a leadership or +role model position. diff --git a/project-leader/03-capacity-planning.asciidoc b/project-leader/03-capacity-planning.asciidoc new file mode 100644 index 00000000..b10e3381 --- /dev/null +++ b/project-leader/03-capacity-planning.asciidoc @@ -0,0 +1,87 @@ +== InnerSource and Planning + +Planning plays a role in InnerSource in two important situations: + +Contributing teams need to understand that working on upstream code +typically does need more time than making comparable changes to their +own codebase that they are well familiar with. They need to be aware of +the fact that even if the host team does not have to implement the +change they still need to be available for mentoring and reviewing. The +time needed for that increases with the size of the change required. As +a result early communication with the host team is important in +particular in cases of larger changes. + +Host teams also need to be aware of the time needed for mentoring and +reviewing. Simply telling contributing teams that they can submit +changes as patches does not reduce the time to make the change to zero +for the host team. In addition host teams can find themselves in the +rare situation where they are flooded with pull requests. For that event +there needs to be a clear understanding of business priorities for the +projects sending these pull requests. When overwhelmed with patches it +is often time to think about sharing ownership of the component. In +particular contributors that are coming back regularly and have earned +trust of the host team are good candidates to receive the title Trusted +Committer. + +Some friction due to slightly different work culture cannot be avoided +though. For these cases it is important to explicitly set expectations. + +=== Setting expectations + +Imagine the following situation: As a contributor you finally made the +change needed - likely with a little help from the host team. You +proudly submit the pull request. Then - nothing happens. A day later - +still no reaction. You start wondering if the host team has seen your +patch. You wonder where to best ping the team about an update. This +silence is very frustrating in particular for first time contributors. +There are several remedies to this situation - remedies that need no +coding knowledge, but require at least some basic communication skills: + +* Make reaction times that can be expected of the host team explicit - +e.g. in the contributing documentation. +* As soon as a pull request is +received communicate the expected time it will take to receive +substantial feedback instead of letting contributors wait. +* Communicate +ways for contributors to get in touch with the host team and watch +communication there. + +Neither of these tasks needs code writing skills. This underscores the +need for people beyond those who have programming knowledge. It is good +practice to consider people covering these tasks as committed to the +InnerSource project and include them as Trusted Committers as well. + +=== Small vs. large changes + +Small changes and patches are easy to handle - they are quick to review +and often do not carry a lot of risk when merged. One way to help host +teams is to make time for splitting changes into smaller chunks. Make +sure to communicate the wider context these changes belong to though. + +Often making larger changes requires communicating intent and purpose +early. It can also be benefitial to make sure contributing team and host +team have enough time set aside for working on the change together. This +means that people setting team priorities need to think beyond their own +team when prioritizing changes. However coordination can still happen +fairly independently as typically only the pair of contributing and host +team are involved. + +=== Increasing the team around your InnerSource projects + +Rarely host teams run into the challenge of receiving too many patches +from contributing teams. In that case it helps thinking about moving +trusted contributors to the Trusted Committer role. In addition to +simply help with reviews, new Trusted Committers can help with issue +triage, mentoring new contributors and the like. + +When faced with a lot of interest in contributions one additional factor +to consider when prioritising mentoring help for contributors can be +interest of the contributors in a long term relationship with the host +team. The more time is needed for mentoring, the more likely it should +be for contributors to stick around longer. + +In practice sharing ownership of the component with very active +contributors has proven to keep the newly minted Trusted Committers +engaged with the project over a longer period of time. Typically they +help keep the component up to date and mentor new contributors long +after the initial motivation for the contribution has been addressed. diff --git a/product/04-negotiation.md b/project-leader/04-negotiation.asciidoc similarity index 98% rename from product/04-negotiation.md rename to project-leader/04-negotiation.asciidoc index 125529ba..333096a3 100644 --- a/product/04-negotiation.md +++ b/project-leader/04-negotiation.asciidoc @@ -1,16 +1,18 @@ -# InnerSource and negotiation skills +== InnerSource and Negotiation Skills Coding and negotiation? You may ask yourself how these two go together. In particular for InnerSource host teams it helps to have a few stumbling blocks in mind when it comes to change negotiation. -## Small vs. large changes +=== Small vs. large changes As discussed in the last training segment, smaller code changes tend to get accepted faster. For the host team the advantages are clear and should be communicated to contributing teams: + * They are easier to review. * They have less impact - both, positive and negative. * They are faster to integrate. + As a result making small changes in an ad-hoc fashion typically causes little to no friction. They are a sweet-spot for drive-by contributions and often can be handled without much coordination support. Typically this is how InnerSource contributions start: Engineers in teams start collaborating on smaller changes and find that work very easy and light weight. @@ -20,6 +22,7 @@ This may cause teams to adopt a mindset where InnerSource is only for the softwa However this learned ad hoc working model breaks as soon as the scope of contributions increases. If kept purely to software engineers, in the worst case even with push back from other roles in the teams this means that escalations will happen way more often. For modifications with a larger scope other roles in the contributing and in the host team need to be aware of the InnerSource work and need to bring their skills to the table: + * Together, the two teams need to figure out a good time for working on the contribution. If the host team has no time for mentoring the contributing team is more likely to get frustrated for lack of support. They may also be more likely to develop a solution that is likely to need a lot of rework causing frustration for everyone involved. @@ -29,7 +32,7 @@ Ideally this also means that tech and business level expertise needs to come tog Often this results in negotiations around if the changes should be made in the InnerSource project - with maintenance subsequently covered by the host team. It can mean that those involved need to clarify what the value for everyone involved is, but also if and how the contributing team can help the host team lower the maintenance burden. -## Coordination +=== Coordination "Just write the code and send us your patch" - sounds easy enough. Except in reality this is only true for the most trivial changes. @@ -64,4 +67,4 @@ As a next step the host team needs to think about expanding the number of Truste As mentioned earlier one option could be inviting people committed to the project who report to a different business line. In particular when faced with a lot of contributions that are fairly complex, host teams need to understand where the time invest to mentor contributors is a worthy investment. -The more time needed for mentoring the more likely it should be that these contributors will have time to stick around for longer. +The more time needed for mentoring the more likely it should be that these contributors will have time to stick around for longer. \ No newline at end of file diff --git a/project-leader/05-shared-ownership.asciidoc b/project-leader/05-shared-ownership.asciidoc new file mode 100644 index 00000000..b7ea0c60 --- /dev/null +++ b/project-leader/05-shared-ownership.asciidoc @@ -0,0 +1,181 @@ +== Options for Shared Ownership + +"If everyone owns it, nobody is accountable." Traditional +organisations perfer to have a single point of contact in case of +issues. On the other hand allowing simply everyone to make changes +surely will result in a mess that can no longer be maintained. + +Based on that observation each InnerSource project has a dedicated team +of Trusted Committers. Interest in maintaining an InnerSource project +often is motivated by enlightened self interest: A team understanding +that they themselves need the InnerSource project to fullfill their +customers' needs and understanding that opening the project up for +contributions can spread the workload to move the project forward. +Opening a project up for contibutions though doesn't mean that Trusted +Committers have to accept all submissions. It is the team of Trusted +Committers that sets the mission and goals for the project. They are +then in a postition to set direction and decide on change acceptance +accordingly. + +=== Ownership misconceptions + +"Trusted committers are responsible for an InnerSource project. They +review submissions and mentor contributors." + +This is a very simplistic summary of what the role of a Trusted +Committer looks like. In reality one of the first questions often +revolves around the need to accept each and every contribution. In +particular where contributors have already invested a lot of time in the +contributions can become frustrated when hearing that their work was in +vain. Communication skills are important to make sure that contributors +know roughly what the roadmap of the InnerSource project looks like. +They are also needed to make sure that contributors know to share intent +and progress very early on to avoid spending a lot of work without +results. Last but not least rejecting contributions needs very good +communication skills. To cut a long story short: Even if you are not +writing source code yourself, your support is needed to clearly +communicate the vision of the InnerSource project, to potentially help +when contributions need to be rejected. Another aspect that becomes more +important as the InnerSource project becomes more popular: Review and +mentoring become more time intensive and over time need to be scheduled +into the day explicitly. This does have impact on general capacity +planning and should not happen "under the radar". + +On the other hand for contributors it is important that code review is +not a last stage quality gate. Instead it is a way for continuously +guiding contributors through the code development process ideally +leading to better results faster. For that to work out in practice there +needs to be time and space for team building - but across traditional +team boundaries. Having at least a vague understanding of the different +cultures in teams makes misunderstandings much less likely and the +contribution process much more smooth. + +In particular when host teams are flooded with contributions project +leaders that otherwise focus only on their local team need to take a +more global perspective: +* Help the team understand different priorities +for incoming contributions depending on overall company strategy. Often +not all contributions are equally urgent. +* Another way to help the team +is to take over tasks like issue triage, handling initial responses to +contributors and guiding larger contributions through the process. You +can help your team by communicating to contributors if integration of +the change takes a bit longer. +* When faced with larger contribution +requests teams can benefit from help negotiating with other teams the +best time to work on these contributions. Often that is still way faster +than your team doing all the work on their own. In particular first time +contributors may need some hand holding - in particular for larger +changes. Coordinating the timing around that mentoring can be a big help +for your team. + +"But we could simply fork permanently" ... a misconception where +potential guest teams believe that simply copying the code would be +faster. + +In the short term that is true. In the long run it means added +maintenance. As a project leader you can help your team understand why +contributing changes to the project you depend on is in the best +interest of the business: Less work overall. Maintenance for the long +term is taken on by the host team. + +=== InnerSource governance levels + +"We are using pull requests to develop our component - so we are using +InnerSource on a daily basis". While using pull requests and reviews is +a crucial component, it is just the baseline for InnerSource projects. +Just because two projects you depend on use pull requests on a daily +basis does not mean that their openess to team-external contributions is +the same. + +InnerSource comes with different best practices. In order to avoid +confusion and frustration for contributors it is important for host +teams to define for their InnerSource project which governance model +they want to adopt. Much like in Open Source these governance levels can +differ substantially. + +In the InnerSource Commons we provide an InnerSource pattern that +defines at least three governance levels: +* Source code is visible to +everyone - but the team has no time to mentor contributors. From the +outside this may look like your everyday InnerSource project. Making the +refusal to mentor and accept contributions explicit though avoids +confusion from colleagues trying to interact with the project through +InnerSource means. Instead this communicates to those depending on the +project that only feature requests and bug reports can be handled by the +team. Essentially that means falling back to a regular traditional +software development project. +* Source code is visible to everyone - +plus the team of Trusted Committers has set aside time for mentoring +contributors. For these projects patches and pull requests are welcome. +The team of Trusted Committers makes sure that project relevant +communication happens in a written, archived, searchable and linkable +channel. The team also makes sure that project relevant decisions are +taken where contributors can see and follow them. Final decision making +though rests with the team of Trusted Committers - and becoming a +Trusted Committer of the project is tied to working for the initial +project team. +* As above - but the team of Trusted Committers is open to +the idea of sharing write access. This approach requires a process for +building enough trust with contributors for the team of Trusted +Committers to share write access. This is particularly helpful where +there is a long term relationship with contributors. Shared write access +can remove the review bottle neck. +* In the final stage the team of +Trusted Committers is also ready to share control over who gets write +access next as well as project vision and mission. While this will often +result in the highest level of committment from contributors it also +requires a high level of coordination crossing team boundaries. It also +requires the highest level of transparency when making decisions about +the project. + +To summarize each governance level needs a different approach to +collaboration and coordination +* Increased sharing increases the need +for communication and co-ordination. +* Increased shared accountabilities +can slow down decision making. + +=== Explicit pointers for contribution + +What is implicitly clear for team members is best made explicit and +documented if the project would like to encourage contributions. Topics +like +* Response times to expect when submitting changes, +* communication +channels to use when getting in touch with the team of Trusted +Committers, +* communication channels to use when trying to follow the +project as a contributor +* governance levels to expect from the project +are all topics that the entire host team has to agree and communicate to +contributors. + +=== Impact on leadership + +Increased sharing of accountabilities for InnerSource projects also has +an impact on performance reviews. In hierarchical settings those often +consider contributions local to the team. InnerSource contributors +however are starting to have an impact outside of their own teams. +InnerSource Trusted Committers have an impact on teams that can be +outside of the scope of their own team. That means direct line managers +are losing a certain level of control. They are also losing direct +oversight. As a result, performance feedback from potentially remote +teams should to be taken into account. + +=== "You build it, you run it" in settings with high sharing levels + +A common best practice for cross functional teams is a "you build it, +you run it" setup. With contributions potentially coming from +downstream users this best practice seems to break. There are several +ways to use InnerSource in that context as well: + +* Option number one is +to move to greater modularization and collaborate only on the parts that +are the same across teams and keep operations local. +* Alternatively +work with contract tests to avoid API breakages. +* Work with internal +service level agreements, make contributors sign up to warranty periods +to remove the fear of the host team that contributions break production +systems. diff --git a/project-leader/06-relation-to-open-source.asciidoc b/project-leader/06-relation-to-open-source.asciidoc new file mode 100644 index 00000000..a8efe640 --- /dev/null +++ b/project-leader/06-relation-to-open-source.asciidoc @@ -0,0 +1,106 @@ +== Relation to Open Source + +InnerSource is the application of Open Source collaboration best +practices inside of the confines of corporations. This makes +understanding two aspects of Open Source easier for teams through +parallels with InnerSource: + +=== Governance levels + +Much like in InnerSource, Open Source projects have different governance +levels. Not all Open Source projects are created equal: While some +groups only publish the source code, expecting no interaction, others +want downstream users to become active and submit patches. Other +projects have processes set up to allow for sharing impact on the Open +Source project. Understanding these governance levels means that +deciding which open source project to use in house will take Open Source +governance into consideration as well. A downstream user of an +InnerSource project will have learnt to correctly evaluate the balance +between moving fast but being unable to influence a project vs. moving +at a slower pace but being able to influence a project together. + +=== Building a platform together + +Working in InnerSource projects helps teams practice what it means to +share the cost and effort to build platforms together. Sharing the work +across teams helps innovate faster overall: Product teams with different +focus areas can join forces to develop a needed base platform faster and +share the resulting maintenance load. + +The same dynamic drives several Open Source projects as well. +Understanding it means that participation in these projects is natural +for any team that has experience with InnerSource. Knowing that dynamic +from practical experience also makes it easier for teams to recognise +which open source projects are being developed according to these +principles. Typically this understanding subsequently also has an impact +on which Open Source projects teams decide to use internally. + +Platform features that many teams need can then be created by +collaborating instead of re-implementing them locally over and over. +That makes it easier to understand the concept of how sharing effort can +help to make the pie bigger for everyone and how it can help drive +industry standards if done in an open source way instead of only +internally. + +=== InnerSource? Or Open Source? + +In terms of mechanics both practices are very similar. The major +difference is the visibility of projects: For InnerSource that is +limited to the corporation, for Open Source they are public. + +What sounds like a tiny difference on paper is a huge difference in +practice. Going Open Source means that each and every message is +publicly visible and potentially archived forever. This implication can +be very uncomfortable in particular for employees not used to that way +of working. In addition all actions being public means they are also +available for public scrutiny - no longer can every move be vetted by +corporate communication experts. Similarly produced artifacts are +available for public scrutiny wrt. license compliance, security and the +like - e.g. for competitors, for potential future new hires, for +customers. + +On the other hand it also opens the door to collaboration with others +outside of the walls of one corporation - taken to the extreme that can +result in co-opetition where competitors join forces to build a common +technical platform, innovating and competing against one another on top +of that. + +Going open source also reduces the tax implications of collaborating +across the boundaries of legal entities. While transfer prizing as a hot +topic for many InnerSource effort it is irrelevant for any Open Source +project. + +=== Participate upstream - gain by sharing + +While "what about publishing projects as Open Source" often is the +first thought when talking about becoming active in the Open Source +space. When experienced with InnerSource it becomes clear that +publishing entire projects is only one way of being active in the open +source space. + +Instead it is much more natural to adopt an enlightened self interest +point of view: +* Where teams use certain Open Source dependencies in +vital parts of their components it is important to ensure being involved +upstream - even if the only goal is to understand the future roadmap of +the project. +* Where teams have a need for changes in open source +projects they depend on, experience with InnerSource makes the +advantages of participating upstream obvious: Clearly it is not only +about a "sharing is caring" mindset - but it does have clear economic +benefits where contributing teams have a highly reduced maintenance +overhead if their changes are integrated upstream. + +Taking another step back even the decision of which Open Source project +to adopt and use internally will be influenced by the InnerSource +experience of a team: +* InnerSource trains teams to understand what to +look out for in terms of ways of collaborating and communicating - from +personal experience they will understand why it's important for project +to have clear, archived, searchable communication channels. They will +also understand why it's important that every major project decision is +taken on these communication channels. +* Understanding the different +governance levels in InnerSource teams are well prepared to understand +the implications of Open Source projects operating according to +different levels of openness. diff --git a/project-leader/index.md b/project-leader/index.md new file mode 100644 index 00000000..4ae5f842 --- /dev/null +++ b/project-leader/index.md @@ -0,0 +1,4 @@ +--- +title: Learning Path - Project Leader +--- +This section covers how InnerSource fits with other aspects of project leadership including agile, open source, capacity planning, and more. \ No newline at end of file diff --git a/product/outline.md b/project-leader/outline.md similarity index 100% rename from product/outline.md rename to project-leader/outline.md diff --git a/scripts/generate_learning_path_markdown.js b/scripts/generate_learning_path_markdown.js index a44d8d87..000c5449 100644 --- a/scripts/generate_learning_path_markdown.js +++ b/scripts/generate_learning_path_markdown.js @@ -93,23 +93,22 @@ const getArticleImage = (youTubeCode) => { writeMarkdownFile(fileName, frontMatter, body) }) - // Workbooks not translated. - if (!isTranslation) { - const workbookFileName = join(baseWritePath, 'workbook.md') - const contributors = await getContributors(`workbook/${section.workbook}`) - const workbookPosition = articles.length + 1 + const workbookFileName = join(baseWritePath, 'workbook.md') + const contributors = await getContributors(`workbook/${section.workbook}`) + const workbookPosition = articles.length + 1 - const workbookFrontMatter = { + const workbookFrontMatter = { title: 'Workbook', contributors, image: section.workbookImage, weight: workbookPosition - } + } - const workbookReadPath = join('..', 'workbook', section.workbook) - const body = asciidoctor.convert(fs.readFileSync(workbookReadPath, 'utf-8')) + const workbookReadPath = join('..', 'workbook', section.workbook) - writeMarkdownFile(workbookFileName, workbookFrontMatter, body) + if (section.workbook && fs.existsSync(workbookReadPath)) { + const body = asciidoctor.convert(fs.readFileSync(workbookReadPath, 'utf-8')) + writeMarkdownFile(workbookFileName, workbookFrontMatter, body) } }) }) diff --git a/scripts/section_data.json b/scripts/section_data.json index da54925d..18f8358f 100644 --- a/scripts/section_data.json +++ b/scripts/section_data.json @@ -30,5 +30,13 @@ "workbookImage": "images/learn/workbooks/Learning Path-Product Owner Workbook-image.png", "image": "images/learn/LP_thumbnail_productowner.jpg", "renderArticles": false + }, + { + "learning_path_group": "Project Leader", + "dirName": "project-leader", + "workbook": "", + "workbookImage": "", + "image": "images/learn/LP_thumbnail_projectleader.jpg", + "renderArticles": true } ]