The InnerSource Spain community had its first meeting, and we are already planning next steps. Let’s start by briefing first meeting outcomes.
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!
We are pleased to announce that we are writing a book about inner source.
We have been collaborating for some months with companies that are developing this methodology to produce the software they need. They were pioneers who early on realized that inner source has lots of benefits for talent management, software development, and business improvement. And now others are asking us for advice about implementing inner source.
So we have decided to bring together all our knowledge about inner source, share it and ask for open collaborations. We want to do this as openly as possible. We are building it as a GitBook, posting each chapter and asking for reviews. We will announce each part on our blog. So stay tuned and don’t miss a thing!
We are all used to open source projects. Concepts such as community, code review process, continuous integration, geographically distributed contributions, community managers, and a whole myriad of terms and collaborative way of working are usual for all of us. And enterprises are learning from this open process. Those are changing the direction of their development models to a more open one within the organization. Initiatives such as the Inner Source Commons where companies such as PayPal or Bloomberg are publicly exposing their case, help others to deal with the usual problems they face.
Once again, Bitergia has been invited to participate in the Linux Foundation Open Source Leadership Summit (previously known as Linux Foundation Collaborative Summit). This time, we have new things to show, based in the work we are doing currently for The Linux Foundation and several of its collaborative projects such OPNFV, CNCF, OCI, Xen and Cloud Foundry (details to be published soon!).
- Diversity in Open Source Projects together with Susan Wu from Midokura and Nicole Rutherford from Intel, on Tuesday 14th, 1:45pm – 2:15pm
- Technical Debt for Linux-based Distributions: Estimating What You are Missing together with Paul Sherwood from Codethink, on Tuesday 14th, 4:10pm – 4:40pm
- Community Dashboards for Linux Foundation Projects: From Open to Inner Source Metrics, on Thursday 16th, 4:00pm – 4:30pm
If you are around, don’t miss the chance to meet our colleagues, join our talks and discuss about how Bitergia might help you!
Meanwhile, we have started working on ideas for next GrimoireCon and OSCON US 2017. Stay tuned or contact us for more information.
In a recent post we’ve seen how to set up Inner Source in your company is a cultural change question. Companies need to increase inner transparency, confidence and collaboration for breaking the functional silos in order to create a proper environment to develop software between motivated peers and enable code/knowledge reuse.
Open Source development communities use several tools for enabling collaboration and transparency. Companies can take advantage of them for their inner software development projects. Let’s see some examples from our experience tracking collaborative software development and helping companies in their Inner Source projects analysis:
“The idea is beginning to take root in even the most secretive corporate cultures… Its power lies in the inherent social nature of the creative process. When developers are able to access, use and build upon what their colleagues are creating, innovation can really take hold.”
Phil Granof in Wired
As we detailed in the previous post, adopting Inner Source practices creates great benefits for companies such as saving cost, faster time to market and enabling innovation.
There’s no doubt that Inner source needs a different approach to project management but “hands on!” What’s the best project to start Inner Sourcing?
Software is becoming the core of most business, even the traditional ones. However it doesn’t mean that companies should build all the software they need, most of it can be easily bought or outsourced with low cost, in order to focus their efforts on their core business. Thus, Inner Source should help to add value to organizations running away from commodity.
This was the case for Philips Healthcare. Klaas-Jan Stol and Brian Fitzgerald in their article Inner Source—Adopting Open Source Development Practices in Organizations recommended to start with a seed project. That means, not starting from scratch but choosing an existing initial implementation of a software product or component.
Frank Van Der Linden, CTO at Phillips was responsible for and pioneered the setting up Inner Source within the company. He decided to start with a component suite of DICOM (Digital Imaging and Communication in Medicine) standard, used in many medical imaging tools such as x-ray and MRI (Magnetic Resonance Imaging) scanners. Philips Healthcare has a product line for diagnostic techniques in Hospitals, so they chose a core business software product for Inner Sourcing.
Van Der Linden reports enormous business benefits using Inner Sourcing as a process for developing:
- Three times more product groups served.
- Substantially improved product quality (Improved feedback from product groups)
- Product groups find defects earlier.
- Significant time to market gains.
- Growing an active Inner Source community – Over 60% of the PH software community involved.
Philips and other companies running Inner Sourcing learned from Open Source projects, they understood how to align and coordinate efforts. In the next post, we will talk about essential tools to enable Inner Sourcing.
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?