I was reminded today after speaking to Ted Leung @twleung that he uses the phrase “commons based peer production” rather than “open source”, because:
The problem with the term open source is that everyone means something different when they use it. Some people just mean licensing. Some people think of a particular community’s set of practices. Others think that it means some kind of fuzzy democracy and mob rule.
Which of course is exactly what I was trying to capture in my post from last year on Blockchain & Open Source Definitions.
Researching that phrase further brought me to a bunch more posts from Ted that make for good reading to see what parts of them apply to today.
This early post was where we were all still trying to explain open source as it came out of the shadows a bit, in the shallows of Web 2.0 and open APIs: Explaining Commons Based Peer Production, er, Open Source (2005).
This is not communism, it’s about preserving the freedom/openness of the web at a basic level, since the software in the commons will be available to anyone, and not controlled by a corporation with a profit motive. It’s about fostering innovation by providing a base that can easily adapted or used as a ground for experimentation. We foster innovation by lowering the threshold so that passionate, talented people can get involved right where they can help the most.
The topic of Design and Commons Based Peer Production (2009) is still being wrestled with today:
Can we actually do design using the commonly accepted tools of e-mail, version control, wiki’s and bug trackers? The design process relies very heavily on visual communications. The code (including design and architecture of code) process is predominantly a text based process. It is very difficult to do design efficiently in a distributed setting using the existing stable of tools. This is going to be a challenge not just for designers but for many other problem domains that could benefit from commons-based peer production.
In various open source projects, we talk about “Core Devs”, but we do not talk about “Core Designers”. And maybe we should be. Or maybe, in 2018 where we may be able to have a single “backend” of a blockchain, and multiple front-ends, then benevolent design dictators may be able to more appropriately fund themselves.
Further reading leads me to Yochai Benkler’s Coase’s Penguin, or Linux and the Nature of the Firm (2002), which is where Ted got the phrase “commons based peer production”.
In this paper I explain that while free software is highly visible, it is in fact only one example of a much broader social-economic phenomenon. I suggest that we are seeing is the broad and deep emergence of a new, third mode of production in the digitally networked environment. I call this mode “commons-based peer-production,” to distinguish it from the property- and contract-based models of firms and markets. Its central characteristic is that groups of individuals successfully collaborate on large-scale projects following a diverse cluster of motivational drives and social signals, rather than either market prices or managerial commands.
Full paper lives on the Yale Law Journal (direct link to PDF). Coase is of course something that is talked about a lot these days with DAOs and fully distributed teams.
Top comments (3)
"Open source" has a formal definition that we need to be informing people of, and abiding by ourselves.
In all honesty, "commons based peer production" is just as likely to get muddled as a term as anything, maybe more so since it has no formal organization helping to define, foster, protect, and educate about it (yet?)
Hi Jason. Commons Based Peer Production refers to the way of building software, not the license.
This isn’t about a standard — it’s about learning that the practice of building software collaboratively is mostly people :)
There are a lot of further links in what I shared, I found them an interesting historical read on the research in this area.
The way I see it, Open Source is about far more than license as well; the license is related to the philosophy! We've overly distilled the concept to "just being licenses", but Eric S. Raymond's watershed book "The Cathedral and the Bazaar", which was the literal genesis of Open Source, spent the large majority of the time talking about people and processes for building software.
When I have time, I'll look at the links, but meanwhile I stand by what I said: instead of coming up with Yet One More Thing™, maybe we need to get back to what Open Source meant to begin with.