On the way from Boston to Raleigh this weekend, but one of our conversation topics was The Open Source Way.

The thesis we came up with over lunch is that the open source way, at its core, is two things that are really the same thing: (1) How to avoid being forked, and (2) how to fork a project properly.

The primary thing that makes a project 'open' is "is it forkable?" This goes into all the things the current book is already enumerating: is it licensed in a way that makes it permissible to fork? is the stuff that needs forking available so people can find it and fork it? and so on. The existing content in the book is, in a sense, "things you should do in order to ratchet up the number of points of your doing-it-right/no-fork! meter." That last point was inspired by Spot's failmeter, and the question of what the equivalent list is for non-software projects is still an open question.

For instance, public infrastructure... what does it mean to "fork," say, a library? In the US, public libraries are commonplace and usually of high-enough quality that citizens are content enough not to fork it. In other countries, this system isn't adequate, so private citizens have grouped together to make their own libraries and to share notes with each other on how best to "compile your own library," so to speak. I think about Stian Haklev's study of government-supported and independent reading gardens (libraries) in Indonesia as an interesting look at a system that has a lot of parallels to free software.

Or to take another example: homeschooling as a fork of the public education system. Karl pointed out that public schools take a variety of stances to this sort of "forking," and that one of the friendliest things a public school could do is to make their offerings modular so that homeschooled students could, for instance, play on the sports team and take a pottery class but study math and Russian literature and history and so forth on their own. Modularity (and reusability) is also something we value in code in the FOSS world.

What other parallels can you think of? Does this framing of "how can a project in $discipline become more forkable" help think about doing things the open source way beyond the software realm?