How does your organisation manage open source governance? Do you have a standard policy in place? Do you revisit it frequently? And, do you involve your developers in the development of your governance policy?
In the research study Accenture completed last year, companies and organisations stated that building skills in open source products and technologies was a bigger challenge than open source governance. This was especially pronounced in public sector organisations.
I was surprised. Is governance really easier than skill building?
Skill building takes time, people need hands-on experience and formal training to learn new things—and they need to be motivated to do it. Trying to make unmotivated people learn new things is not really “motivational work”. So, yes, in some cases, skill-building can be really hard.
On the other hand, governance (and in this case open source governance) can sometimes be seen simply as a bureaucratic exercise. Policy in place - check, legal people involved and the required approvals received - check, policy communicated to all relevant people - check, mandatory one hour training on the policy taken by all relevant people - check. How hard can it be?
While open source is about openness and freedom, governance is many times about control—quite the opposite ends of the playing field.
How many organisations have implemented their open source governance on the policy level and then left it there without further action? Staying in their end of the field—forcing the other side (the developers) to come all the way across? The answer is many, if not most.
On the flip side, how many companies involve their developers in their governance activities? How many can state their governance is developer-driven?
Disregarding the developer community in developing an open source governance policy is just bad policy. Many times developers are well versed in the issues relating to open source governance: legal risks, IP leakage, security vulnerabilities, etc.
Can we trust our developers to always do the right thing? Maybe. Should we incorporate controls (think of Sarbanes-Oxley) to ensure that our open source policies are followed? After all, legal perspective is not about trust.
This conflict—managing controls in an open environment—is where mere paper policy fails. Implementing proper governance requires one to take the “people” perspective to be the most effective: How can we help the developers to do their work more efficiently? What are their suggestions? And, how can we help them “not” make their work more bureaucratic and cumbersome?
To put this new thinking in place, what is needed is good old change management. Put the people, the users, the developers, in the centre of it. Organisations need to understand the freedom and openness perspective and build the governance model out of it. Maybe your organisation’s developer community has some very specific modes of operation —if so, understand them. Essentially make sure you meet at least the developers at the half-way mark, if not a bit beyond it.
And what about the public sector? How do they manage the governance issue, is it an even bigger issue? I think the more formal procurement process actually gives the public sector an advantage over the private sector on the governance side. Moreover, the public sector can better share practices, whilst not being afraid of losing a competitive edge by exposing their approach and mechanisms to governance. As many governments around the world are encouraging the uptake of open source and want to see it as a real alternative in public bids, this will in fact be the next logical step.
Many times governance is viewed through the lens of using open source. The advanced class is when you zoom in on contributions - then governance takes on a whole new dimension. Maybe more about that in an upcoming blog post.
Want to learn more about what I think about open source governance? Listen to a recent webinar I did on the subject.
Posted by Tomas Nystrom, Global Open Source Lead, Accenture