Holders of zero-tolerance positions on both sides of the divide need to realise that accommodating open sourceproductively inside standards bodies is both viable and happening now.
You’ll recall that open source and open standards are orthogonal concepts where even the words they share (like “open”) are defined differently. That doesn’t mean they are mutually exclusive, nor that they are bad together – they can be cultivated well in the same garden. There is great value from accommodating the two orthogonal concepts so that neither is invalidated by non-mandatory elements of the other. When they combine, great value is unleashed.
Why accommodating open source at a standards body is like growing blueberries.
Fresh-from-the-bush blueberries are one of the good things of life. When I set up my home office about a decade ago, I had to install an underground conduit to supply essential services — power, water, network — and dug a deep trench all along the path that leads there. When I refilled the trench I decided to plant a blueberry hedge so looked into how to grow good blueberries.
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?
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.
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.
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 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: