OpenOffice.org Losing Viability
Code: , , , ,
Comments Off on OpenOffice.org Losing Viability

OpenOffice.org developer Michael Meeks analyzed 2008 commit data to show that the project is losing steam: decreasing numbers of commits, developers, and companies. He rhetorically asks about how the project is losing technical quality:

Continue this post

Open Source Communities
Code: , , ,
Comments Off on 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:


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, 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.

Django vs Rails: The Dead-Tree Edition
Code: , ,
Comments Off on Django vs Rails: The Dead-Tree Edition

Continue this post

Washington Post Update
Code: , , ,
Comments Off on Washington Post Update

It’s been a long time since I’ve written
about what I’ve been up to at the Washington Post, so let me run down the apps
I’ve worked on since September 2007 in roughly linear order. Lots of these apps link different places,
so if you don’t see projects.washingtonpost.com at the start of the
URL, you’ve probably wandered off something I directly worked on.

Continue this post

Django Template Tag for Dictionary Access
Code: , , ,
Comments Off on Django Template Tag for Dictionary Access

About a million times when writing Django pages I’ve been iterating through a list of objects and wanted to look up a value in a dictionary keyed by object.id. But you can’t, the built-in tags don’t allow it.

Continue this post

Django And The Disappearing Template Tags
Code:
Comments Off on Django And The Disappearing Template Tags

If you are defining custom template tags, don’t put them in a file named log.py. You’ll be able to {% load log %} fine in your template, but you won’t be able to use your tags. No, this isn’t documented anywhere.

Continue this post

Django Gets Transactions
Code: , ,
Comments Off on Django Gets Transactions

Jacob Kaplan-Moss added transaction support to the magic-removal branch of Django just a few minutes ago. It’s one of the many changes to come out of the sprint. Usage will look something like this (based on Jacob’s docs and chatting with him in #django-sprint):

Continue this post

Versioning: The Next Big Thing
Code: , , ,
Comments Off on Versioning: The Next Big Thing

In the web development world, anyways. So, in the grand scheme of things, maybe not a huge deal to anyone else. Versioning is going to be one of the biggest problems and opportunities there is in web development, and it’s going to take us at least five years to get it right.

Continue this post