When it comes to Open Source software, forking is a feature! Anil Dash said it well:
There are several related technical concepts that can answer to the name “fork”, but the one I reference here is the dramatic moment when a software project undergoes a schism on ideological or technical grounds. Instead of merely taking their ball and going home, those who forked were taking a copy of your ball and going to a new playground. And while splitting a community could obviously cause an open source community’s momentum to grind to a halt, even the mere threat of a fork could cause significant problems, by revealing conflicting goals or desires or motivations within a previously-united community….
…Part of the predicate for forks being so disruptive was the idea that there is One True Version — a creation, like a piece of software, a written work, or anything else, that can only be accurately represented by a single ideal expression.
He then describes how Linus Torvalds and Git (and Github in particular) helped accelerate change from those precepts:
Often, the very first thing a coder does when she sees an interesting new project on GitHub is to make a fork of it and start tinkering. That’s only one of the reasons that GitHub so important, though; The GitHub principle of “see it, make your own version, and then get to work” has started to filter into other disciplines….
“Make it your own” certainly is one liberating aspect of Open Source, and it’s great how the tools we have today provide such affordances to make it easy peasy.
On the other hand, Open Source software is nothing without its community. “Make it your own” may be nice for building your own widget, but when it comes to complex systems like Drupal or Ubuntu, collaboration is the dominant ethic that brings the power to the software.
And yet, forking still must be a feature, at least in part, of any open source project. Without that liberating power, the project risks languishing in groupthink, the inertia of limited resources, even the sclerosis of closed minds or cocky attitudes.
Contrib all on one plate
In the open source Drupal community, forking is not only not embraced, it’s generally frowned upon, even actively discouraged. For example, to become a module or theme contributor in the Drupal community, you first must prove to community leaders that not only do you have the knowledge and ability to produce a solid, secure project that follows some basic coding standards, but you also must demonstrate that your first project, the one upon which you’re being evaluated, does not overlap with any existing project. Even overlap of general use cases could lead to rejection of an otherwise strong project, and thus strong developer/themer. If it’s a forked module, fuggedabowdit!
With thousands upon thousands of modules in contrib, a degree of this kind of conservatism, if not curation, can make sense. It’s already difficult enough to find good modules to work with. Imagine if the floodgates were thrown open to anyone who had an itch to scratch. Imagine how hard it would be to find the right contrib module when you have dozens that do essentially the same thing.
So the gates to new developers remain fairly guarded. New Drupal project applications can wait weeks and months to find approval. Community volunteers are simply overwhelmed by the backlog.
One might think the Drupal project risks doom with such difficult barriers to entry. Fortunately there’s a release valve of sorts in the fact that, for the most part, once a developer is approved with Project creation permissions, she can pretty much create whatever projects she wants. There’s still a dominant culture of “collaborate, don’t duplicate” when it comes to these kinds of endeavors, but the determined developer can still press forward, and let the cards fall where they may.
Dries has stated several times that, in the case of seemingly duplicate projects, the marketplace of ideas should decide which project is better. Certainly we’ve had instances of purportedly overlapping features of two or more projects where the community benefitted in the end. Remember Flexinode? It was the method to define custom node types … until CCK came along and quickly replaced it. Now most of that custom-content-types functionality is incorporated into Drupal core, but I seriously doubt that would be the case if Flexinode had been given squatting rights and CCK were never allowed its place in the sun. Even with collaboration between projects, CCK ended up lighting up a new way to take things, and the community made its choice.
Another example: Today we have Panels, Display Suite, and Context modules, which all have large degrees of overlapping functionality, but I don’t know if anyone could successfully argue that Drupal is diminished by such overlap.
Culturally we in the Drupal community have a tension between diametrically opposed open source values: the virtue of collaboration vs. the feature of forking. And it’s hard to shake a stick at either. Collaboration is at the heart of building a commons. Individuals don’t raise barns. On the other hand, there are times when forking can benefit a community. Witness Joomla’s success forking out of Mambo — a development borne more out of community politics than any technical issues.
Core by the spoonful
A year ago, there was a lot of anguish over Drupal 8 and where it was going (or not going). Many of us remember how the tension surrounding the state of Drupal core was palpable. It was like everyone looked at Drupal 7 with an eye towards making the Drupal 8 plans happen, and collectively gasped, “This is going to take a crapload of work!” With Drupal core growing in size and complexity like it has, is it any wonder?
Was it time to fork Drupal? That question rang like a bell. It woke people up, and scared the crap out of some. Fork Drupal?! What?!
In his forking post, Anil writes:
Moving forward, there are a lot more lessons we can learn if we build our social tools with the assumption that no one version of any document, app, or narrative needs to be the definitive one. We might even make our software, and our communities, more inclusive if we embrace the forking ourselves.
And yet contemplating forking is no fun. It’s like a divorce. Maybe it’s a good idea. Maybe not.
As we approach DrupalCon Munich, Drupal 8 is moving forward in collaborative mode: Drupal core developers, themers and documentation writers are working the various Drupal initiatives, hashing out how to improve Drupal without forking it into a separate project. Working to make Drupal 8 more awesome. And in the year since that devil’s advocate question about whether it was time to fork Drupal, the Drupal project has kicked into gear, bringing to the next major release of Drupal some truly innovative changes and features that will make it perhaps the most eagerly anticipated release of any CMS. (Am I exaggerating? I’m not so sure.)
Forking may be a feature of open source. But in Drupal, we prefer spoons.