November 12th 2008
Freedomware needs more engineering and less mere “development”
I am absolutely convinced that freedomware requires less typical development projects and more engineering projects. To overtake freedom-trampling software, we need more than a good philosophy, the best hardware support, cutting-edge technology and money — we need engineering.
We have a lot to learn from the freedom-trampling industry is this regard (possibly, the only thing that is worth “porting” to the freedomware environment). In that industry, software process standards (like CMMi or ISO 12207) are widely used and often a requirement. And we need them here too:
- We have more people working together and commonly they are from different countries. Diversity is enormous. So, we need standard, comprehensive and proven mechanisms to handle the software process.
- Nearly all of the freedomware projects are mere software development projects, not software engineering projects (and that’s a huge difference!). The wide range of bad practices extends from lack of proper in-code documentation to unrealistic deadlines, including no way to keep track of users’ satisfaction (specially of those who don’t speak the lingua franca of technology). This is, free software is rarely measured (and that, using our own terminology, is a “blocker bug”).
That a given project is community-driven with no full or part-time developer is not an excuse not to measure the software they create. It’ll certainly take time to learn what and how to measure (depending on one’s responsibilities) if the person is new to software measurement, as well as time to analyze the relevant collected measures periodically, but rest assured that by basing your estimations and decisions on such an periodical analysis, the continuous improvement of the project would be guaranteed.
Of course, not every freedomware project “must” be a software engineering project. Tiny projects aimed at a very limited audience and maintained by a couple of developers may not require such a care, specially if it’s not expected to grow too much.
Unfortunately, it’s worth noting that there’s a drawback of using standards like the ones mentioned above: They (usually) assume a software development process like that of non-free software, so you’ll frequently encounter (much) text specific to such processes; and as a result, many processes specific to freedomware development are not covered. I think we need an standard that addresses our software development processes.
Learn more
As in the previous article on software measurement, I recommend the book “Software Measurement” by Christof Ebert and Reiner Dumke (ISBN: 978-3-540-71648-8). As I said previously, it’s a must-read, although it’s perhaps specially aimed at decision-makers and not too much at developers themselves.
Another good book on this topic, which is more practical (as its title implies), is “Software measurement and estimation: A practical approach” by Linda Laird and M. Carol Brennan (ISBN: 978-0-471-67622-5). This one is definitely aimed at developers themselves.
If I reached my goal of making you interested in software measurement in freedomware, then you may also want to keep an eye on the upcoming ÉcoleCua project.
Finally, I invite you to check out Ohloh.net, a gratis and basic metrics service for freedomware projects.
