Archive for March, 2009

How Open Source Isn’t Open, and What to Do About It

March 12, 2009

The Problem:

Open source development can’t be completely open. Sure, you can read all the code and docs for any good open source project. But the way you really learn a code base is by changing the source and making sure the changes work. Of course, nobody running a successful open source project can let just anybody out there in the community get in and mess with the code. So there’s a closed circle of trusted committers who do the real work of developing the project, while everybody else watches and comments. Getting to know the code well enough to become a trusted committer takes more effort than most members of the community can afford, so the circle of people who understand the code usually remains limited to small number of developers who are paid full time by an enterprise that has a vested economic interest in the project.

Suppose a developer wants to learn about the internals of an open source project, but doesn’t have much time to give. Wouldn’t it be great if there was a safe way for anybody interested the source to spend just a few hours digging into the code, and still make a genuine contribution to improving the project?

The Solution:

Code inspection can make it happen. For little effort and no money, any open source project can publish the diffs in source code changes and invite the community at large to inspect the code for defects and points of confusion. No vetting is necessary, since the inspectors won’t commit anything. The immediate benefit will be finding bugs that tests might miss. A huge secondary benefit will be increasing the number of people who understand the code and who can contribute to the project. By adding code inspection to the existing development process as an optional volunteer activity, the core developers can continue as before without necessarily waiting for their changes to be inspected, while the community at large gains a genuine sense of ownership by contributing significant value through inspection as time permits.

The Tool:

Code Collaborator by Smart Bear Software, winner of the 2008 Jolt award for Collaboration Tools, is free for use by open source projects. No, I don’t work for Smart Bear. I just heard about their product, read their free book The Best Kept Secrets of Peer Code Review, and have been looking for a place to use it ever since. I learn best by doing work that has real world value, not just academic tutorials. Code Collaborator supports inspection of any kind of source, provided it’s in text form and diffs between versions can be generated. It makes sense to inspect and improve source comments, specifications, and user documentation, not only the code. It makes sense to use inspection to identify and clarify points of confusion, not only actual defects.

Or Not The Tool:

Suppose you don’t want to use Code Collaborator. Maybe you work with closed source and don’t want to pay, or maybe your potential inspectors won’t learn to use the tool. Then find another way to do code inspections. Make your own lightweight process. There are basically two ways to find software defects. Run it or read it. You know you’re going to run it with tests and in production, so why not read it also? You will discover defects, but even if you didn’t, the benefits are worth the effort.

  • Inspectors get cross trained, so your organization is more robust.
  • Inspectors learn more coding techniques.
  • Code that’s correct, but hard to understand, is identified and
    explained or simplified.

Read the free book from Smart Bear. It’s an eye opener.

Advertisements