Is your Open Source Program Office just part of your corporate defences, or is it the community’s advocate inside your company as well?

As we considered before, corporations are not a person, but are rather a vehicle for the collective expression of the vision of many individuals, showing the outworking of the processes and systems they devise to embody their vision. So the work of an Open Source Program Office (OSPO) needs to address social change within the company and address community needs outside as well as compliance or other corporate self-protection.

Lessons from Sun

As a technology company takes the road to open source, their approach to everything has to change. This can take some time. At Sun back in 2004, the decision to fully embrace open source came right from the top, yet it still took perhaps two years for that understanding to spread across the whole company and even by 2009 there were still one or two hold-out product groups refusing to comply. I was running what I think was the industry’s first fully-staffed Open Source Office (now called an OSPO) at that time. Despite the CEO’s strategic decision clearly articulated internally and publicly, we kept finding activities which an open source company just wouldn’t do. Sometimes we found out through the press. During the transition period while the “open source way” was spreading like Aslan’s breath, I think we were entitled to some benefit-of-doubt.

From my position as chief open source officer and with direct support from the CTO and CEO, I was usually able to stop harmful things happening. A notable exception was refusing a Java testing license to Apache, where the commercial folk finally outvoted me. But I also won some (and you never knew). In one significant but never-disclosed incident I learned of an OEM deal with a company actively attempting to destroy Linux and got the CEO to cancel it just before it was announced. By the time the Wall Street crash of 2008 killed our legacy funding, Sun had re-established itself as an open source community member.

On our watch Sun made its code in the boot-loader open source; we released details of hardware interfaces to allow open source drivers to be written; we released the tool chain as well as the design source for SPARC chips; we fixed a licensing anomaly that someone stumbled on in ancient Sun-RPC code that had found it’s way into Linux; we learned to make patent non-assert pledges; we GPLed Java rather than writing yet another license and devised ways to be very transparent of our motivations around OpenJDK; and we eventually learned about joining the existing community instead of starting our own. That’s just a selection; Sun’s OSPO was pretty busy, especially the Ombudsman function we created! In addition to all this, of course, we were overseeing the license compliance work you’d expect.

OSPO: Compliance Or Community?

It is thus possible for a corporation to address localised sociopathy if its leaders want to, by giving their open source co-ordinator air-cover from the CEO-level to challenge and change legacy behaviours. But an OSPO has to be dedicated to more than just license compliance to achieve this. When after an extended period the sporadic “local” sociopathy continues, that might still be tolerable as long as it’s a different case and area each time. But if a particular harmful behaviour continues over an extended period, one can only conclude that it’s open source that’s a localised tactic rather than a corporate strategy, even if the locale is large and the OSPO loud.

The test for whether the corporation’s procedures and goals have been corrected to stop sociopathies is whether, over time, they become less frequent and stop. When they don’t, it seems fair to assume the OSPO is just a compliance fig-leaf deployed by the leadership as a cover for a reality they know is problematic but which they don’t intend to change.