Programming is more fun when you keep score. The extreme programming (XP) development model popularized the idea of test-driven development (TDD) with professional programmers in mind. But TDD turns out to be even more useful for lone amateur programmers, because it provides much needed motivation in the form of more visible rewards for your work. This is true even when simple test runners are used, but I decided to make things a little snappier by including a couple of other types of measurement and generating a "scorecard" for the present state and progress of my Python software projects. Here's how it works, and a download link for my script, which I call "PyRate".

A constant pattern in the corporate environment is the gathering of resources, but with the free exchange of information inherent in commons-based projects, the pattern of choice is the dispersal of resources. This presents certain design challenges, which manifest themselves in the Unix-style "small sharp tools" approach to specialization; encourage "bottom-up design"; and most importantly require easy-to-obtain, shared, free standards for data interchange between programs. When every train car is to be made by a separate builder, it is essential that the rail gauge is constant and known.

The "edge" for free software over proprietary software comes from volunteer effort. You should spend just as much effort on designing a comfortable and inviting project as you would on any consumer establishment: you may not be trying to convince customers to part with cash for your product, but you are asking volunteers to part with their time for your project (which is not any easier).

The gender inequality among developers and supporters of free software is stunning. Less than 2% of us are women, according to studies conducted for the European Commission. Why? The evidence says we're driving them away. There are even some pretty good published guidelines on how not to drive them away. What's missing is a practical implementation strategy: here I present ten relatively simple changes in how you run your project, to make it more attractive to would-be contributors—especially women.

Language and lock-in

One of the favorite arguments for free software is that it avoids lock-in to a particular manufacturer's products. Something similar happens due to choice of programming language, though, which accounts for the sometimes-baffling project rivalries in the free software world. While this may be a surprising result to end users, it makes a lot of sense if you think about how developers—especially free-software developers—work. Occasionally, you hear complaints about these "divisions" of the free software world, but is this really a bad thing?