Category Archives: blurb

Links (& blurbs about them)

The economics of contributing to open-source projects

This adaptation of Elinor Ostrom‘s work on the emergence of self-governance to open-source projects can explain my decision to stop reporting bugs to Ubuntu. If this formula holds true, then an open-source project will thrive:

benefit of contributing > benefit of not contributing + cost of contributing

In my experience with Ubuntu, this formula does not hold true. The benefit of contributing is often zero, as patches are not accepted and bugs are not fixed, or close to zero, as it can take years for a bug to be fixed. And the benefit of not contributing is similarly zero. And of course, the cost of contributing, in terms of time spent filing bugs, is greater than zero. The cost of contributing is often very high, requiring arguing for the validity of a bug, re-reporting the same bug multiple times, or attempting to recreate a bug from several releases prior.

PottyMouth moved to BitBucket

I’ve moved PottyMouth to BitBucket.org, where you can keep up to date with PottyMouth releases, subscribe to feeds, request features, and contribute patches. (It’s also on PyPi.)

In the last few months, I’ve fixed a bunch of poor design decisions on my part around encoding and repr() within PottyMouth, and added new syntax suggested by users. The latest version is 1.2.0.

A comment about commenting

#1, #2, #4, and #5 in these Five Rules for Writing Good Code are right on the money, but the edict against comments in #3 is shortsighted. A concise, five-line function following language and framework conventions can still benefit from a comment explaining why the function works a certain way, when it should be used, and what other related functions should be looked at. Sometimes your audience is unfamiliar with the language or the framework or the project and needs to make a change quick; inline comments will help them make it the right change.

Google Wave is not for you

Sounds like Google Wave might actually be pretty useful for:

  1. non-technical people in corporate environments who are
  2. sloppy with email and
  3. use email for lots of collaboration but
  4. aren’t familiar with all the tools and process that tech companies are accustomed to using (wikis, bug-trackers, IRC, version control, archived mailing lists, etc.).

In other words, non-technical, corporate environments.

MiniMash looking for beta testers

Some friends of mine are looking for early beta testers for MiniMash, their online video editing and publishing site. If any of my early-adopter readers out there are interested in video editing, or interested in trying out an application pushing the rich internet application envelope (video editing!), drop me an email, and I’ll get you into the early round of testing.