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

The Insidiousness of The Slow Solution

In software development, slow solutions can be worse than no progress at all. I'll even say its usually worse and if you find yourself making slow progress on a problem, consider stopping while you're a head.

Its easy to see why fast progress is better: either you solve the problem or you prove a proposed solution wrong and find a better one. Even a total standstill in pushing forward on a task or a bug or a request can force you to seek out new information or a second opinion.

Slow solutions, on the other hand, is kind of sneaky. Its insidious. Slow solution is related the Sunk Cost Fallacy, but maybe worse. Slow solutions have you constantly dripping more of your time, energy, and hope into a path that's still unproven, constantly digging a hole. Slow solutions are deceptive, because they still do offer real progress. It is hard to justify abandoning it or trying another route, because it is "working", technically.

We tend to romanticize the late night hacking…

Finding "One Game A Month"

I was really excited about the One Game A Month challenge as soon as I heard about it.
For about two years I've struggled in fits and starts to make my way into game development. This hasn't been productive in any of the ways I hoped when I started. Its really difficult to be fairly experienced as a developer, which I believe I am in my day job as a web developer, while struggling really hard at an area in which your experience just doesn't exist.
Its like being a pilot who doesn't know how to drive.

But this challenge provided a new breath to this little hobby of mine. It gave me a scaffolding to experiment, to learn, to reflect on finished projects. I had spent far too much time on game projects that stretched on far past their exciting phases, bogged down by bad decisions and regret.
And it has worked.
I have a lot to learn. I have a lot of experience to gain through trial and error and mistake and discovery. I have a lot of fun to be had making more small games t…

On Pruning Your Passions

We live in a hobby-rich world. There is no shortage of pastimes to grow a passion for. There is a shortage of one thing: time to indulge those passions. If you're someone who pours your heart into that one thing that makes your life worthwhile, that's a great deal. But, what if you've got no shortage of interests that draw your attention and you realize you will never have the time for all of them?

If I look at all the things I'd love to do with my life as a rose bush I'm tending, I realize that careful pruning is essential for the best outcome. This is a hard lesson to learn, because it can mean cutting beautiful flowers and watching the petals fall to the ground to wither. It has to be done.

I have a full time job that takes a lot of my mental energy. I have a wife and a son and family time is very important in my house. I try to read more, and I want to keep up with new developments in my career, and I'm trying to make time for simple, intentional relaxing t…