• Buy it in a place where every single computer ships with Windows, so that I could claim a refund. I didn’t care about the money: I just wanted to mess with that kind of vendors and file a lawsuit if I didn’t get it on good terms, to encourage people to do the same thing and thus contribute to do away with the Windows Tax.
• Purchase it from a Linux pre-installed vendor, to support them. Even if they pre-installed a freedom-trampling system like Windows, it’d be good to show them that Freedomware worths it.

I liked both options alike, so I based my decision on the computer specs and costs, not on the vendor/manufacturer.

I decided to get a Dell XPS M1330, one of the two Ubuntu-powered computers that I remembered Dell sells in Spain. So I visited dell.es/ubuntu and was surprised to find just a couple of netbooks! Change of plans; now I’ll have to get it with Windows and claim a refund, I told myself.

So the first step was to get a proof that I was imposed the operating system when I bought the laptop. Sales representatives were available for a chat, so I asked them how could I get a Dell XPS M1330 without Windows. The surprising answer was that it was available with Ubuntu and pointed me to configure2.euro.dell.com/dellstore/! Plans changed one more time; back to the original plan, get it with Linux.

I obviously asked why it wasn’t listed on dell.es/ubuntu. The sales rep said that s/he didn’t know why and that s/he will forward my query to the relevant department. I bought the laptop with Ubuntu that day and that was it.

Today, out of curiosity, I went to dell.es/ubuntu and found that it hasn’t changed! The link the sales rep provided me with the other day still works but the laptop is not listed. And the same happens in dell.fr/ubuntu, dell.co.uk/ubuntu and dell.de/ubuntu, for example.

This can hardly be a mistake. Why the heck does Dell hide some of the few Linux-powered computers they sell now? Maybe due to threats from Microsoft? After all, it’s well-know for its monopolistic practices.

PS (April 18th @ 14:00 UTC): The link above to configure2.euro.dell.com/dellstore/ doesn’t work at times today, so here’s an screenshot if it doesn’t work for you:

PS (April 19th @ 18:30 UTC): This is an screenshot of the random error I warned about yesterday (which I took just in case), before reaching Digg.com’s front-page:

Now, almost 20 hours after reaching Digg’s front-page, the link no longer works (not even at times, as yesterday) and a better formatted page is displayed instead:

I don’t know if the different error pages actually mean something, but my point is that the link is now dead.

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:

1. 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.
2. 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.

But first, let’s remember some basic terminology:

Programmer

Anyone who can create a program in at least one programming language, regardless of the use of a systematic approach (if any).

Software developer

A software developer is a programmer who doesn’t only care about about simply writing code, but also cares about (although may not be directly involved in) the requirement analysis, the functional specification, the design, the testing, the deployment and the maintenance of the software product they work on. Disciplined software developers usually follow a software development methodology, like XP.

Engineering

According to the Wikipedia (bolds are mine): “Engineering is the discipline and profession of applying technical and scientific knowledge and utilizing natural laws and physical resources in order to design and implement materials, structures, machines, devices, systems, and processes that safely realize a desired objective and meet specified criteria.”

Both programmers and software developers qualify the software progress. They can’t often meet deadlines nor track process because they don’t know for sure where they are nor where they should be. Qualification is subjective and absolutely imprecise, so you can only have subjective and imprecise answers to precise questions like “when it’s going to be ready?” (to which the most common answers are “soon” or “when it’s ready” in the freedomare world).

When you travel by car, what can you do to find how far you’re from the destination and how much time is left? You have to measure. If you find a sign that states that you’re 20Kms away from your destination and you measure the current car’s speed (well, your car does so for you) and it turns out to be 60Km/hour, then you’ll realize that if you keep the speed you’ll arrive in 20 minutes. If you don’t measure, you can’t tell if you’re on time and you can’t even avoid getting late next time (to improve, you need to know the previous measures!).

If you quantify, you will find the real status of a given process and whether you’ll reach your goals within the desired parameters (time, money, etc.). If you quantified and analyzed such measures, you will be able to execute the right corrections in order to improve the process and thus reach the goals within the desired parameters, or at least reduce the difference between the desired parameters and the final results (this is, reduce risk). And that’s not specific to software.

So, the difference between a disciplined software developer and a software engineer, is that the former qualifies and the later quantifies. In a software engineering project, when a process is going wrong, it’s found (the sooner or later) thanks to software metrics (or “software measurements”) and the appropriate steps are taken to reduce risk. In a software development project, the process is not measured and software product is delivered out of at least one parameter (over-budget, with less features, after the deadline, etc.).

I don’t think you need a diploma that says you’re a software engineer (or hold a position ending by “Software Engineer” in a organization) to call yourself “software engineer”, unless required by local law. But you need to be a disciplined software developer who measures the software process and make decisions based on an objective analysis of the relevant measures.

Learn more

There are good resources out there to learn more about software measurement. The one I strongly recommend is “Software Measurement” by Christof Ebert and Reiner Dumke (ISBN: 978-3-540-71648-8). This book is a great introduction to software measurement and covers the four kinds of software metrics (project, process, product and people metrics). I think it’s a must-read for anyone involved in software processes and wants to improve continuously (which can only be achieved by measuring!).

But there are also good resources on the Web, like the ones listed below. Unfortunately, I couldn’t find something like the book above, but online.

• Debates within software engineering, which also addresses the use of the term “engineering” in the software context.
• Software engineering.
• Software metric.
• The Goal/Question/Metric (GQM) Approach: Not everything is worth measuring!
• Software development process.
• Comparison of the occurrences for “programmer”, “software developer” and “software engineer” on the Web.