North Bridge and Black Duck published last January their 2016 Future of Open Source Survey Results with a lot of interesting conclusions. Maybe the biggest one it’s that Open Source continue gaining force inside the IT business, but its management is chaotic because the lack of process.
Most common problems related on the survey were:
- Nearly 50% of companies have not formal policy and process for selecting and approving open source code.
- One of the major problems of that is security. 47% don’t have a formal process in place to track the code and only 19% of vulnerabilities are detected and fixed automatically.
- Nearly 1/3 has no process for identifying tracking or solving known open source vulnerabilities.
- Over 1/2 companies has no responsible to identify and tracking remediation.
Not everything in inner source is about community building [but a big portion!] and the infrastructure is basic to foster collaboration, transparency and community building.
This post is about aspects to have in mind when deploying the tooling needed to provide support to developers within the organization and across business units.
There is a more extended version of this infrastructure topic in the work-in-progress book about inner source: Managing Inner Source Projects that we, in Bitergia, are writing. Specifically in the infrastructure chapter. This is available under a CC-BY-SA 4.0 license and anyone is more than welcome to propose new sections, improve the current ones and collaborate in any way. Please feel free to redistribute!
In past posts, we talked about Inner Source and the benefits for your organization. Some large organizations, such Paypal or Zalando started their own process to approach Inner Source; we can say without a doubt that each of them has taken their own path, because Inner Source is more related to a philosophy or enterprise culture than to a process or static methodology defining it.
During last LibreCon we have been sharing some insights about it during our
Inner Sourcing and Software Development Analytics talk, and next months we are going to collaborate with some companies in their inner source approach. So it seems the right momentum to start a set of posts about “Inner Source”, doesn’t it?
Inner Source (or Inner Sourcing) is a term coined by Tim O’Reilly in 2001 that referenced to the,
“use of open source techniques within the corporation”.
Although more that 25% of the deployee code in the most influential IT companies was Open Source in 2015, IT departments didn’t show much interest in collaboration or innovation process. (Gartner, 2015).
But recently there are so many mainstream IT firms that are allocating resources to Open Source contributions, not only for the benefits of the code, but the benefits of the methodology brought to the organization such as collaborations, innovation and quality control.
Inner Source takes the lessons learned from developing Open Source software and applies them to the processes that companies follow to develop software internally.
Innersourcing’s benefits for the company