Implementing Open Source Internally—Key Elements to Success

Creating efficiency with InnerSource—key elements to promote effective review, approval, and the automation of collected documentation.

istock 509290786
iStock

In Part 2 of this 3-part series, we outline key elements within the implementation of InnerSource as a secure open source software development tool.

Reliable, trusted commitership is key to the processes of review and approval before initial production. At first, you may have to put your best developers in the role of mentoring and reviewing/approving commits instead of writing code, which may seem like you’re letting them sit idle. “I recommend 10% of your engineering workforce should be conscripted to trusted committership,” said Danese Cooper, Founder and Chairperson at InnerSource Commons, and a longtime open source advocate. “If you don’t have that 10%, you will be in trouble when InnerSource starts happening.”

Another key to porting successful open source projects over to closed shops via InnerSource is what Cooper calls, “the automatic accretion of actionable documentation.” 

“[Apache] made an early decision that anything that is important needs to land on the mailing list so that it can be archived and people can discover it later and research into it,” Cooper continued. “If you have a meatspace conversation that’s material to the development of this software, it never happened unless you memorialize it on a mail list, period.”

Apache’s projects have become prolific.  Your documentation storage doesn’t have to be a mailing list—it’s no longer 2004, and better tools exist. With every bit of conversation about a project automatically visible and searchable, new contributors can both search for answers and step through the log of development decisions that is the documentation center.

Speaking of better tools, Cooper and her foundation have been talking with folks from Stack Overflow about how to use our Stack Overflow for Teams product as the documentation hub in InnerSource implementations. “I think that your engine (Stack Overflow for Teams), as I have interacted with it in the open source world, would be a pretty good bet,” said Cooper. “As GitHub has taken over development—I think it is a brilliant tool—and as the new crop of kids come in and want to make everything their own and do it slightly differently, they don’t realize they’re throwing the baby out with the bath water when they have half the conversations on Slack.”

In fact, that’s exactly what Intuit has been able to do. They used Stack Overflow for Teams as their documentation log. If an Intuit engineer had a question, they were encouraged to get it out of the black hole of email (or chat) and get it into the permanent record of Stack Overflow for Teams.  

“If Intuit has been able to use it,” said Cooper, “I imagine there’s some others who’ve been able to use it.”

Implementing these changes company-wide takes a fair bit of work, but the rewards are great. In 1999, Tim O’Reilly, Brian Behlendorf, and Bill Portelli founded CollabNet with the intention of doing two things: 

  • Create a brokerage service between open source developers and anyone who wants work done. 
  • Teach companies to use open source methods internally.

Sounds a lot like InnerSource, right? Like many projects in technology, it may have been a good idea that arrived too soon. CollabNet failed to get traction and pivoted to products to support DevOps and Agile processes.

“When I looked at why companies couldn’t get there, it was always cultural,” said Cooper. “It was always their prejudices about how engineering was supposed to happen.” Traditional engineering, especially around the turn of the millennium, was focused on everyone building their piece of the product, then crunching in the two weeks (or, heaven help us, longer) before release. People were invested in their piece of the process because they worked at it and made sure it shipped with as few bugs as possible. 

In 2014, Cooper saw that clash happen in person when she took a job at PayPal with the intention of bringing some open source magic to their internal development lifecycle. “When I got inside the company and started listening to where they wanted to go, I realized that they had no business doing open-source engagements until they understood collaborative development.”

That traditional engineering culture respects owning your little piece of the product from beginning to end. “If you have an excess of ownership culture, you have silos, and that means you have knowledge that is held by few people,” said Cooper. “If those people all go away, you have orphaned code.” Companies are left with broken, hard to maintain code—and new hires have to spend a lot of time parsing the mysteries left by their predecessor. 

“A big problem with the silo system is that people’s ownership makes people sort of Gollum-ish, right?” said Cooper. “Getting senior devs to part with their precious is the first step. But it’s in their best interest—I don’t know any engineer that likes being bombarded with chat messages because they’ve kept the secrets to their fiefdom siloed away. For companies, breaking down walls between codebases means bottlenecks go away.”

Stay tuned for Part 3 of this 3-part series where we’ll explore the benefits of collaboration and innovation within code reuse and general maintenance.

If you missed part 1, click here.

 

Want to learn more? Listen to Intuit’s Journey to InnerSource.

Join Stack Overflow’s Director of Product Vasudha Swaminathan, as she sits down with the members of Intuit’s engineering team to discuss all things InnerSource. You’ll learn:

  • What is InnerSource?

  • The benefits of InnerSourcing

  • How to gain support and adoption

  • How to enable collaboration across decentralized teams

  • What tools support InnerSourcing

Related:

Copyright © 2021 IDG Communications, Inc.