Summary
We recently moved "Python 3 Patterns & Idioms" from Launchpad to BitBucket. Here's why.

First, I want to make it clear that I think Launchpad is great, and especially the code base that it was created for, Ubuntu Linux. The Ubuntu crew gets that Linux needs to be friendly from top to bottom, and they are doing a terrific job.

Our experience with Launchpad was good. They do a lot of things right, and it's hard to say what, if anything, they don't do right. For some reason it was just a little harder than it could be. Also, the web site had a slow response time.

The key shift happened when I decided I wanted to lower the barrier to entry for participating in the project, and a wiki seemed like the right way to do this. If someone wants to contribute but they don't want to learn about Spinx and distributed version control and the mechanisms of the hosting site, they can just put text into a wiki and we will take it and do whatever is necessary.

We looked at third-party wikis (in particular, wikidot seemed very nice), but then someone suggested BitBucket, which has a wiki for each account.

After some brief experimentation, I decided to move the project to BitBucket and I've been much happier with it ever since. But the two sites provide more or less the same services, so it's hard to pin down exactly why one seems to provide a more pleasant experience than the other.

Clearly, the speed of the BitBucket site is a significant issue. It just feels more responsive. But more than that, the design appears cleaner, and the use of it -- including mercurial -- just seems ... smoother, somehow. For example, whenever you upload a package to BitBucket, the latest version is automatically ready for download in compressed format (it does the compression for you) by anyone. This changed the way we organized the project, so that all the elements of interest to the end user show up at the top-level directory, then there's a src directory where all the build stuff goes. When you download the compressed file, you get everything, and you can just look at the book or you can look at the sources and our build system. The result is that it's much easier to think about and -- this is important, I think -- every time I do a push to BitBucket, it becomes the latest everything, so there's no "now we're going to do something special to make a distribution." It's always a distribution. Of course, you don't have to do it this way but I found that the "implicit guidance" given by BitBucket in this direction was very helpful.

I had an observation about Launchpad's "Blueprints" feature: It appears that Launchpad was created with Ubuntu development in mind (I'm sure it was) and so tended to funnel us in the direction of the way Ubuntu development works. Thus, they have "Blueprints," a specific way to add features, while BitBucket has a wiki, which allows you to do anything -- and in our case, was a better solution to the problem.

In general, I think the Ubuntu orientation of Launchpad turned out to feel a bit constraining, whereas BitBucket seems to have thought more about making a platform that is flexible for a larger number of projects.

I also found Mercurial to be more straightforward than Bazaar; again, hard to specify exactly why but it's as if Bazaar overthinks the problem and that adds cognitive load to the learning process. (This was definitely not a double-blind experiment; I had already learned a little about distributed version control from Bazaar, but Mercurial still seems clearer).

Talk Back!

Have an opinion? Readers have already posted 2 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Bruce Eckel adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

Bruce Eckel (www.BruceEckel.com) provides development assistance in Python with user interfaces in Flex. He is the author of Thinking in Java (Prentice-Hall, 1998, 2nd Edition, 2000, 3rd Edition, 2003, 4th Edition, 2005), the Hands-On Java Seminar CD ROM (available on the Web site), Thinking in C++ (PH 1995; 2nd edition 2000, Volume 2 with Chuck Allison, 2003), C++ Inside & Out (Osborne/McGraw-Hill 1993), among others. He's given hundreds of presentations throughout the world, published over 150 articles in numerous magazines, was a founding member of the ANSI/ISO C++ committee and speaks regularly at conferences.