Inner source is the use of open source software development best practices and the establishment of an open source-like culture within organizations. The organization may still develop proprietary software but internally opens up its development. The term was coined by Tim O’Reilly in 2000. (Wikipedia)
In 2013, when I became in charge of creating a better development environment for thousands of developers, I was surprised by two main things: several teams were working in silos and were constantly reinventing the wheel.
Upon further investigation, I gathered these two points:
- Developers wanted to address this concern, but did not know where to start.
- Developers were too busy with their Business as Usual (BaU) activities, having hardly any time to work on common assets for the company.
I was deeply convinced that the way we worked would not sustain in the long run.
Fixing this situation became a purpose in my new position.
Let’s look at the approach we followed:
-
Listen to the Field
When the same situations, concerns and motivations are faced across various teams, you are probably identifying an interesting use case to address.
In that case, teams identified the need to collaborate, grow together and work on common interest, and this was a great motivation to improve their day to day activities.
-
Share Knowledge
So, we decided to Build a community to share findings, learning and best practices. This was a great platform to learn from each other’s experiences.
In this community we focused on technology, each developer came with his own skill set. This, coupled with open minds and a positive approach towards helping each other was key.
-
Create the Conditions for Success
Developers met once a week to share knowledge about solution upgrades, testing, performance and tips. After several months the willingness emerged to co-construct common technical assets between projects/teams, that anyone in the company could leverage on.
We introduced GitHub, in 2014, as our source code management system to enable this co-construction. The usage of this platform extended from the teams initially involved to the whole company.
The idea was to have one single platform that thousands of developers could easily benefit from.
At first developers used the platform as a basic Git, ignoring the collaborative features offered by GitHub. But thanks to the training materials/classes we provided, the overall mindset evolved.
-
Scale up by Raising the Engagement Level
Team managers were quite keen on funding the initiative given the success of the experimentation.
But after a couple of weeks, the end of year getting closer, the pressure of BaU increased. The development pace on enhancing and fixing the shared assets decreased drastically.
After removing many blockers/irritants by building communities, gathering funding, purchasing a collaborative platform, it was important to reinforce our leadership engagement level to preserve the collaborative momentum while ensuring the performance management of the company.
-
Challenge the Status Quo
We understood quickly that it is nearly impossible to promote the re-usability and cross-teams’ collaboration without change on our vertical incentive model or without alignment of our company’s performance goals.
Despite this difficulty, we have progressed a lot since 2013 with thousands of developers currently leveraging on our single GitHub instance.
We have gone a long way already, and we are still working on transforming our culture to the collaborative model
We still have a long way to go and it is one of my key areas of focus. I would be more than happy to exchange with you on the subject and share experience.
Amir Jaballah is the Head of Digital Transformation & the Digital Lab ASIA, at Societe Generale Global Solution Centre. In his spare time he enjoys street photography and portraying the local culture through his expressive art.
Originally posted on https://www.linkedin.com/pulse/5-practical-steps-almost-enable-inner-source-big-company-jaballah/
