Started in 1999 and established as an official corporate function in 2005, Sun’s Open Source Program Office (OSPO) was among the first in the industry and maybe the first to use the name.
As I’ve discussed in earlier posts, corporations are the vehicle for the collective expression of many individuals. However, to the outside world they are a monolith, and are expected to be consistent as well as predictable in their actions. With the many varied, implicit expectations and explicit obligations that different open source projects have, transforming a company’s reputation into that of a good actor in open source is a complex task. It’s also a necessary one if you expect other actors to invest their time and work in your project, or to give you influence in steering a project together.
Starting in 1999 with just one employee embedded in a major software division and eventually growing in 2008 to a cross-corporate department that also covered standards development, the Open Source Program Office at Sun Microsystems (which went on to have a variety of other names throughout the decade as it evolved) was one of the first in the world. It was led by Danese Cooper under the title “Chief Open Source Evangelist” (informally “Open Source Diva”) until she went on in 2005 to work on open source at Intel. After discussion with Sun’s CEO and CTO, I took responsibility for the function.
As Sun’s ambitions in open source grew, placing open source at the heart of its technology strategy, we moved it out of product-specific groups and into the CTO’s Office with my title becoming “Chief Open Source Officer”. I had a modest – but wonderful – staff and a reporting line directly to the CEO, (by this time, Jonathan Schwartz, who had the vision to see that Sun’s technology stack would become irrelevant without the adoption that open source offered) and we kept going right to the end – the part of Sun where I worked was shut down in March 2010.
What did the Open Source Program Office do? From the beginning in 1999 onwards it had the same vision -– cross-company oversight of anything related to open source — using open source code, working with open source communities, establishing new open source projects and shipping products built from parts under open source licenses. More than that, we acted as an interface between the many open source communities of interest and the corporation: helping the community understand – appreciate, even – the company, and helping the company to read the room.
License Compliance
License compliance is both “entry level” open source (i.e. it’s a hygiene factor) but also highly specialised, certainly for a company with the degree of IP investments Sun was involved in during the early days of open source. I therefore did not actually have any staff working directly on license compliance as that function was covered by Sun’s legal department. They devised and ran a workflow system tracking inbound or outbound software as well as the licenses covering it. But we did get involved when a group was choosing licenses for new projects, or needed to work with an external licensor over an incompatibility issue. Back in those days CI/CD was not a “thing” (although the open source Hudson/Jenkins project that came out of Sun was probably key to making it a thing) so the tracking workflow was largely manual steps. But if I were doing this today, I’d make the compliance function part of CI/CD, fail the build any time there was a license issue detected and track escalations into the legal team.
Being a Trusted Actor
Inconsistent behaviour with no apparent accountability can mean that the hard won trust of consistent contribution can easily be lost by a misaligned policy or an incompatible license, to the frustration of a community who cannot find anyone to take accountability. That’s why I created an “Open Source Ombudsman” function that formalised what Danese and I experienced anyway. This gave communities a published single point of contact for escalation to resolve quickly potential community conflicts of policy, license and so forth. We would then investigate, take whatever remedial action was needed and liaise with the community reporting the problem. This was very effective; we liberated the code in the boot-loader that Sun turned out to own, we relicensed RPC code that had made its way into the Linux kernel so it could stay there, we found data sheets for old Sun hardware and built a wiki so BSD developers could write drivers, and plenty more things. There was also the matter of the overtures SCO kept making to Sun, but that’s a tale for another day.
Building Communities Around Technology
Across the history of the OSPO we all provided an internal consulting service as each Sun software product went open source. “Open source” is not a business model, of course, but an approach that gives many potential advantages to a business model. We would help product teams understand business models before they would then select appropriate licenses and governance structures. Liaising with existing communities covering the area served by the product, helping internal teams understand issues their approach might raise and attempting to address them. Emily Suter, who was indoctrinated with the Open Source idea by Bill Joy and Mike Clary while developing the Jini project at Aspen Smallworks in the late 90s, joined the OSPO and captured the bulk of these steps toward open-sourcing a new or existing project in a comprehensive internal Playbook.
On Danese’s watch Sun notably donated the code that became Apache Tomcat, Apache Ant as well as various XML-related projects to the Apache Software Foundation and worked through all the issues that these donations caused at both Sun and Apache. She also catalysed the creation of OpenOffice.org from StarOffice, the release of NetBeans, GridEngine, Glassfish, as well as the design of the CDDL and the release of Solaris under it, among many other projects.
In my time, we worked with the existing Free Java community to understand their outlook or concerns while also working with them first to get Java shipped in Debian and then to make the licensing around OpenJDK good enough that Richard Stallman was willing to withdraw publicly his “Java Trap” objection in a Sun promotional video. We (led by Emily) also catalysed release of the SPARC source and toolchain under open source licenses, much of the compiler portfolio, the release of Sun’s identity middleware and much more – not least supporting the purchase of MySQL. By 2008 we had Sun’s whole software portfolio open source (bar one compiler!)
Building a Community of Practice
It was a fairly obvious decision to run internal “Open Source Summits” to enable all the staff working on open source in every part of Sun to meet, discuss their work and discover new ideas. Led by Emily, these were very popular and effective. Peer relationships built trust, communications channels and friendships; so that every staff member could be the public face of Sun and not just the OSPO staff, just as the blogging movement in Sun (started by many of the same people) had unleashed so many as company communicators. Such activities can help cement a change in culture – or in the case of Sun’s relationship with open source, a sense of “getting back to our roots” since most Sun developers, especially those working on Solaris, had an instinctive sense for open source. Indeed, one of the first textbooks on open source for business was written by Sun researchers and includes an early print mention of the name “Open Source Program Office”.
Being Present
Communities run on relationships, which means it is vital to be present to forge and sustain these relationships. Clueful attendance at major community events such as OSCON, FOSDEM and FISL (in Brazil, supported by Bruno Souza) were essential, then, and we had to find creative ways to stretch our budget to make sure Sun staff met their peers in open source communities – kudos to Sara Dornsife that these are still mentioned on Twitter even today. This proved crucial to accelerating open source adoption in the company. One particularly important activity that was employed both by both Danese and by me was bringing together key community influencers to meet product teams each time a major release was contemplated.
Being Corporate
Sun’s embrace of open source was also a visionary business decision. We needed to do the work of understanding the projects and communities we wanted to work with; but we never took for granted the need to explain this strategy to the rest of the company, and indeed, to our commercial partners. This meant participating beyond community events to far more corporate settings – starting as early as 1999 with bespoke private briefings to CEOs of Sun’s partners such as SAP, BEA, Palm/Handspring, even briefings for high-ranking officials at US Homeland Security and the DoD as well as of course to the European Commission, along with more routine engagement such as explaining an open source strategy to Gartner analysts, Sun’s sales team (who not long earlier had been told that Linux was their enemy, don’t forget), delivering this message through traditional software marketing along with sales channels and directly to our key accounts.
We also engaged both with speech-writers as well as with Sun’s PR team to make sure that the messages executives and product teams communicated did not unintentionally cause a community incident. This was a time when plenty of FUD was still cast towards open source, around security and IP risk as well as around the apparent contradiction of making money while giving something away for free. Kudos to Patrick Finch for great work later in the life of the OSPO producing so much material and suffering endless internal reviews as a result! Ken Drachnik also served many hours handling company briefings.
Polymathic
In summary, an Open Source Program Office needs to understand the practice of open source at both a strategic and tactical level, understand the intricacies of software markets, incentives of community participants, communications, development practice while also considering change management. A good program office, then, is a blend of a diverse set of all of these skills and knowledge; bridging both internal and external divides to solve mistrust, build productive behaviours while also addressing the complex issues that arise in the gaps.
Thanks to Patrick Finch and Danese Cooper for working on this, and to Emily Suter, Ken Drachnik and Sara Dornsife for their reviews and comments.
Meshed Insights Ltd 
Pingback: The Week In Review: OSPOs | Meshed Insights Ltd