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.
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:
Is your Open Source Program Office just part of your corporate defences, or is it the community’s advocate inside your company as well?
Supplies?
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.
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.
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.
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”.
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:
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.
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).