Brian Kardell (вкαя∂εℓℓ) tweeted:
Forking another spec: generally less than ideal.
Spooning w another spec: weird.
Knifing another spec: generally indicative of larger issues
— вкαя∂εℓℓ (@briankardell) April 28, 2014
@briankardell Sporking another spec: "welcome to the w3c, here's your badge." ;-> @simonstl
— Kip Hampton (@kiphampton) April 28, 2014
Free and Open Source software licenses make forking legal. Git makes forking easy. GitHub makes it easy to fork sociably. Can we just make this normal?
The most visible recent fork – LibreSSL‘s blunt forking of OpenSSL – was widely reported as conflict. It’s certainly not a polite break, but the OpenSSL’s Apache-style license means it’s legal.
Meanwhile, in a reminder that specifications can fork too, Ian Hickson put his objections to the W3C forking a WHATWG spec on www-archive to make sure his complaints of plagiarism would be part of the permanent record. WHATWG specs are licensed CC0, so once again, it’s legal.
It seems to be a common pattern to want to grant rights, but only want other people to use those rights if they acknowledge our control. (I sometimes have similar tendencies, granted.) We hope that people will contribute to our works while recognizing our power and our ownership over those works. Even the fact that we have to choose licenses at the start of a project gives us a sense of ownership and control, often hiding the (excellent) lack of control that comes once those licenses are applied.
Once we’ve given the rights away through open licensing, we hope our projects will stay coherent because of respect for its creators, because of etiquette, or because the ‘main’ flow of a project will likely see more regular updates. I suspect the last of those, the regular stream of updates, is the only one that works. Meanwhile, expectations of respect and etiquette create the friction that makes forking such a fiery conversation.
Can we let go? Can we acknowledge how much we’ve already let go by choosing a license?
Perhaps I’m utopian, but I’ve always been puzzled by the expectation that Free and Open Source projects must have gatekeepers, owners, restricted lists of committers. I know some of that comes from the technical limitations of early source control systems, but its social hangover remains even in an age of distributed revision control and much easier diffs. Digital copying and remix culture are great, but remixing code sounds… dangerous. Likely to confuse consumers. A threat to the processes that create code.
Think about it a different way. If we considered forking a positive good, we might be able to:
- Have contests for the best fork of a project, encouraging programmers to explore the entire breadth of code rather than focusing on narrow bits of code.
- Encourage software developers to maintain a version of the specifications as they’ve implemented them, so that we can evaluate what’s changed in implementation.
- Push “rough consensus and running code” to support the full variation of “rough” during (and after) the specification process.
- Develop components that are available in pre-packaged variations, as people can easily share their different approaches and preferences.
- Evolve practices for looking across a number of forks and figuring out which directions among them seem best for pursuing a remaining “primary” thread of a project.
The Extensible Web Manifesto dreams of a “virtuous cycle” of rapid polyfills and testing across environments. I would love to see a rich environment full of forks, pulls, and exploration that supports such an ecosystem. The Web, with its flexibility and page-level granularity for experimentation, may be the best place to start building such a culture.
In the meantime, though, please be kind to the people who fork your work, and to the people whose work you fork.