Workbook

Why 1 is incorrect: InnerSource allows other teams to upgrade your software to meet their needs. You can’t depend on other teams to take on your own priorities, nor can you assign a project to another team. InnerSource relies on voluntary contributions, and works where the interests of the guest and the host team align.

Why 2 is correct: Large organizations that assign different teams to different parts of a code base routinely suffer battles over priorities. What’s critical to your team’s business plan may be seen as an extraneous annoyance to the host team that owns the code. With InnerSource, you add the code you need directly to the other team’s project, although you are responsible for following their guidelines and the host team vets it before it goes in.

Why 3 is incorrect: If a third party delivers a proprietary solution, you can’t participate in its development. However, free and open source software from third parties offers excellent opportunities for collaboration. The skills you learn doing InnerSource can be applied to open source projects outside your company, and vice versa.

Why 4 is incorrect: InnerSource exploits the desires of other teams to enhance your software. If your software is mature and doesn’t need many changes, there is no reason for you or other teams to enhance it. Your skills can be directed to new projects.

Why 1 is correct: When each team is responsible for a single code base, different teams tend to add code to their particular code bases to implement the same feature. This is not only wasteful, but can lead to incompatibilities. With InnerSource, the teams collaborate on adding code to a single code base to implement the feature.

Why 2 is incorrect: InnerSource allows team members to set their own priorities. It is a voluntary system that features grassroots participation. In fact, at its best, it reduces the involvement of high-level managers, allowing them to put their efforts toward other strategic needs of the organization.

Why 3 is incorrect: InnerSource is not magic. The same amount of work is needed to write a thousand lines of code as before. People engage in InnerSource to make sure they get the code their projects need, and invest the necessary time to write it.

Why 4 is incorrect: The whole idea of InnerSource is to spread around maintenance as well as new features. Anyone in the company who sees a problem is empowered to fix it. Teams use InnerSource because they see widespread participation as a strength.

Why 1 is incorrect: InnerSource is a technical activity in which developers (both contributors and trusted committers) participate, supported by product owners. Although meeting the needs of end users is the ultimate goal, end users do not determine who does the work or how it is done, and therefore are not part of the communications and activities that constitute InnerSource.

Why 2, 3, and 4 are correct: The three keys roles in InnerSource are the contributor who creates the basic contributions (code, documentation, and guidelines), the trusted committer who mentors contributors, and the product owner who represents the needs of the organization.

Why 1 is incorrect: It’s unreasonable to think that every engineer can understand all the company’s code. Each engineer needs to understand only the code that has an immediate impact on his or her work. However, InnerSource allows engineers to explore the code from other teams to the depth they want, and to contribute to other team’s code while having a limited understanding of it. The engineer may simply read one function and provide a bug fix, for example.

Why 2 is incorrect: Trusted committers vet each change. InnerSource places responsibility closer to developers, lower in the organizational hierarchy, and frees product owners to concentrate on strategy and requirements.

Why 3 is correct: Are trusted committers are chosen by their community for their demonstrated ability to write excellent code, their communication and mentoring skills, and their knowledge of the code and the team’s goals. They review all contributions before allowing them into the code base.

Why 4 is incorrect: InnerSource, unlike open source, keeps code within the company. Of course, teams are free to bring in outside experts (such as for security reviews), but this is not part of InnerSource.

Why 1 is correct: Every development team has to maintain standards for coding style, structure, quality, security, and general adherence to the project’s goals. Although these are written and shared with contributors, the trusted committer is the key transmission point where the team conveys its guidelines to outsiders.

Why 2 is incorrect: The goal of InnerSource is to empower outsiders to contribute to a team’s code, offering the mentoring in quality control as well as standards and guidelines. It would undermine the whole premise of InnerSource if a member of the team did the writing requested by the outsider; that would simply be a traditional response to a feature request. Furthermore, if the trusted committer wrote the code, InnerSource would simply impose new communication burdens without removing any programming burdens.

Why 3 is correct: A contributor’s code is an excellent starting point for training the contributor. Mentoring can produce educational and personal growth that is even more beneficial than the code contribution itself. And contributors, even if competent and knowledgeable about the code base and team’s goals, can benefit from guidance to bring their contributions in line with a team’s goals and standards.

Why 4 is correct: The trusted committer, along with educational and mentoring responsibilities, plays the typical role of a committer on a project, ensuring that the code works well and does not break something else in the application.

