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".
There is no "magic" to commons-based peer production. Most of the techniques that have brought free culture products ranging from software to art to electronic hardware have been in play for hundreds or thousands of years. But they do run counter to the patterns of commercial proprietary industry. Due to the massive improvements in communications and authoring technology, we have reached a point where we can be more productive in our "leisure" than we are in our "work". And any labor of love is almost always going to be superior to labor alone.
Since free software and other free culture products are formed by an organic, incrementalist process, they tend to be highly organic in their design as well. Free software is not so much built as it is grown. Thus, when considering a new project, you must think not about how to break it down into implementable chunks that can be assembled into a working product, but rather about how the project can organically grow—moving from working product to working product as it does so—becoming progressively more useful as it is developed.
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.
Many systems support video upload and viewing functionality. Of course, all video files uploaded by users shall be converted to some common format (flv format as usual) to make playback easier, probably scaled to common resolution, or watermarks are required on the site, etc. Therefore, developers have to solve the problem of video conversion very often and use various approaches.
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).
Terry Hancock seemed to raise a few hackles when he presented case recently that "copyleft has no impact on project activity?!)". I'm not certain why, because it seemed he was just asking a question really (you'll note the question mark). In that piece he mentions the reasons developers choose a copyleft licence. As a -- somewhat small-time -- developer of free software this topic interests me. Terry made a few statements about why developers choose a copyleft licence as did Tony Mobily in his editorial for issue 20. So let me tell you why this developer chose (and continues to choose) a copyleft licence?
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.
Recently, I collected some data from Sourceforge, hoping to find evidence for the importance of copyleft. But I found something surprising: although there's plenty of evidence that many developers believe in the power of copyleft, the one measure I could derive of how much copyleft actually works showed that copyleft made no difference whatsoever! If true, this means a lot of free software's social theory is wrong and many things will have to be re-thought.
Some people seem to challenge the idea that most (if not all) free software projects need a benevolent dictator--that is, somebody who has the last say on every decision. They are quick to point out Linus Torvalds' past "mistakes" (see the speech marks): using BitKeeper to manage the kernel, not allowing "pluggable" schedulers in Linux, etc. As a software developer, I feel that a dictator is absolutely necessary in every free software project. Here is why.
Respect earned by the BDFL
From http://bear454.blogspot.com :
Jimmac announced today on the Tango Mailing List that thanks to about a bazillion requests and the negotiation skills of Michael Meeks, the Tango Icon Library will be changing licenses from CCASA2.5 to Public Domain. Yes, folks, free as in free. Put those beautiful icons in any app you want; they're yours...
Plone is a well-known Content Management Systems (CMS). Since it's relatively easy to customize to a specific enterprises style and workflow, there is a healthy trade of services around the core software. Martin Aspeli, the book's author, is an active contributor to Plone. Heavy involvement in a project that you are writing about always bodes well for the potential value and quality of a book that you, the reader might be considering buying. Aspeli's book "Professional Plone Development", published by PACKT, proves this quality point once again.
There are few people who would deny that Autoconf, Automake and Libtool have revolutionized the free software world. While there are many thousands of Autotools advocates, some developers absolutely hate the Autotools, with a passion. Why? Let me try to explain with an analogy.
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?
If you want to develop applications with GTK+, a graphical toolkit used by the GNOME desktop environment, it is essential that you are comfortable with the C programming language. This article is meant to give you a short refresher on the basics of C that you will need to know when developing GTK+ applications.
Web developers are sometimes forced to travel. Unfortunately, lugging a big, bulky laptop around with all their programs is the only way to develop on the road. After all, using another computer is out of the question since it doesn’t hold all of your favorite programs. Luckily, there is a best of both worlds. Thanks to John T. Haller, the Apache Friends, evolt.org, winPenPack.com, and a host of others, you can carry an Apache server, a MySQL (and SQLite) install, a PHP install, a Perl install, a mail server, an FTP server, two popular web browsers, an FTP client, an HTML editor, an image editor, and a vector graphics editor on a 512MB flash drive to be used with any Windows computer. All using free software.
Programmers. The system administrators worship their bit twiddling capabilities. The users exchange vast quantities of beer for new features and tools. And the project managers sell their souls when they make the magic work. But inside the average programmer’s psyche are several demons that need exorcising.
Drink was the first great leveller, as it brings everyone to the floor eventually. The second was the Internet. Everyone can be published, listened to, and promoted giving freedom of expression to the masses. Community-driven development is the third leveller, as it allows anyone to affect a project that's important to them, as either a programmer, artist, writer, or web designer. Alas, the leveller in this case engenders a flat uninteresting landscape because these self-assumed polymaths reduce everything to the best they could manage. And not the best that can be achieved.
I still haven’t found a free software case management framework for non-profits emerging on the horizon. If you search SourceForge or Freshmeat, you find legal case management systems, but nothing oriented to the general non-profit market for client management. There are electronic health records, CRMs and ERPs... all of which have elements that would be useful, but none alone can do the trick.