Skip to main content

How To Adopt/Kidnap a Project

Distributed version control is a good thing. I've started wondering, abstractly, removing the middle word of that phrase. In other words, how are we being affected by "distributed control" and how will the landscape of free software politics change as it becomes more predominate and we all become more comfortable with it?

Even centralized version control began the distribution of control. At least, it made it easier for more than one person to control the changes of a codebase. In old days of e-mailing patches around, it was pretty much a requirement that a single person be responsible for the merging of patches into any single codebase (or any section of that codebase). Source control allowed multiple developers to commit changes and began to put less burden and less power in any one person's hands.

Anything that makes the submission of new code easier is going to thin that power even more. When anyone can come along and submit changes to change functionality or add something new, it takes a little bit of control away from the owners of that project. At some point, you start to feel that the community runs your project as much or more than you do. This has its good and its bad sides, but it is a shift we see more and more.

A few years ago there was a rift in the development team of the XFree86 project and from this we got our current fork, X.org. The story is well known and it brings to light an important political power of open source: fork and run. Even if you own a project, you'll begin to loose power both to make users and other developers happy, and to keep control at all. A strong enough disagreement could mean everyone else just leaving you behind and taking the project with them, under a slightly different name and a forked codebase. This can be scary and obviously could be harmful, but like any democracy we trade that for the benefits willingly.

Today, forking is easier than ever. Project hosts like github and launchpad promote forks as the primary means of submitting patches. No longer do you submit your changes for scrutiny and wait for acceptance or denial. These are the days of "I liked your project, and I have my own version of it. Take it or leave it." Other developers are as welcome to use your version as the original. This begs the question, when does the original project stop mattering and when do we come to realize that all forks are created equal?

The big question here is when the use of a fork with a few patches, either yet to be pulled into the original or rejected for differences in opinion, becomes as reputable. This can only happen if we can get past looking at forks as either replacing or diverging and understand them as ongoing versions with differences for good reasons. Should I find that I want to make some modification to a library I'm using that the current maintainer doesn't want to accept, there should be no social issue with those two branches, the original and my own, existing and being used in parallel. The choice for others on which to use can be considered of as much weight as its configuration options.

When we reduce to zero the social cost of taking a project for you own to make the changes that fit your needs, we make many things easier. Abandoned projects become far easier to adopt, without feeling the need to make all due process to contact and get the fair wishes of the creator. Difficult to work with maintainers no longer hold control over users and developers who disagree, because even more democratic than a democracy we can allow everyone to truly get what they want.

Comments

ulrik said…
Just another nail in the coffin: Ubuntu's Personal Package Archives takes this further, since it allows anyone to publish versions (with no changes, small changes, forks) as binary packages, that most common users can install without having to learn to compile etc.
The fear of forking causes projects to work against it if they are to retain their momentum. In a way forks make open source development what it is.

A fork may be a good way to show that this is the way we (or some individual) want(s) to go. If the fork's goals differ significantly from the goals of the origin, perhaps it is better off as a separate project on its own (see BSD projects for instance).

Sometimes you might want to fork for specific need or just out of curiosity (ie. what if I change this and that...). I do welcome the easy forking allowed by DVCS's. As you mentioned patches can be somewhat tedious to handle and their vibility is quite low (depends on project infrastructure of course) so on that background this is progress.

Just as a final note remember that a project is a lot more than just its source code. It really depends on the goals of the fork but if you really want to "kidnap" a project, you need something else than just the source code too.
Anonymous said…
A sustainable fork is quite a lot more than just a source code delta. It must be an ongoing commitment by the new author/team/organization to a new direction and continued activity and support.

Popular posts from this blog

CARDIAC: The Cardboard Computer

I am just so excited about this. CARDIAC. The Cardboard Computer. How cool is that? This piece of history is amazing and better than that: it is extremely accessible. This fantastic design was built in 1969 by David Hagelbarger at Bell Labs to explain what computers were to those who would otherwise have no exposure to them. Miraculously, the CARDIAC (CARDboard Interactive Aid to Computation) was able to actually function as a slow and rudimentary computer.  One of the most fascinating aspects of this gem is that at the time of its publication the scope it was able to demonstrate was actually useful in explaining what a computer was. Could you imagine trying to explain computers today with anything close to the CARDIAC? It had 100 memory locations and only ten instructions. The memory held signed 3-digit numbers (-999 through 999) and instructions could be encoded such that the first digit was the instruction and the second two digits were the address of memory to operate on

Statement Functions

At a small suggestion in #python, I wrote up a simple module that allows the use of many python statements in places requiring statements. This post serves as the announcement and documentation. You can find the release here . The pattern is the statement's keyword appended with a single underscore, so the first, of course, is print_. The example writes 'some+text' to an IOString for a URL query string. This mostly follows what it seems the print function will be in py3k. print_("some", "text", outfile=query_iostring, sep="+", end="") An obvious second choice was to wrap if statements. They take a condition value, and expect a truth value or callback an an optional else value or callback. Values and callbacks are named if_true, cb_true, if_false, and cb_false. if_(raw_input("Continue?")=="Y", cb_true=play_game, cb_false=quit) Of course, often your else might be an error case, so raising an exception could be useful

How To Teach Software Development

How To Teach Software Development Introduction Developers Quality Control Motivation Execution Businesses Students Schools Education is broken. Education about software development is even more broken. It is a sad observation of the industry from my eyes. I come to see good developers from what should be great educations as survivors, more than anything. Do they get a headstart from their education or do they overcome it? This is the first part in a series on software education. I want to open a discussion here. Please comment if you have thoughts. Blog about it, yourself. Write about how you disagree with me. Write more if you don't. We have a troubled industry. We care enough to do something about it. We hark on the bad developers the way people used to point at freak shows, but we only hurt ourselves but not improving the situation. We have to deal with their bad code. We are the twenty percent and we can't talk to the eighty percent, by definition, so we need to impro