Why 1 is correct: The host teams open their code base to others and put effort into vetting contributions precisely because their code end up better and with more features than if they did all the coding themselves.

Why 2 is incorrect: InnerSource has no impact on the definition of requirements and priorities. As with any professional software development, developers have to understand their users.

Why 3 is incorrect: Contributors from many teams submit changes to the code, one hopes, during periods of high-volume activity. This means that the host team has to juggle many interactions with outsiders. The result, however, is more code in a short period of time.

Why 4 is incorrect: Outsiders make contributions come to projects that they recognize as important, The importance precedes the voluntary donations of code. Because InnerSource solicits voluntary contributions, outsiders work only on projects that they see as important. However, a team can ask outsiders to contribute, by persuading them that the project is important.

Why 1 is incorrect: InnerSource has no effect on funding for a team. It’s true that managers of other teams can allocate money so that their own team members can work on high-priority code in other teams. They pay their own team members to work on code, not the members of other teams.

Why 2 is incorrect: InnerSource is not open source. The code is not published outside the company. However, some companies choose to open their code at some point, turning an InnerSource project into an open source one.

Why 3 is correct: InnerSource invites company staff outside the host team to work on the host team’s code. The host team benefits from the outsiders’ understanding of their users’ or consumers’ needs, as well as from the new features added.

Why 4 is incorrect: InnerSource can be a valuable force multiplier during time crunches, bringing people from many teams together to complete high-priority code quickly. But after the crunch, people go back to working on projects within their own teams.

Why 1 is incorrect: InnerSource blurs the responsibilities taken on by each team. Its goal is to enable people from one team to collaborate with another. The outsiders learn not only the host team’s code, but its style and standards. In InnerSource, the host team encourages outsiders to take on increased responsibility for its code.

Why 2 is incorrect: Traditional training is still important for basic skills such as learning programming languages, development tools, and good software engineering techniques. However, mentoring can enhance this training, and is an important part of InnerSource.

Why 3 is correct: On a large project, one team often produces services consumed by other teams. The team coding the service often doesn’t understand the ultimate purpose and requirements as well as the teams that build upon the service. InnerSource improves communication between teams, and lets the team with the greatest knowledge of the user put its code directly into another team’s code base after vetting by the host team.

Why 4 is incorrect: Requirements are not closely related to the decision to use InnerSource. For instance, InnerSource allows developers inside and outside a team to negotiate features as they go along. It is compatible with either a rigid requirement setting (a waterfall model) or a loose requirement setting (an agile model). But because InnerSource tends to devolve power and decision-making to outer leaves of the organization, including individual developers, it encourages people to set their own requirements within the context of the project, and to change them to meet new aspects of the environment.

Why 1 is correct: Trusted committers are chosen because of their superior performance at coding tasks and their commitment to building a community. Therefore, their behavior serves as a model to others in the pursuit of better code and a stronger community. Many contributors aim to become trusted committers.

Why 2 is incorrect: Trusted committers continue to participate fully in all the activities of their team. The trusted committer role intensifies their contributions, rather than replacing them. They also need to keep coding (although probably not as much as before) in order to understand their team’s code well enough to help outside contributors and judge their work. Finally, the trusted committer role is temporary for some developers, and they plan to go back to full-time coding.

Why 3 is correct: When a single team develops its own code, team members tend to share a tacit understanding of the code and its goals. They may need no vetting, or may provide minimal vetting. InnerSource brings in outside coders who need more careful checks of their code, because they will come to the project with their own views and experiences.

Why 4 is correct: All contributions can benefit from a second pair of eyes. So trusted committers review code both from outsiders and from their own team.

Why 1 is correct: Education is often most effective and long-lasting when learners focus on specific projects and derive general lessons from their own efforts. Few learning experiences are more powerful than asking someone to write code and then explaining how it can be improved. This is a key role for the trusted committer.

Why 2 is incorrect: Writing great code is a wonderful preparation and prerequisite to being a trusted committer, but mentorship is more than example. Mentorship must actively try to teach others and improve their ability to code in the project.

Why 3 is incorrect: Each trusted committer role is coupled to a specific project and is designed to help individual code contributions to have the support that they need for their contributions to be accepted into the code base. Most trainings and presentations are designed with a large audience in mind and so have a more generalized topic. Trusted committer mentorship mostly happens at a one-on-one level.

Why 4 is incorrect: While pair programming can be done remotely, there’s no guarantee that contributors can coordinate specific times with trusted committers. Trusted committer mentorship happens mostly asynchronously and digitally.