The importance of doing things badly

Update: added “code review” to the things that we’re doing well below.

There were a couple themes for me from OSCON last week. One is transitions and change. I’ve got a whole slew of thoughts on this, particularly from my experience leaving the management team of Open Source Bridge.

But the other is the importance of doing things badly. In particular, the importance of doing things badly in open source.

Tim Anglade, at about 41:10, says that he thinks the reason why open source companies make money is because open source is kind of shitty (from an interview he did with Cliff Moon last fall). So, on one hand there’s a Money Making Opportunity. Probably not the one that we’d all prefer, but it is what it is.

When he said that, I immediately thought about the other things that we do badly (other than documentation) and the discussions I’d been having with people last week.

Basically, we had a problem in the Postgres community of experienced developers solving every small bug at nearly the moment it was reported. It’s sort of like a cat sitting at the entrance of the only mousehole.

The effect on the code is amazing – we have clearly documented, concise and consistent code. But the effect on the community is that we don’t have mid-level developers, and it is very difficult for inexperienced developers to build up a portfolio of small projects, based on bugs.

I don’t have a ready solution for this problem. And I do not mean this as a criticism of the thousands of hours our core teams have devoted to fixing bugs. We all benefit from the dedication. I am just pointing out that our system had a clear tradeoff – fewer contributors.

What we could do a bit worse (to address the point of this blog post) is lengthen our response time to solving bugs, and let some less experienced developers respond to the bugs queue. This probably involves creating a bug tracker and holding the tension a bit longer on fixes.

Our committers have made efforts toward spreading the load around more – with commitfest – meaning a greater support of code review, with Tom’s recent presentations about the planner, with our wiki-fied Todo list. And there are many more examples of our committers putting real effort into mentoring, tutoring and finding ways of bringing more people in.

The thing that’s missing from all of those efforts, however, is urgency. That’s what bug-fixing is great for. That’s why we have people who remain in operations work even if they hate being woken up at 3am. Urgent work is worthwhile work (mostly).

I’m sure there are other particular areas where we could do things worse, and thus invite more people to contribute. I’ll be thinking about this more in regard to our project event planning, as I think there’s a bit of a disconnect there, and a huge opportunity to involve more people.

I’m reminded again of David Eaves’ talks about how community management is the core competency of open source, not technology. I struggle with that thought every day, but it rings truer the more I try to work on the significant problems facing any particular open source project.

8 thoughts on The importance of doing things badly

Comments are closed.

  1. “What we could do a bit worse (to address the point of this blog post) is lengthen our response time to solving bugs, and let some less experienced developers respond to the bugs queue.”

    While that sounds like it may plausibly attract some developers that might not otherwise get involved, it’s not 100% clear.

    We already have a low-barrier path to get people involved: code review. It has essentially no barrier at all (where bug hunters would probably be lost in many cases without decent knowledge of c/gdb). It has a tangible benefit to to community, where leaving bugs unfixed may have a negative effect. And I’m pretty convinced that reviewing code is a better way to learn — not just about the code itself, but about the process of developing code.

    “I’m reminded again of David Eaves’ talks about how community management is the core competency of open source, not technology.”

    That sounds like something that is partially true among many other factors; being presented as if it were the whole truth.

  2. Jeff: Good points.

    To clarify, I want bugs to be fixed, despite what your fourth sentence implies. :)

    Because something is low-barrier, does not mean that it is easy to get motivated to do. Bugs are nice because they typically are a satisfying, high-motivation task. I think this is why our most experienced contributors fix so many of them!

    Again, my point is not that anyone is doing something wrong. We may have an opportunity for experimentation, and could take a risk that pays off in the form of what I think is our most valuable asset: experienced contributors.

  3. This really resonated with me (which is to say, it made me laugh). I’ll definitely be sharing it with some of the folks I work with. It’s hard for people who “just know” how to do something to step aside and give someone else space to gain that knowledge, perhaps making mistakes or taking more time in the process.

    The payoff we hope for in the workplace is not only that new contributors build skills, but also that the more experienced contributors are freed up to work on more difficult tasks. Might there be other work that the experienced Postgres developers could spend more time on, were they not fixing bugs? (If the answer is “no,” it may be hard to convince to back off from that mousehole.)

  4. Amy – that’s a very good point about “what else they could be doing.” There are definitely other things, but bug fixes are a point of pride in our community. Heck, I even talk about how quickly bugs are fixed when I give talks — and during the last talk, had an audience member (not a plant!) testify that their bug was fixed in 48-hours.

    I agree with Jeff that longer lead time on bug fixes isn’t 100% certain to increase participation. But I do think it’s one experiment among many that we should investigate to increase contributors.

  5. The PostgreSQL TODO list is a problem too. A lot of the items that are on there are deceptively difficult. This is because the easy problems tend to get bashed out immediately, so only the hard ones end up on there. Newcomers should be careful to read the normally referenced discussion thread and heed its warnings. Assuming you know where the hard parts are from the description has let many a developer into a quagmire, one that was already documented during previous list discussion.

  6. I’m liking the Jeff’s point that code review is the community’s low-threshold path in. In resonates with the idea that the best way to learn to code well is to read well written code, just like writing in general. Also something that most projects lack, so that bug-fixing is the only thing available for new developers to get their feet wet elsewhere. It’s also very hard not to ‘just fix it’ once you’ve tracked down the cause of a bug. In fact, I seldom see a fresh bug ‘over the transom’, as it were, these days. They usually pop out of a fairly long performance debugging session in the mailing lists. So usually someone with deep knowledge helped find the bug, and is right there with all the context to fix it. In fact, that’s another path to deeper knowledge for PostgreSQL: hang out on PERFORM and help track down specific issues.