A draft scorecard for determining if a software project is open as bait for a business pivot or genuinely keeping your freedoms protected.
The seven signs a project is following the rights-ratchet route to riches and the framework for going beyond licensing can be augmented by some straightforward indicators of an issue. None of these alone is necessarily a cause for concern, but the more clicks, the more risks. Here’s a rough-and-ready first draft of a scorecard to check whether your software supplier considers you a community peer and will respect and protect your essential freedoms, or visualises you more like one of those pods in The Matrix. Just count the clicks; the more clicks, the higher the risk this is a rights-ratchet that will end up closed.
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.
The lesson Elastic’s restrictive relicensing teaches is that those using open source to ratchet a software startup will forsake software freedom eventually if they’re aggregating rights. That’s no reason to believe open source needs updating.
Many of the responses to the decision of Elastic to drop open source licensing for their products and instead use restrictive commercial licensing have involved asking whether they were justified to do so based on market conditions (especially the provision of a service by Amazon Web Services) or diving into the minutiae of what they actually did. Some see it as support for the hypothesis that the very definition of “open source” is out of date. But to do so is to swallow the bait of distracting explanation and overlook the actual value of open source and why Elastic — and the cloud databases before them — no longer care about it.
If you’re managing community or developer relationships for your employer, a crucial principle is to “go with the grain” of the community — promote and embrace the freedoms it needs and the expectations it cherishes — rather than take actions that result in easily-anticipated opposition.
Facebook’s BSD+Patent license combo fails not because of the license itself but because it ignores the deeper nature of open source.
In July 2017, the Apache Software Foundation effectively banned the license combination Facebook has been applying to all the projects it has been releasing as open source. They are using the 3-clause BSD license (BSD-3), a widely-used OSI-approved non-reciprocal license, combined with a broad, non-reciprocal patent grant but with equally broad termination rules to frustrate aggressors. Continue reading →
How can you grow an open source community? Two blog posts from The Document Foundation (TDF) illustrate a proven double-ended strategy to sustain an existing community. Spanish
Since it was established in 2010, the LibreOffice project has steadily grown under the guidance of The Document Foundation (TDF) where I’ve been a volunteer — most lately as a member of its Board. Starting from a complex political situation with a legacy codebase suffering extensive technical debt, TDF has been able to cultivate both individual contributors and company-sponsored contributors and move beyond the issues to stability and effectiveness. Continue reading →
You feel slighted by a comment on a mailing list, or a forum post has failed to be moderated live. How should you react?
A recent exchange on a user forum caught my eye, one that’s typical of many user interactions with open source communities. Someone with a technical question had apparently had the answer they needed and to help others in the same situation had posted a summary of the resolution, complete with sample code. When they came back later, the summary was gone. Continue reading →
At FOSDEM 2017, Simon gave a well-attended talk explaining many of the things that could go wrong for a company trying to engage a large open source project over legal or governance issues. Based loosely on a mailing list thread at the Apache Software Foundation, the talk highlighted seven things to avoid and gave ideas on how to do so.
Including design and UX in a true community project is a challenging matter of balance because of the motivational model behind open source projects.
According to The Cathedral and the Bazaar, the key motivation for participants in open source projects is “scratching their own itch.” One consequence of this is co-ordination of contributions to support user-centric design is inherently an optional extra in a true open source project with multiple independent participants. We all wish there was a way to get genuine user experience quality as a key dynamic of open source projects. But there are two big reasons that is challenging. Continue reading →