push.cx
Peter Bhat Harkins
Open Source Communities
Open source projects should be judged as much by their community as by their technological achievements. The code tells you what it’s good for, but the community tells you what its future is.
Communities need to be active to continue improving the project, deal with bugs and changes to their ecosystem. If no one is interested enough to talk about the project, none of that will happen. Newcomers need to meet experienced users to be sold on why to use the software, to get help as they learn their way around, to maybe be drawn into contributing to the project itself.
Some communities are maladjusted. They self-defeat (see the section on Bion’s support groups), they lack plans or goals, they abuse newbies to keep from growing or changing, they’re more interested in bringing something down or defending turf than building up their own project. Some successful projects start with a grudge to pick, but most that do so fail to develop their own identify, and you can hear that in a cacophony of blame and flames in their social spaces.
Productivity is the best way to tell if a community is well. Even if it doesn’t have regular releases, it needs explicit plans on a reasonable schedule to meet measurable goals. Good software is produced by careful and deliberate iteration.
All well and good, but what about the slugfest between Django and Rails? When do we get to the part where I reveal myself as an irrational, deceptive propagandist because I say anything nice about the project you don’t prefer? Better question: why is there so much vitrol between the two?
The two are far more alike than dissimilar: extracted from projects that were created in similar dynamic languages from late 2003 through 2004, their core functionality was routing URLs to templates rendered with data retrieved with an ORM.
The biggest early difference is in these two contemporaneous blog posts: Django releases, Rails turns 1. Django was wrongly seen as a Python copy of Rails on its release, though it’s just a case of convergent evolution: to solve similar problems they developed along the same lines.
If success is binary, both Rails and Django are successes. They’re strong, reliable tools for building websites quickly. They are their respective languages’ leading web frameworks. Speaking personally, I enjoy working daily in both.
If success is relative, Rails is far more successful than Django. By any measure I can take, the Rails community is at least ten times larger. For example, Indeed has more jobs and Google Trends shows more searches:
{style=”float: right”}
And yesterday I posted about the difference in books with a ridiculous title. The difference between eight books and dozens can’t be explained away by Python being simpler, the Django docs being better, or Rails being more of a moving target (all true); none of them would stop publishers from trying to profit from an audience. The jobs, the searches, the books: they’re imprecise metrics that all point the same direction.
Rewind. Rails and Django were roughly technologically equivalent. They were both once a little flaky and incomplete and Definitely Didn’t Scale. But with the aid of good marketing, Rails turned its earlier release into a lead in in the developer market and created a vibrant, growing community (even if that community acts out a self-parody roughly annually).
Rails has had more resources in the form of bloggers, coders, writers, trainers, and users, and it’s used them to push in far more directions than Django has. Rails has explored dead ends like components, built plugins and changed course to use better integration with its package manager, and soon the entire Merb sort-of-fork project is merging into Rails with the results of its successful experiments.
Django hasn’t moved nearly as fast, it hasn’t had the resources to make as many mistakes to learn from. The Django community is recovering from an 18 month gap between feature releases (0.96 on March 23, 2007 and 1.0 on September 3, 2008). 1.0 included a lot of great features and improvements, but it was a long, quiet year-and-half getting there while Rails was continuing to iterate.
It’s not a question comparing 1.0 minus .96 against 2.2 minus 1.2.3. It’s about activity and momentum, Django lost it while Rails has used the network effect to grow the most active web development community to build better software. Count the amount of blog posts{ruby+on+rails”&btng=”Search+Blogs””}, consultancies, newbies, rants, silliness, projects, and weaknesses addressed instead of books and see how Rails has succeeded. It is its own ecosystem instead of only being part of the web.
The difference in relative success is that Django’s still a useful tool for building good websites. Meanwhile, Rails has Changed The Web, influencing graphic design, pushing collaboration, proving the value of Javascript toolkits, driving the adoption of distributed version control. I’m not claiming Rails is singlehandedly responsible for these trends, I’m saying it’s been a dominant force in these advancements of the web.
The Django and Rails communities fight so much and so rudely because they’re too similar not to. Projects survive and thrive because they have attention from developers, and developers don’t often pick up two tools to do the same job (usually it’s one tool for every job). Community is the lifeblood of every open source project and the world of difference between Django and Rails is evidence.