This week we discussed the topic of Innersourcing – using open source philosophy, process, and tools to scale internal development teams. Dan Skaggs, Raymond Camden, and Tanner Linsley attended the episode alongside regular hosts, TJ VanToll and Dan Wilson. Each participant has deep experience leading, contributing to, and consuming open source. This episode went deep on topics like, what makes a great open-source project, how developers can scale their careers, scaling internal teams, building good development team culture, and participating in the broader development community. The recording of React Wednesday – Scaling Open Source Sanely with Dan Skaggs is now on YouTube.
The episode began with Dan Skaggs discussing an Innersourcing project he has led for three years for a global media conglomerate. Dan’s project involves developing and administering an application ecosystem centered around a distributed content supply chain. The project provides a substantial amount of core features needed by internal applications like authentication, data fetching, internal API integration, feature flag systems, and other reusable elements. The applications built to service portions of the global content supply chain all make use of features available in the Innersource style project.
Dan Skaggs claims his organization is substantially more productive using Innersourcing philosophy because the development teams share processes, code, and ideas beyond traditional internal development teams. It is vital to get the buy-in of individual developers on what methods and techniques to use. Because Innersourcing involves principles used by ultra-large, high-profile open-source projects, Innersourcing ideas are easy for developers to accept and use. Additionally, Innersource principles are refined over the years by diverse and often distributed teams working in the open.
Innersource philosophy means that software developers openly do their work. All internal developers have access to inspect and alter all of the source code. All Software developers participate in Pull Requests to validate the impact and effectiveness of software changes. Ideas and refinements cross-pollinate at a faster rate than traditional development.
On Golden Fences
At 7:21, Dan Skaggs introduces the concept of “Golden Fences” to the discussion. A Golden Fence is an intentional separation in a development organization that gives a small group sole responsibility and knowledge of a subject matter. If small groups hold dominion over a single software area, the company will suffer as crucial staff leave. Innersourcing removes Golden Fences and the risks thereof.
An organization that wants to implement Innersourcing must focus on building the right culture and awareness. Often employees, managers, and executives will have misconceptions about how Innersourcing will affect their organization. Dan mentioned an executive at the company feared there would be too much participation. Dan had to educate the executive on how the areas of responsibility would function. Most open-source developers understand the reality is there are too few contributors, rather than too many.
Key points in the conversation:
- Effective Innersourcing culture (9:40)
- How to handle shared dependencies in a monorepo (16:55)
- A discussion around selecting shared components and how it’s different in Angular versus React (20:55)
- Tanner Linsley, Kent C. Dodd’sAHA programming approach, and how to make appropriate decisions in architecture and React apps (23:02)
- The proverbial “Room at the top of the stairs where all the key decisions are made” and how to make the best choice for the organization and allow for local flexibility (24:27)
- Informing and educating large teams and executive staff about new platform capabilities (31:09)
Important Open Source Principles
Around the (39:00) mark, we shifted the conversation to open source principles. Raymond Camden is a prolific creator, maintainer, and contributor to open-source software. I asked him to share his thoughts about the elements of effective open-source projects. Raymond named documentation as the single-most-important piece of open-source software. Users of open-source software projects require documentation of features and capabilities to use the software correctly. Raymond raises an example of an open-source project that released a feature without documentation. When he criticized the project for not having proper documentation, the software project maintainers claimed the software was open-source, and he could take it or leave it. It is certainly understandable for open-source authors to feel like they are giving their work for free and that the open-source consumer should be grateful for what is freely given. Users won’t be able to use features without sufficient documentation, leaving the open-source author’s effort in vain.
At (41:54) I asked Tanner Linsley, a prolific open-source author and contributor, for his ideas on good open-source. He launched into an interesting segment about how there are many different motivations for a software developer to make software available under an open-source arrangement. Some developers want to release their work and don’t care about building a community or a body of users. Other developers want their work used by many developers. The end-user has a choice of what project to use. Open-source projects with a high degree of quality have the best chance for broad adoption. Tanner has very refined thoughts about open-source, and I agree with him. Open-source authors should make sure to listen to this part of the discussion.
How to Improve Internal Culture
Raymond Camden focused on the removal of friction for contributors. Open-source projects should evaluate their contribution practices to make it easier for contributors to help. If the act of helping is simplified, more people will do it.
Tanner Linsley advised organizations to permit their staff to participate in open-source projects. Software developers will grow from their experiences working on open-source projects. They will learn more collaboration skills, experience working with different ideas and structures, and gain knowledge that benefits their organization. Equally important, open-source contributors will be able to refine their communication skills and practice good communication habits.
In Closing
In closing, this discussion contains many exciting and useful ideas for open-source authors, contributors, and users. Organizations that want to scale their development resources will benefit by evaluating which parts of Innersourcing are appropriate for their circumstances, then implementing Innersource practices and culture.
