Perceval goes on the quest to retrieve and gather data from git, GitHub, Bugzilla, JIRA, Gerrit, mbox, pipermail, StackExchange, Discourse, etc. for producing valuable indices, with GrimoireELK.
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!
As we were telling you a few weeks ago, we were joining FOSDEM, not only as attendees but as speakers.
We would like to share our experience, giving you details about our talks…
When looking back nowadays to the work done on diversity, I’ve realized that it has been quite a trip! My first approach to the topic was in an informal meeting with Nithya Ruff, currently at Comcast. She mentioned that the OpenStack Summit in Tokyo reached (as far as I remember!) 13% of women attending the Summit. And this was a great number if compared to previous summits as the percentage kept growing. But she also mentioned that they received a tweet asking about the current number of technical contributions. Then this is where we decided to have a look at that issue: have numbers, and try to produce some of them from a quantitative point of view.
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:
We are so excited about starting the new year with our contribution and participation at FOSDEM 2017.
FOSDEM is the strongest reference event for developers and geeks to meet and know the hottest incoming tech topics since 17 years ago.
In 2000, Raphael Bauduin, a Linux fan from Belgium, decided to organize a small event for Open Source developers. He named it ‘Open Source Developers European Meeting’ (OSDEM). From the second edition OSDEM became FOSDEM and every year host more than 5000 developers and Open Source geeks.
FOSDEM is our natural environment. We have joined it in a lots of editions and we are very proud to come again this year as speakers. We are also going to set up a stand for chatting with all our friends with special gifts for our community.
These will be our contributions to FOSDEM 2017:
“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.