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?
Klaas-Jan Stol, Brian Fitzgerald mentioned in their article that you can view Inner Source as a bazaar within a corporate cathedral, referencing the two organizational models that Eric Raymond describes in his famous book “The cathedral and the Bazar”.
There are three dimensions where you have to pay attention when you are going to start the journey to Inner Source: product, development methodology and management system.
Characteristics you’re going to need to include in your management system.
“We know that the more power you give a single individual in the face of complexity and uncertainty, the more likely it is that bad decisions will get made.”
James Surowiecki, The Wisdom of Crowds
Software communities run away from hierarchy and feel more comfortable on net structures hierarchy with certain values. They are:
- Collaboration. Opening the one team’s code to others, allows software reuse through applications and components are available for everyone in the the company. Moreover, “Given enough eyeballs, all bugs are shallow.”, according to Linus law.
- Self management. Everyone is allowed to make the decision they consider. Coordination emerge from each person’s adaptation.
- Transparency. there’s no Inner Source without transparency. It’s a no negociable value, because the most value of software communities is the strong sense of meritocracy. Moreover, transparency is the shortest path to reach common goals.
- Confidence. The the underpillar for transparency and for make the things done quicker. You have to create an environment where failing is taking as a lesson and as a knowledge not as punishable.
- Participation. It’s important to fight against silos and encourage the participation between teams. Communities have also to take care about the landing of new members and promote respect between the member, in order to gain the most of the people’s contribution.
- Learning. Open communities are competitive and encourage developers to be better at their work. Open communities stimulate and accelerate learning enabling the mobility across projects.
Open development teams must be managed with different rules and values (governance); you need a new culture in your firm and it takes time to built it. Take it easy and in the meanwhile make your approach to new software development methodology and start thinking which project would be the right one to start Inner Sourcing… We will give you some clues in next posts.
Hi, thank you for this post I agree with you that Opening the one team’s code to others, allows software reuse through applications and components are available for everyone in the the company. very useful information