Workbook

Why 1 is incorrect: Open communities are not a dictatorship. As a contributor, you are part of a community helping the solution to grow and thrive. This may involve compromise at times, but will pay longer term benefits to you and the community.

Why 2 is incorrect: Reducing the amount of work needed to get a customer feature implemented is one of the main reasons for InnerSource. It’s correct that contributing changes back to host projects means that the host team becomes aware of the change and will take it into consideration in any refactorings that they are making going forward. That way the work that you as a contributor have to do to adapt to new versions is being reduced significantly. Still that does not imply that on acceptance the host team will be the only people responsible for making sure the change you submitted works as intended: The 30 day warranty pattern provides a formal means to defining how long contributors are responsible for fixing issues in the modification they submitted. In practice contributors often move closer to the host team and provide their expertise going forward.

Why 3 is correct: Shared solutions develop out of contributions from interested parties. Becoming a contributor allows you to shape the solution, always in consultation and collaboration with other community members.

Why 4 is correct: Contributions go beyond just code. There are many aspects that help to keep a solution healthy and thus make it successful, different aspects require different skills, though don’t make one more important than another. If the code is the machine, then think of these areas of contributions as the grease that keeps the machine running smoothly.

Why 1 is correct: When many teams across the business have the same need, an InnerSource project is a great way to meet those needs at scale without duplicated work.

Why 2 is incorrect: If you skip the chance to leverage code that is already written, you will waste time coding solutions to problems that are already solved rather than adding unique value in your team.

Why 3 is incorrect: You can ask, but there may be times where the next need that you have in the project is not the next priority for the host team to work on. In these cases you can still get what you need by making an InnerSource contribution to the project.

Why 4 is incorrect: Working on other features of a project, or doing background work such as reorganizing code or documentation, may indirectly contribute to your team’s success, so it is legitimate for you to invest time on those things.

Why 1 is incorrect: Even if your team may play a more central role in the company, you are still the guest when interacting with an InnerSource project. Ultimate accountability for decisions made about the project lies with its trusted committers.

Why 2 is incorrect: There is nothing wrong with asking good questions, and they should be responded to in a timely fashion. However, you are a guest and need to respect the time and effort of others in the community. Therefore, make sure to read and understand all available documentation before asking questions, and be prepared for answers from any educated project member, not just host team leaders. This helps your status in the community and avoids randomization.

