OSPOs As Community Advocates

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.

Corporate Maturity As Stochastic Outcome

Corporate open source maturity may be better evaluated by considering the actions of individuals and small groups statistically rather than evaluating the stated corporate strategy

It’s easy to forget that corporations (and indeed large non-profits) are not a person, but are rather a vehicle for the collective expression of the vision of many individuals, as well as the outworking of the processes and systems they devise to embody their vision. Things happen not because a faceless corporation somehow chooses to act in a certain way from a point in time, but because of the persuasive decisions of actual people, acting within their belief systems and directing the work of others.

Collective Behaviour

Every good – and bad – decision ultimately goes back to an individual somewhere, and corporate effects are in many ways emergent. So fitting a maturity model to a corporation may not be the best way to predict its future outcomes. That is a trailing indicator driven by the behaviours of the individuals within the company.

Continue reading

Hybrid PDF: Schrödinger’s Document

Need to send a file most people won’t need to edit? Send a file that’s both editable and final form at the same time, a kind of Schrödinger’s Document – a Hybrid PDF.

One of the scourges of e-mail is file attachments, and particularly those from people sending files made by their newly updated word-processor or presentation programme that half the people receiving it can’t open. While proprietary software vendors love this errant behaviour (it keeps up the pressure for people to re-purchase software they don’t really need so they can read other people’s work – AKA “upgrades” – or to subscribe to an online service that keeps them trapped), it’s really anti-social behaviour.

Continue reading

How Much Interoperability Is Enough?

Interoperability is primarily a matter of the use case, not of the technology. Policymakers considering interoperability mandates need to be watchful for extremes of perfection or compromise, which both offer a game to be exploited by the unscrupulous.

How I Learned To Type

Reviewers of a paper concerning interoperability complained that some sections seemed to imply only 100% functional equivalence would be acceptable, and told us “much smaller percentages are perfectly adequate.” So how much interoperability is enough interoperability? The answer, dear to the hearts of every politician, is “it depends”. 

Continue reading

Chalk and Cheese

How similar are open source development and standards development? Not at all, and even the words they have in common mean different things in each.

It’s a traaap

It is often asserted that open source and open standards are in some way similar. For example, in the accompanying letter to a recent submission to the European Commission, a major European-based technology company that is very active is standardisation said:

Continue reading

FLOSS Weekly 616: Software Heritage

Simon co-hosted FLOSS Weekly 616 this week and along with Doc Searls interviewed Roberto di Cosmo from (among other things) the Software Heritage project, which has the goal of archiving all the world’s software source code. The discussion was as wide-ranging as you’d expect, covering both the idea of software as a cultural artefact and the specifics of Software Heritage such as the unique IDs it gives every software version it archives so that software becomes citable in research. One particular topic was the grant programme that Sloan Foundation funds to get new connectors for Software Heritage written, which readers may want to consider.

The Dream of The Linux Desktop

In a (large) video meeting at virtual FOSDEM, someone joked that maybe this will finally be the “year of the Linux desktop”. One of the oldest jokes in the community. Everyone sniggered. But the joke’s on them: it already happened, like a thief in the night.

Virtual Brussels, home of Virtual FOSDEM

While we were all waiting for the open source community to topple Microsoft’s desktop monopoly by replacing the locally-installed operating system, we missed the real revolution. Sure, there’s still plenty of money in both operating systems and in desktop apps. Microsoft (and indeed Apple) will be milking that legacy monopoly for a good while even if they have started hollowing out themselves — on Linux. It’s certainly been the target of competitive attention from open source software from the beginning; indeed, the open source productivity suite family now epitomised by LibreOffice has over its long history done an effective job in opening up that part of Microsoft’s monopoly (even if mostly by triggering the creation of ODF).

Continue reading

Please donate to keep us afloat!
We’re not in anyone’s pocket so we rely on reader patronage.

Make a monthly donation

Make a yearly donation

Choose an amount


Or enter a custom amount


Your contribution is appreciated.

Your contribution is appreciated.

Your contribution is appreciated.

DonateDonate monthlyDonate yearly

Thank you for supporting Meshed!

The Missing Stakeholders

The coming wave of digital regulation may claim to target “Big Tech” but will inevitably end up harming citizen-innovators most because regulators have forgotten to include them in their process.

Tracks in the snow suggest a bird being captured by a cat.
Stakeholder-Citizen Interaction

Here come the regulators. “Big Tech” companies like Facebook and Google definitely deserve some guide-rails, as well as some consequences for the unwanted impacts they have foisted on society along with the desirable ones. Facebook in particular has some deep, serious consequences of its amorality due soon. But so far, pretty much every regulation relating to the digital realm is defective.

Continue reading

The Rights-Ratchet Model

It’s not new, even if each time it comes up people think it’s a new outrage.

Caged Bird of Paradise

One of the durable long-term strategies for software businesses in the era of open source was perfected by SugarCRM about a decade ago. I’ve described it as the rights ratchet model. The “ratchet clicks” (not necessarily in exactly this sequence) are:

Continue reading