Opinion: What's the real reason for closed, proprietary code? Embarrassment.
Sure, we are drowned in tides of twaddle about precious IP, Trade Sekkrits, Sooper Original Algorithms that must not be exposed to eyes of mere mortals, and all manner of silly excuses. But that's all a smokescreen to cover up the real reason: to hide code of such poor quality that even PHBs know to be embarrassed. Exhibit A: Windows itself. Which proves it takes more than throwing billions of dollars and thousands of programmers at a software project to build something that is actually good.
Diebold, Champion of Ugly Bad Code
There is a good ugly code and there is bad ugly code. Good ugly code is not "elegant", whatever that means, but it works well and isn't full of holes. Diebold is the poster child for bad ugly code, which they have fought mightily to conceal under the tattered "trade secrets" excuse. As if- they were shipping shoddy code, and they knew it. I wonder where they got the idea that no one would notice, because hiding the code doesn't hide what it does.
Samsung's Excellent Rootkit
Number three on our hit parade is Samsung's infamous binary Linux printer driver. Oh, that one's a knee-slapper. The installer— I am not making this up—changes the permissions on key Linux system directories, and replaces a batch of executables with setuid wrapper scripts. setuid means ordinary unprivileged users can run these executables with rootly powers. So installing the Samsung printer driver comes with a fun double whammy: screwed-up permissions and local privilege escalation! Yay! Now that's some compact coding.
I had to see this one for myself, so I downloaded their Unified Linux Driver and took a peek in install.sh, which fortunately is a nice human-readable shell script. This is but a representative snippet of the badness therein:
So OpenOffice and your scanner tools launch with root privileges for ordinary users without asking for a password. In effect, it's a built-in rootkit. But that's not all. It also changes the owner on /etc, /usr, /etc/sane.d/, /usr/lib/, and /usr/lib/sane/ to an unprivileged user instead of root. That is some seriously perverse ingenuity.
Yes I know, this isn't exactly an example of bad closed source because anyone can read the installer script. But if they're this incompetent with a shell script, what does the driver code look like? Note also that this was reported repeatedly to Samsung, with no fix until it hit Slashdot.
The x86 PC BIOS is a relic of a bygone era. You'd think something this tiny would be easy to continually improve and modernize. But no, not at all. Even on our shiny powerful modern hardware, the typical closed, proprietary (and buggy and inflexible) BIOS thinks it's still supporting MS-DOS, probes hardware, loads drivers, scans for bootable devices, initializes memory, and allocates interrupts. Then, at last, it starts up the operating system which ignores everything the BIOS did and starts over (both Linux and Windows do this). A number of Linux distributions are investing resources in improving boot times, but the BIOS alone accounts for 30-60 (mostly wasted) seconds of boot time.
Contrast this with the OpenBIOS project, which takes a different approach. OpenBIOS assumes the operating system is going to do the work, so all the BIOS needs to do is get the machine to a state where the OS can take over. The Linux kernel is a lot faster at detecting hardware and loading drivers; it doesn't need an antique moldy BIOS getting in the way. We don't need to see inside that little bit of code to know that it isn't pretty- the way it functions speaks for itself.
OpenBIOS is already being used in a number of projects, such as the LinuxBIOS, which is amazing and impressing all kinds of people with 3-second boots and unlimited customizability.
Way too many of the closed-source applications and drivers for Linux don't even try to keep up. NoMachine's Linux server and client, for one example, rely on an ancient version of libstdc++ that sends you wandering all over Google trying to locate a copy of it. Most printer vendors don't even try: Given a choice between vendor-supplied drivers and reverse-engineered CUPS drivers, you're almost always better off with the CUPS drivers. Which is pretty amazing considering how few of these have any sort of vendor support.
When the Netscape browser code was opened up and flung upon an eager world, it nearly caused a pandemic of heart failures because of its blue-ribbon spaghettiness. The majority of the work in the early years of the Mozilla project was cleaning up the mess. Same story for OpenOffice, which is descended from StarOffice. StarOffice was originally this giant monolithic blob; a self-contained little universe that barely needed an operating system, because it contained its own working environment. Poor old OpenOffice has been struggling for years to get out from under this unwieldy architecture.
Naturally there are examples of both good and awful code in both the closed- and open-source universes. I'm just not buying into the "protect our preciouss IP" excuse because it is so overused. What's so precious about bad software?
- Rage against the machine, in which even Fortune magazine admits that one of its pets isn't quite up to snuff
- Major Security Hole In Samsung Linux Drivers
- Samsung Linux Printer Driver SetUID Script Local Privilege Escalation Vulnerability
- Ubuntu's Upstart
- Open BIOSes For Linux
- "Chapter 1 "The Mozilla Project: Past and Future" of Open Sources 2.0