The ins and outs of InnerSource

Recently, you may have seen the announcements that Red Hat has become a supporting sponsor of the InnerSource Commons (ISC), and you might have wondered what that is all about. Here’s the story of how Red Hat went from keeping InnerSource at arm’s length to discovering how it makes sense to work together.

After all, Red Hat is committed to working with open source projects and innovating with free and open source software. InnerSource, as a concept, is regarded as a set of practices, derived from open source development methods, to produce any kind of software–open source or proprietary–within a given organization. The short version? InnerSource is a way of practicing open source methods inside the organizational firewall.

Because of this, InnerSource is a way of embracing some of open source's known benefits in order to drive specific kinds of changes. The problematic word in that sentence for folks like me was “some.” It’s great that you can use open source methods and culture to innovate and create better software, but if at the end of the day that software is not open source, it felt like InnerSource was an appropriation of the best parts of open source development and culture. So, the Open Source Program Office (OSPO) tended to be indifferent to InnerSource, preferring instead to have conversations about complete open source best practices with customers, partners, and community members.

To help with these conversations, Red Hat’s OSPO launched efforts like The Open Source Way, a community-led effort to gather community best practices under a Creative Commons license that anyone can modify and use however they want. At Red Hat, we use the Open Source Way as our “upstream” for training and enablement materials that we share with customers and partners, and we encourage anyone else to do the same and add new content when they are able to.

But over the years and through many conversations, we began to notice a pattern: We would have a series of meetings with decision-makers at these organizations, which would seem to go pretty well. We communicated the benefits of open source, solid and interesting questions were asked and answered, and customers would walk away with a better understanding of, and willingness to practice, open source for themselves.

Except when they did not.

Follow-up discussions with these organizations were almost universally along these lines: Organizations were very excited about the benefits of open source but were running into opposition within the organization. This opposition typically fell into one of these categories:

• Concern about the loss of the organization’s intellectual property (IP)
• Difficulty adopting open source/open organization cultural practices
• Lack of knowledge about day-to-day open source best practices

These are all valid reasons why open source contribution practices are not growing within an organization. And they can be interconnected: If people aren’t familiar with and using open source development practices, then they are less likely to be confident about working in ways that befits an open culture. If the open culture isn’t in place or is weak, then there is usually a lack of confidence about IP, because there is no innate understanding and trust in how open source communities and projects work. There are, of course, exceptions, but in our experience this tends to be the general theme.

If this observed behavior is correct, then a solution presents itself: Start showing people exactly how to actually do open source, tactically. Yes, we (and other organizations, like the TODO Group or OSPO Alliance) can offer great strategic advice about licensing, governance, communication, and general practices like our “upstream first,” but in actual execution, what does that look like? So we rolled up our sleeves and started planning out a new collection of educational materials that focused on the tactical aspects of open source practice.

Serendipity is a funny thing, because about this same time, early 2023, I had a conversation with Clare Dillon, then executive director of ISC. In that conversation, at FOSDEM in Brussels, I learned that while my perceptions about InnerSource weren’t entirely wrong, they weren’t entirely right, either. 

Turns out, there’s a strong aspect of the ISC that very much does want to get the people they are working with towards full open source practices. One of the specific purposes and aims of InnerSource is to prepare for open source in a safe space. It’s not a requirement, of course, but the idea that the ISC was using open source practices and culture only as a means to an end was an inaccurate perception on my part. It also turned out that the ISC’s educational materials were already very much focused on the tactical aspects of open source development and–serendipity again–the ISC is lacking a bit in the kind of high-level strategic materials we already have.

The idea of our partnership came about on that rainy Saturday morning: While Red Hat would always consistently promote the creation of open source software, our two organizations clearly could immediately help each other. Later conversations with Clare and her successor Russell Rutledge have revealed other ways our collaboration might produce materials that assist not only our respective organizations’ customers and partners, but the open source ecosystem at large.

Red Hat and ISC share the belief that open source practices and culture are the key to rapid innovation and progress. We are happy to announce this partnership and look forward to bringing new open culture and development knowledge to more people than ever before. Look for collaborative content from Red Hat and InnerSource Commons in the coming months!