It's this last point that resonates. Too often companies release code that's useful for themselves and hope a massive community will arise around it ... to make it even more useful for that company. Open source foundations have largelyfollowed this same self-centered logic, pretending at open governance even as a single vendor controls the outcomes.
Not that LinkedIn was always a paragon of this open source community virtue. As Perisic describes, "One lesson we learned early is that you can't just put software out into the community and not continue to innovate. We've also learned that many of the things that determine whether an open source project will be successful are related to how you engage with the community."
This means, he suggests, that the hardest work begins after code has been open-sourced. For example, LinkedIn has learned the importance of reaching out to the community for feedback and ensuring that the goals of your project are easily understood. Critically, though, the most important decision, Perisic stresses, is the first one: "deciding whether it makes sense to open-source a project in the first place." If you're not prepared for the ongoing work of open source, it's better to not open the code at all.
Given the difficulty inherent in opening code and growing a community around it, why bother? Though much of the value flows outside LinkedIn, a big reason for engaging in open source communities is the effects it has on engineers, according to Perisic.
"We've found that the first result of open-sourcing your projects is that your developers will write better software." Keeping code behind closed doors encourages sloppiness, encouraging a developer's "tendency to cut some corners. This especially happens when it comes to documentation, making code easily readable, and having all the right tests in order."
Opening up code, however, opens up a developer to criticism -- very public criticism. In Perisic's words, "When a developer open sources a piece of code, their reputation is on the line. It's essentially a type of peer review. This gives developers a huge incentive to make sure that their code that is well written, well documented, and reusable."
But it's not about good code hygiene alone. It's also about ensuring developers don't become parochial in their outlook. "Working on an open source project exposes [our developers] to the developer community outside of the company where they work. It will help them become more aware of new trends, and help them learn how to assess the value of other developers' input." In this sea of differing opinions, "developers learn how to lead their own teams more effectively."
Finally, Perisic notes, "from a company's perspective it also helps develop your engineering brand, which proves useful in attracting new talent and retaining existing employees.
Sign up for CIO Asia eNewsletters.