Why Openness is Not Optional

Home / Linaro Blog / Industry / Why Openness is Not Optional

When we started Linaro, we spent a lot of time discussing how it would operate.   Most ARM companies have a culture of secrecy, and why not?  After all, the mobile phone space is worth billions of dollars and demands a relentless pace of innovation.  Worse still, it ruthlessly punishes missed deadlines and ‘nearly’ products.  This culture of secrecy becomes a problem and an easy default position (I call it the ‘foetal position’).  It takes a more sophisticated view of open source to realise that there is much that has no business being secret.

We all recognised the need for some secrecy around plans and details of unreleased products but we felt that openness was key to interacting in a positive way with the open source community.  Having our meetings, planning and engineering completely open also meant hugely simplifying the legal agreements.   Before we made this implicating assumption, the agreements were complex and difficult.   Once we decided that everything is open and ‘outside the firewall’, the legal position was hugely simplified.
The secrecy habit was hard to break.   When we first held TSC (Technical Steering Committee) meetings, we would take notes and circulate them for comment before publishing them (see http://wiki.linaro.org/TSC). After a few times of doing this, we moved on to taking the minutes there and then.  It often amuses me when I look for minutes of meetings within various open source consortium (and you know who you are!) that I cannot find anything public.   No meeting minutes, plans, code etc.   Why the secrecy?   I suspect that it’s more of a habit than for any practical reason.  Linaro’s problem is the exact opposite, there’s so much information there that it can be hard to find out what is going on.   We’re working on that.   As well as hacking code, Linaro is also hacking project management, but more about that in another blog.

Linaro can, and does, handle secrecy, but it’s the exception rather than the rule and it is confined to Linaro’s member relationships.   Here we discuss roadmaps, align work (in their Landing Team and elsewhere) and ensure that our members get the most value out of Linaro.  If you go to connect, that’s what all of those private meetings in the afternoon are about.

Speaking of Connects, at the last Linaro Connect, in Copenhagen at the end of October, I realised a couple of other really important things about being an open organisation.   The first is obvious when you think about it.   If everyone implements a feature in secret, they will all implement it differently and fragmentation will occur.   That’s how ARM Linux was before Linaro.  However, when a few work together in the open, there’s a guide to be followed and even those continuing to work in secret can align.   We’ve seen this happen several times.  One really good example is the consolidation work within the ARM sub architecture maintenance group hosted by Linaro.   Non-members working in secrecy have followed the same trajectory as the Linaro members and have aligned, accelerating consolidation within the ARM Linux kernel.  I’d like to see this effect happening with the ARMv8 platform support, but first we need a ‘correct’ example of an ARMv8 platform.   This is why I’ve been pushing Catalin Marinas, the ARMv8 Linux kernel maintainer to publish his Vesatile Platform support.

The second, important byproduct is in roadmap and operational planning.  Making Linaro’s roadmap(s) and detailed planning public, helps members align their plans with Linaro.  It shows what Linaro is doing, when it expects to finish, how it tests its code and so on.  If this information is not clearly accessible, you end up having one to one discussions with each member, involving the technical leads, project managers etc.  Having the information openly available and easily navigable helps communication with Linaro’s members.  Especially important now that we’ve launched the Linaro Enterprise Group (LEG) and we have more members to work with.

Recent Posts

Showing 3 comments

  • Jef Spaleta

    So how do you reconcile those private member meetings at the Connect event with the recognition of the problem that “If everyone implements a feature in secret, they will all implement it differently and fragmentation will occur”?

    Have those private meetings give you a heads up about ongoing non-communicated work being done in parallel by multiple member entities so that you can steer work on those parallel implementations into an open workgroup process? Any examples you can talk about where you’ve been able to redirect what would have otherwise been duplication of secret sauce implementations as part of those Connect private meetings?

    -jef

    • David Rusling

      The private meetings tend to be about as yet unreleased products and so contain sensitive dates. They’re mostly about aligning plans. For features, the members work directly with the working groups. So, for example, there are some big.LITTLE implementations going on, so there’s a lot of cross chatter with the Power Management Working Group. This split works because Linaro is doing general frameworks and the members are adding in platform specific support.

      big.LITTLE is a good example of avoiding fragmentation, both via internal and external meetings. For ARMv8, ARM did the initial kernel work, but we were involved in reviewing code before it was released.

pingbacks / trackbacks