Using a community FAQ as a way to get internal disagreement addressed and external communities on board – the OpenJDK experience!
In this talk from FOSS Backstage 2021, Rich Sands and I discuss the way we used a (very large) FAQ to both align the disparate corporate functions inside Sun Microsystems and address the lack of trust in Sun by both the Free Java community and the wider open source community. What we did back then is still a highly appropriate tool for any OSPO that needs to stand in the divide between a controversial corporate position and an aggravated community.
Software freedom is important to as an idea, but it also creates all the value of open source for business and should be jealously guarded by OSPOs.
In talking about open source, I and others routinely use the expression “software freedom” to refer to the set of rights upon which the open source phenomenon is based. It arises as a synonym for “free software”, an unfortunately ambiguous term that leads people hearing it for the first time to conclude all the primary attributes of open source software relate to money — price, cost-of-ownership, license fee and so on.
“Software freedom” puts the focus in the right place — on the essential liberties required to benefit from the software. One problem with this alternative term is we are becoming accustomed to hearing discussions of “freedom” be limited to activist or political contexts, and consequently regard the term “software freedom” with caution. But a focus on software freedom isn’t just for the revolutionaries.
All the values that make businesses pick open source software — both as alternatives to off-the-shelf software and now as elements of a platform strategy — are derived from software freedom. You can use the presence of software freedom as the ‘genetic marker’ for value to your business. Ensuring software freedom is delivered to the enterprise is a primary role of open source program offices (OSPOs).
The free software definition does indeed read like a revolutionary manifesto, partly because it is. The people behind it often eschew the pragmatism of the term ‘open source’ for historical reasons. But it’s worth looking behind their philosophy as it remains the heart of open source. I paraphrase the free software definition as guaranteeing the liberty to use, study, improve and share software for any purpose without further negotiation. Those four liberties are not important to you (only) as an ideology — they also create all the value of open source for business:
Being able to use the software for any purpose, without first having to seek special permission (for example by paying licensing fees or negotiating royalties). This allows developers to try everything and use what works. It also means suppliers need to demonstrate value beyond just access to the software.
The availability of skills and suppliers because they have had no barriers to studying the source code while also experimenting with it. The market in experienced staff, open source tools together with expert consultants is getting richer, and more vibrant by the day because of this freedom.
The assurance that vendors can’t withhold the software from you because anyone has the freedom to improve and re-use the source code. If a vendor decides to end support for open source software, another company can step in and carry on where they left off. If the capability you need isn’t there, you can get it elsewhere, have it written or write it yourself.
The freedom to pass the software on to anyone that needs it, even including your own enhancements – including your staff, suppliers, customers and (in the case of governments) citizens.
These freedoms also combine to deliver benefits associated with open source: the right to fork arises from all of them together; the ability to form a collaborative community arises from them; the ability to subset and super-set code as well as repurpose it in unrelated works arises from them; the ability to embed software in devices or scalably deploy in the cloud arises from them. All are easiest to appropriate when using software licensed under a community-reviewed, OSI-approved license.
When software users are deciding which suppliers to deal with, they need to know whether their software freedoms are being respected and cultivated, not out of a sense of philosophical purity but because their budgets as well as success depend on it. All the values that differentiate open source for the business user are the first derivative of software freedom. A primary role for an OSPO is thus to ensure that this value accrues to the company they serve and not (just) to a supplier.
Having meaningful markers governments and larger businesses can use in their procurement to favour open source – the software that lowers costs, avoids lock-in while also enabling unexpected future uses of data and software – is not an abstract matter of angels on pinheads or out-of-touch insiderism. It’s exactly the catalyst for innovation and value that the enterprises I’ve been visiting are asking for. Look for the genetic marker of business value –- open source that delivers software freedom to you and doesn’t have it exhausted elsewhere.
Is that single-company-controlled project actually open source in the sense of delivering software freedoms to you or just about delivering prospective customers to its host company? Here are 7 tests.
I frequently sum up the nature of open source licensing as granting permission in advance to developers or users to use, improve and share the software for any purpose. But the “Permission In Advance” lens has uses beyond just the rights to copyrights and patents granted in an OSI-approved license.
In my consulting engagements, I use a “thinking tool” to help clients work through their proposals for new open source community activities. Evaluating a project’s licensing, patent, and community management strategy — both to join it and to host it — should begin with the question: “How confident are community members that they have permission in advance to do whatever they need to succeed?” The more reasons for confidence, the larger the community.
Here are some of the questions community members will be asking, perhaps silently, about single-company open source projects and their own agency as a member of the community:
1. Am I granted rights permissions? An OSI-approved license guarantees this; does it apply to all the code? If there are portions of the code that remain proprietary or wrapped in additional terms that amount to a “constructive restriction“, a community is not truly free to form around the code. Developers wanting to enhance or even deploy that portion of the code do not have permission in advance, so probably won’t want to join even for the portions where they do.
2. Am I free to use my chosen business model? Copyleft licenses may limit certain business models, but issues arising from them aren’t usually directly to do with their copyleft terms. Communities use the GPL very effectively where the playing field is level — the Linux kernel and the GNOME community both come to mind. More problematic is the use of strong copyleft license like the AGPL in combination with a contributor agreement that means the “project owner” is not subject to the terms of the license for their own trading. In these circumstances, one community member is free to engage in proprietary strategies while everyone else can only offer support or add-on businesses because any platform value-add would have to be donated to the business of that one community member.
3. Am I unlikely to suffer patent demands? It can never be prevented, but patent grants like the ones in modern open source licenses — plus corporate pledges and nonaggression alliances like OIN or LOTN — can all help. Communities with no patent grants to protect people can feel like the Wild West, with the concern anyone could show up with weapons any time you’re successful. While patent demands can always come from afar, most patents related to a given codebase actually arise close to where it was written. Projects built around de jure standards that permit “FRAND” patent royalty demands are also likely to find this will happen.
4. Am I free to compete with other community members? Community rules that prohibit — explicitly or tacitly — competition with the sponsor reduce freedom. That includes any attempt at field-of-use restrictions — which are banned in OSI-approved licenses but still show up in governance rules — such as “not for mobile use” or “not for cloud deployment” or “can’t be used for military purposes.” Watch especially for contractual controls outside the scope of the actual code, such as to participate in an app store or to use components or apps that are essential for participation in the platform ecosystem.
5. Am I free to contribute my improvements? That’s a matter of the rate of acceptance of pull requests, of course. But it also applies when contributor assignments are a precondition to contribution. As well as creating inequality, they get in the way of participation, as does any mandatory agreement that will require legal review. I contribute back to reduce my maintenance and refactoring burden — it’s not (only) philanthropy. It’s reasonable for a community to expect me to demonstrate competence and ownership before giving me commit rights. It’s much less reasonable to insist I have to assign ownership of my work to a “project owner.” That chills participation, by forcing me to effectively pay to participate, both for legal advice and with code.
6. Am I treated as a development peer? When a company’s employees have privileged access to the code (or unearned commit rights) they rob potential collaborators of the confidence they have space to innovate. A sure sign is changes that are conducted in private, then “thrown over the wall” to the community. Why would you invest in significant new work, only to find the “project owner” rendering all your work moot with a bolt-from-the-blue code update, license change or business move that turns the rights ratchet? All these moves are scornful of contributor equality. When the only way to be sure you’ve permission to innovate is to enter into a bilateral agreement with one company, you’re being treated as a client or partner and not as a community peer.
7. Is the project inclusive of all people and skills? How do you license your documentation? Can I contribute to it? What about your user support community? Can I join in both to get and to give help? Do you have policies to discourage harassment of people who don’t seem to fit into your community norms? If people need to ask for any of those, that’s a lack of permission in advance as well.
Using the lens of “permission in advance” turns out to be an easy and useful tool for diagnosing your community governance, and for an OSPO to understand concerns with projects their developers would like to adopt beyond mere licensing issues. The seven points here aren’t the only concerns; which do you use for your own purposes? I would be interested to hear what tests others apply to community and project governance to determine whether there is truly freedom to collaborate.
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.
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.
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.
The cost of compliance may not just be a copyleft issue now we understand how to work with the GPL.
Even before Christoph Hellwig (backed by the Software Freedom Conservancy) started his suit to enforce his copyright claims against VMWare, there was a great deal of fear of the GPL in particular and copyleft licensing in general among corporate lawyers, and hence among their executive clients. Continue reading →