Why 3 is correct: InnerSource stresses the creation of documentation, both as background to the work (for instance, README.md and CONTRIBUTING.md, and to justify individual decisions and code changes. The reason for a culture of documentation is to provide you, as a contributor, with the background you need to fit your change successfully into the project.

Why 4 is incorrect: Getting your contribution accepted is an achievement to be celebrated. However, your involvement does not end there. You should plan to be available at a minimum to fulfill a 30-day warranty on your changes (and their impact), or even better: stay close to the community and help out with additional contributions.

Why 1 is incorrect: Before contributing, you need to communicate your intent to other project members. Surprises in projects create a great deal of confusion, wasted effort, and irritation. Early and open communication will send a clear message of intent and will increase the chances of a smooth contribution experience.

Why 2 is incorrect: Great contributions are valued in open, shared solutions, but keep in mind that you are a guest. Suggested changes to the code may be rejected for many reasons: because they run counter to the intent of the solution, do not meet the coding standards, etc. This is not a personal reflection on you but a professional decision. Mitigate this by understanding the outlined requirements in the project documentation (README.md, CONTRIBUTING.md, etc.) and the project plans for the future. If documentation is missing, ask about the project’s standards, expectations, and plans. Your first contribution may well be to write or review the missing documentation.

Why 3 is correct: Projects need people to be engaged and stay atop of the open issues, help to fix issues, and weigh in on plans. Staying engaged will help you build a positive reputation and provide you with the opportunity to learn more about the project’s problem space.

Why 4 is incorrect: When engaging, you should engage with the community as a whole (all the guests as well as the host in our metaphor) and work in the open. Physical location or organizational location should not play a role in how you engage or with whom you engage. After all, InnerSource is about working together across boundaries for everyone’s success.

Why 1 is incorrect: For many reasons, contributions to an open and shared solution will likely take more time than changes to a closed, single-team project. For example, coordination with the host may not be straightforward as it is with your immediate team. Your interests and the hosts’ interests may not easily align, and compromises may need to be found. Logistics may also add overhead, such as simply working in different time zones. To mitigate against these delays, plan with additional time. This will alleviate stress and tension and increase your chances of a successful engagement.

Why 2 is correct: Through communication, you allow everyone to understand your intent and give advice where needed. Communication ensures that you understand the plans and goals of others and can work together optimally for the greatest impact.

Why 3 is incorrect: Contributing a feature or bug fix is not the time to introduce a different coding or documentation style. Changing coding styles and convention in a project is a big undertaking, so you should rather align your changes to the coding and documentation styles in the project. If a different code style is needed, bring it up as an issue and have a discussion with the hosting team and the other participants outside of your current contribution.

Why 4 is correct: Small-scoped changes are easier to understand, not only in the code involved in the review, but also regarding the impact your suggested change may have on the rest of the solution. Limited-scope discussions will lead to a quicker acceptance of the changes and thus a more immediate benefit to the solution.

Why 1 is correct: You should delve into the documentation that is provided to answer your questions. When you recognize that your answer is missing from the documentation, or is not clearly enough explained, asking a question to the project is the right next step. Not only will a clarification get you moving again, it will help future contributors.

Why 2 is correct: Having proper tests for the code you write is a general good engineering practice to ensure that the code is robust and maintainable. In an InnerSource project, the tests also help to build confidence in you as a contributor. Automating the tests as part of a code integration process also allows InnerSource projects to spread maintenance across all trusted committers of the project, independent of their membership status with the team the InnerSource project originated from. Thus, continuous integration and continuous delivery (CI/CD) are valuable in InnerSource.

Why 3 is correct: Checking tests and documentation for any needed changes are part of a solid contribution and will help guide future contributors down the right paths.

Why 4 is correct: Code conventions were put in place to enable all participants to understand the code quickly. Your changes need to blend in with the current existing code styles and conventions to ensure that your contribution is also easy to review and maintain by all others.

Why 1 is incorrect: You have to work within the constraints of the shared project. In that respect, InnerSource is really not much different from working within a healthy team.

Why 2 is correct: In shared projects, you effectively pool your resources, thereby multiplying your impact and the speed at which features can roll out.

Why 3 is correct: As you interact with people outside your immediate team, more people will learn to know you, your work style, and your abilities, thus helping to build your reputation.

Why 4 is correct: Interacting with other engineers from different teams will broaden your knowledge and scope, thus helping you to design and build better code.

Why 1 is correct: Once the contribution has been integrated into another team’s project, it becomes an integral part of it. The contributor usually maintains responsibility for the new feature for an agreed-upon grace period, after which the hosting team maintains the code just like the rest of the project. However, your team should stay engaged, because you depend on the code and know it well. This will help to maintain your influence and avoid surprises down the road.

Why 2 is correct: Organizational changes are a fact of life. People change jobs, organizations need to adjust to new company directions, and so on. When key knowledge is restricted to a single individual or team, it can get lost fairly quickly. When the knowledge spreads through the community using the shared code base, there should always be someone with enough knowledge to help drive the project or solution forward in a consistent manner.

Why 3 is incorrect: Contributions are not a means for gaining leverage over others. They are a means to share a common path to the benefit of all participants. The attempt to use contributions as a lever to gain advantage is often met with harsh criticism, even triggering a split in the community and a fork of the code, which in this case is unhealthy and undesirable.

Why 4 is correct: Contributing to an InnerSource project gives you the best chance of ensuring that the shared project has the functionality needed for your scenarios. Not only can you contribute code to accomplish what you want, but the InnerSource process creates communication channels and decision-making procedures that take your views into account.

Why 1 is incorrect: InnerSource should be adopted in order the align development more closely with the goals of each team, but not for cost savings or staff reduction. InnerSource projects require just as much coding (and somewhat more communication) than siloed projects. Satisfaction, however, should be higher at the end among teams as well as customers.

Why 2 is correct: InnerSource adopts, from the open source model, the principle that all discussions and decisions should be written and preserved. Through mailing lists and forums, comments in the version control repository, and bug reports, the organization preserves information about the goals of the project and the trade-offs developers have made. This is valuable later on for many purposes.

Why 3 is correct: InnerSource practices connect developers to both code and people with whom they wouldn’t normally interact. These connections spread technical knowledge about specific projects and create new social avenues where knowledge flows more easily in the future. Both of these aspects have the result of reducing siloed knowledge in the company.

Why 4 is correct: As projects are shared more widely, the teams using them tend to come in closer alignment as a necessity of using the same shared code base. This shared vision reduces duplicative work and is an overall benefit to the company.