The open source way == “how to be forkable and not get forked”

August 31, 2010 – 2:20 pm

On the way from Boston to Raleigh this weekend, I stopped by Karl Fogel’s place for lunch (more accurately, a Mexican restaurant down the street from his place). We talked about life and a million other things, 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?

Know someone who'd appreciate this post?
  • Print
  • Facebook
  • Twitter
  • Google Bookmarks
  • email
  • Identi.ca
  1. 4 Responses to “The open source way == “how to be forkable and not get forked””

  2. OK, I get where this is coming from, and I’ll tell you the challenge. It’s related to why I balked at the idea when I first heard it.

    “To fork something” is an idiomatic expression that requires a lot of explanation.

    Forking is linked with software — that’s the origin of the term, it’s most common usage scenario as a term, and ultimately how you have to explain the term to anyone who isn’t already immersed in the software world.

    Thus, as a term it is already mapped to software. For it to work for the book ‘The Open Source Way’, we need to rephrase (unmap) it so that it meets certain criteria, roughly in this order (as a sort of timeline):

    1. Be accessible to the greatest audience at first glance; target more than 50% of the population; first passage can be culturally specific if it reaches a larger population.

    2. But non-idiomatic so that it can be translated; it should be more of an example than an idiom that requires culture. Music or other art forms. Cooking?

    3. Become generic enough that a simple phrase catches the essence, is easily translatable, and when requiring explanation can be done by a layperson in just a few sentences.

    So I’m challenging you and Karl to think about that some more, since you are suggesting these ideas as the essence of what the open source way (and thus the associated handbook) are most about.

    Here is why cooking might work as an example that is translatable:

    * A recipe might have ingredients you cannot get or will not eat (for health, religious, philosophical, etc. reasons.) Thus it needs modification.

    * A recipe might not work in your environment (too hot, cold, dry, elevation, city, country, etc.) Thus it needs modification.

    * Some recipes seem the same worldwide (McDonald’s french fries), with the recipe a secret.

    * Recipes require equally known techniques, e.g. French cooking. If you use a cookbook (Julia Child’s, for example) and adhere to traditional techniques, you are essentially not forking. The original is good enough, has made itself accessible to you, so you can participate without forking. However, you might fork as an individual, a group, or an entire country (think: pizza, hot dogs, hamburgers, ice cream cones – all forked in the USA). For whatever reason.

    So what would the phrase be for cooking as the example? Yes, “to fork” would be confusing for many. “Change a little or change a lot”?

    “The essence of the open source way is:

    1. How to make it so that people never want to deviate from your recipes and school of cooking when they are planning dinner;

    2. How to make people successful when they do decide to deviate from your recipes, through 100% open and unfettered access and rights to everything they need.”

    By Karsten 'quaid' Wade on Aug 31, 2010

  3. Another analog that I think people always keep returning to is the scientific one. Without the prior work of X the current researcher cannot discover Y, whether that is an understanding of optics enabling the discovery of Jupiter’s moons, or an understanding of genomic sequencing enabling the identification of genes linked to an obscure disease.

    When scientific knowledge is siloed in a private place, it becomes unusable for future researchers. Who knows how much cryptographic research has been conducted behind closed doors, and is unavailable to the public? The paranoid have their ideas on that one!

    I’m not convinced that the ‘fork’ is, or should be, a central idea of free software development. I set my code free not because I expect people to wrench it from my grasp and repurpose it, but because I would like them to assist in making it better. Some of this thinking informs licensing decisions too. If I want to make my code as easy as possible to fork, then I am less likely to use the AGPL, I think.

    To avoid being forked? Well, if I stop having the time or inclination to work on my free software projects I hope someone else will come along and give them love! Will that be a fork? I don’t think it fits the definition if I’ve handed over the reins of the project to a new team. The ability to pass the code over to another person is certainly something I would consider a critical success factor for a free software project.

    A few years back I was examining formulae for valuing companies and one of the common multiplicative ‘fudge factors’ was whether the founders had successfully exited the company. This is considered to have a positive effect on the value of the company, and I think that the same logic also applies to an open source project: can the project survive the departure of it’s original inventors?

    We see this kind of success in projects like the Xorg[1], Apache, Debian, GCC, Inkscape and PostgreSQL and while forks have occurred in the history of all of these projects it isn’t what defines them, and what is probably more interesting is in how differently the forks have interacted with the original projects in each case.

    Cheers,
    Andrew McMillan.

    [1] Well, except for Keith Packard perhaps!

    By Andrew McMillan on Sep 1, 2010

  4. Regarding the desirability of forking in terms of putting it forward as an objective.

    When you make a contract (business, marriage, tenancy-in-common, etc.), it includes the terms for dissolution of the relationship. For divorce, that’s usually by the state you live in – in California, you know it’s going to be, “Divide it all in half: alone, via arbitration, or in court.”

    It seems counter-intuitive to think about dissolution when the whole goal is to get together! Yet it is an important sanity thing. We KNOW from the history of humanity that not all partnerships and relationships stay together. If we do all our planning as if nothing ever breaks up, we are going to be in serious trouble before too long.

    The alternative of always being aware and laying preparations for break up IS a bit intense — thinking of forking from the beginning is just such an example.

    But it’s also a kindness. If I love and care for my fellow humans, I want to make sure that they can leave an uncomfortable situation without being taken for their shirt and savings. If my project is no longer comfortable to them, they should be able to fork and walk away.

    Conversely, people are more willing to join something if they know they can walk away with minimal loss later. A FOSS project has minimal money costs, but sometimes significant time investment. The code is part of that “payment” and you receive payment before you even start, and no matter what thereafter. That is freeing.

    By Karsten 'quaid' Wade on Sep 13, 2010

  5. BTW, since I’m referencing this post now :) I created a short URL (in a non-FOSS system that lets me track the usage):

    http://bit.ly/ForkingTOSW

    By Karsten 'quaid' Wade on Sep 13, 2010

What do you think?