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:
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.
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).
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.
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.
It’s not new, even if each time it comes up people think it’s a new outrage.
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: