There is a lot of debate as to whether the FSF’s “free software” or the OSI’s “open source” is the better term. But I don’t think either fully describes the idea, or why it’s a good thing in this context. I prefer something like “open development”, because the point isn’t simply that you or I can read the code – I’m not much of a coder, and most people aren’t at all – it’s that as a result, the development of that code takes place in public. (It’s worth emphasizing, because although it appears obvious when put plainly like that, it’s not always immediately apparent to anyone who hasn’t been involved.) Even if the leaders of a particular project were to have closed-doors talks with some governmental agency, the code they produce will be seen and examined by all. Nothing is impossible, but this makes the sort of collusion we’ve seen between Microsoft and the NSA extremely difficult to pull off.
Hardware, as Shuttleworth points out, could still be a problem. Open drivers help, but the chips themselves could be doing nasty things that we don’t know about. Open hardware is the next frontier.
– Sam Duncan
There are subtle but important differences between “free software” and “open source” with free software being more of a superset. Open source is pretty important for the assurance of properly behaving software whereas the free software has more implications about guidance and development from the community and the ability to fork things should improper behavior, either from the software or the more general actions of the developers start to occur.
Hardware is indeed tricky. Even with most of the actions in firmware, it is still possible to hide a lot of undesirable stuff in the parts that need to be hardware with microelectronics being so small. I’m not sure how far open hardware will take us on that but it will be interesting to see, especially with technology becoming more and more accessible to the home user.
On a related note, relevant to previous discussions of 3d printing, I took delivery of a printrbot LC last week. So far, I have only printed a few test pieces but I already have a few ideas I’d like to try out.
Anyone else things SQOTD might be getting a little too self referential these days? Today’s is from a comment (actually the complete comment) in the thread before that no one has even had chance to reply to yet.
If I decide we have need of another editor, I will be sure to let you know.
It’s worth mentioning why hardware drivers ten to be so proprietary….
There are generally three different types of hardware device. A device has a quite simple specialist portion, in the case of WiFi and cellular cards this is the RF electronics, in the case of hard drives it’s the heads, motors and platters. Those parts are complex, but not that complex to the initiated. Then it has some means of interfacing with the rest of the system and performing data processing. There are three common methods, the first is to punt the problem to the PC itself. In that case the PC main processor runs software that does all the complex tasks, the hardware is quite basic and just puts digital information onto buses and obeys commands. Modems were the first devices to do this, it then spread to sound cards and some WiFi cards. The second method is similar to the first, the more complex tasks are dealt with by a processor on the device itself, often an ARM processor. Cellular cards, Bluetooth modules, Hard Drives and most WiFi cards use this method. The third method is to put a programmable logic device on the card and have it do all the complex tasks.
The common problem with all these three approaches is that software is very important. In the first approach the driver software running on the PC controls everything and exposes all the manufacturers secrets. Because of this limitation hardware of this type virtually never has Linux drivers. The second type has a similar problem, the driver must (usually) contain the code for the on-board microprocessor, normally in binary form. In that third approach the routing table of the programmable logic device must be stored too. This is why there are so many “binary blobs” in the Linux kernel.
This is why there are few truly open source drivers (many contain binary blobs). Those that are there are often for devices that work through the second approach, but use Flash memory or ROM to store the code rather than loading it in from the driver. They may offer proper open source drivers because the important code is written to the device at manufacturing time.
Mostly these concerns are what motivates the hardware makers. I don’t know of much that can be done about them at present.
Well, I can die happy now. QOTD. It’s only taken around eleven years. 😉
Fair point, Richard. As I said, I was really talking about the terms’ descriptive qualities – which aren’t very good – but I do understand the subtle difference. Richard Stallman’s rants against open source are eerily familiar to anyone who’s read Ayn Rand on libertarians.