Among modern programming languages, Ruby is relatively easy to learn and use. Given that fact, a book designed to introduce Ruby to experienced programmers should be a fairly straightforward endeavor. O’Reilly’s Learning Ruby succeeds in this regard, but unfortunately tries to teach people new to programming as well. If you ignore the oversimplified (to the point of inaccurate) explanations of programming theory and just concentrate on translating your current programming knowledge to Ruby, you’ll find this book an excellent resource.
Writing analysis
At 238 pages, Learning Ruby is among the shortest programming books I’ve yet read. I wish I could say that the reduced length means that it’s superbly written, using fewer words with more powerful and specific meanings, but I can’t. Were this book brilliantly written, it would probably be about 3/4 of its length, and would be maximally functional. As it is in this edition, Learning Ruby is difficult to read — the language is cluttered, non-specific, and meandering.
The author is obviously a fruithead, and over-covers the Apple platform while predictably over-generalizing instructions and advice for Linux. Fortunately, very little of the book focuses on platform-specific technical instructions.
Each of the eleven chapters focuses on a particular programming topic, and each section narrows the topic down to specific methods and processes for doing work in Ruby. Since Ruby is versatile and offers a number of different problem-solving approaches, the author shows as many of them as possible in each section. Every chapter ends with review questions that pertain to the preceding material; some readers may find these helpful to retain the information they’ve just read.
There are no programming exercises in Learning Ruby, and the code samples are small and only functional as an example of how a particular function or process is used.
Putting the book to the test
I can’t stress enough how difficult it is to read Learning Ruby. Here’s an example of what I mean, taken from a warning box in chapter 1:
“If you get a permission denied message when running matz.rb, and you aren’t sure what to do about it, I’d like to offer you a hand. Go to the section ‘Permission Denied’ near the end of this chapter to find out what to do.”
Language like this makes my liver itch. Teach me — tell me what to do. Don’t tell me the story of what I should do. In the same number of words, the author could have told us how to fix the problem, rather than bluster on about how we might feel and what he would like to do for us, and then tell us where else to go to find a solution. Learning Ruby is one scatterbrained abomination of a sentence after another, which makes it difficult to learn from.
The technical discussions are equally substandard. The explanation of object-oriented programming is particularly terrible. Learning Ruby’s author took what should be a simple overview of classes, methods, and objects, and turned it into something that, after reading it ten times, I still could not accurately decipher.
The only good part about Learning Ruby is that it excellently imparts the mechanics of the Ruby language. If you already know data types, object-oriented design, and other programming essentials, the author brilliantly shows you how they are all applied in Ruby. He shows not just one approach, but several that you might know from a variety of different programming languages. So if you have, for instance, an existing C++, Pascal, or Java program that you would like to re-code into Ruby, Learning Ruby will be a great help to you.
Conclusions
Learning Ruby claims to be aimed at both beginning programmers and experienced software developers. In that, there are explanations of programming principles as well as examples and commentary that show you how to write Ruby programs. Unfortunately, the elementary explanations are insufficient at best, and vague to the point of incomprehensible at worst. If you intend to learn how to program by following this book, you will be badly misguided in the elements of software development.
On the other hand, if you’re an experienced programmer, Learning Ruby is an efficient (if difficult to read) guide to translating your current knowledge into Ruby-friendly terms.
I’ve always resisted the urge to blindly bash Microsoft — indeed it does make a few really nice products, and has had a positive impact on the computing world in some important ways. I also have to try to maintain a neutral stance on computer products that I intend to review, with the understanding that a product’s quality and a company’s behavior speak for themselves. Today I’m writing about something that all computer users need to be aware of, and Microsoft’s at the forefront of the effort that goes against user interests. Specifically I’m referring to Microsoft’s crusade to convince the International Standards Organization (ISO) to adopt its proprietary Office file format as a standard. If Microsoft wins this, we all lose.
No matter what your word processor situation is, you have at some point in your life experienced file format compatibility problems. Even if you only use Microsoft Office to create and read documents and you upgrade to each new version the minute it’s released, you’ll still run into problems sending Word or Excel files to other people who don’t have the latest version. More likely, you have an older version of Office that works well for you, but you can’t read files created with newer versions of Word, Excel, or PowerPoint. Maybe you’re one of the few and the proud who understands the superiority of WordPerfect or TextMaker, or you’re using the free OpenOffice.org or its commercial counterpart StarOffice. If you use one of these suites instead of Microsoft Office, then you already know the hassle involved with file format conversions.
If Microsoft wins the ISO standard war (and it’s trying really hard — it’s forcing or paying off its customers to flood ISO meetings with favorable votes), the file format problem has no hope of going away in the forseeable future, and in fact it will get worse as time goes on. Making Office Open XML (OOXML) the official ISO document format will encourage government agencies, corporations, and schools to standardize on it, which will more or less force them to buy MS Office 2007. The worst part, though, is that if these things come to pass, you too will be required to buy Office in order to exchange documents with these entities. In effect, the problem will be a lot more severe, because OOXML files created in one program could display differently in other programs.
The big problem with OOXML is that it is impossible to uniformly implement. Microsoft did not publish the entire standard — only the “required features” of the standard — so it’s not only possible, but according to history it is an absolute certainty that OOXML documents created by OpenOffice.org or WordPerfect will not work properly in Word, and vice-versa, because Microsoft will implement hidden portions of the standard. Secondly, much of the OOXML standard is left to application-specific rules and procedures. This means that similar features in different programs can write their OOXML files in different ways, essentially making them incompatible. Tactics like these are old hat for Microsoft; it is not the first time it has released specifications in the outward interest of compatibility with competing software, only to turn around and make its own products the only ones that work properly by taking advantage of hidden or undocumented and secretly required features. If you’re at all like me, right now you’re wondering how in the hell something this non-specific and nebulous can possibly be considered a “standard.” Standards are supposed to be static, thoroughly documented, and well-understood by everyone who needs to implement them. OOXML cannot be considered static, only part of it is documented, and it is impossible to understand it completely when parts of it are secret.
We already have an industry-accepted ISO standard document file format that is completely open and free to fully implement — OpenDocument. Microsoft’s effort to push OOXML through is nothing more than a ploy to force more people to buy Microsoft Office (and by extension, Windows Vista).
Last week Metaweb announced that its open information database, Freebase, had gone into public alpha, meaning you no longer need a registered account to access Freebase. Half the reason I know about this is because I wrote some documentation (it’s an O’Reilly Short Cut PDF, but you can download it for free) for Freebase developers a few weeks ago. It’s really quite an interesting service — kind of like Wikipedia, only in the form of a graph database.
Frankly, I don’t understand the concept of “public alpha” — I think the term “alpha” in software development belongs more to marketing and PR than it does to programming. If something is still in the alpha stage, it’s under active, volatile development, so it’s not ready to be used on a critical basis. In this case, the term does not properly apply to Freebase in its current state — it’s perfectly usable and you can start accessing, modifying, and building applications for it right now.
Freebase is an online, publicly accessible graph database (as opposed to a table-based relational database). Much of its data is Creative Commons content from other online information sources like MusicBrainz and Wikipedia, but Freebase’s users are slowly refining what’s there and adding more information as time goes on and the registered userbase expands. As of this writing, you still need to be registered with Freebase in order to modify or contribute. Registration is handled on an invitation-only basis; if you’d like a Freebase invite, email me at jem at thejemreport.com and I’ll send one out to you if I have any left.
For many years I’ve lamented two fundamental problems with software: that it doesn’t have features I really want, and that it doesn’t work the way it is supposed to. In other words I’m talking about a lack of appropriate features and a surfeit of bugs. As the era of open source software is slowly ushered in, and the era of proprietary software slowly wanes, I see the two different programming and licensing philosophies more dramatically exhibit these two fundamental problems, each to its own weakness. Neither of these philosophies is ever going to be enough to create truly great software. I wonder what the perfect licensing, distribution, and development model will be, assuming it has not been invented yet.
With open source software the traditional fundamental problem has been a lack of features. A program might almost do what you need it to, but not quite provide the same level of functionality that a proprietary alternative does. Likewise, in the height of the proprietary software era in the 1990s, a program might have all of the necessary features, but crash at inopportune times or only work under a certain set of conditions. Today those roles are totally reversed — most of my extensive experience with open source software on both desktop and server systems has elicited piles and piles of bugs and problems, nearly all of which are fixed for no cost in a reasonable amount of time. Likewise, proprietary software has increased in price and is delivering less interoperability with other software, less compatibility across different versions and platforms, and fewer features that in my professional opinion are necessary for the target userbase.
The traditional open source business model is to give the software away for free, but to charge for various services — installation support, paper manuals and pressed CD/DVD media, telephone technical support, bug fixes and other software updates on demand or as part of a subscription service, and custom software development. The “product” here is not the software (whatever it does), but the amount of responsibility and interactivity the company that distributes it provides. Seems like a great idea until you consider the fact that the company is never financially compelled to produce a technically perfect product — such an application would never need the associated services that the company charges for.
On the other hand, you have proprietary software that you pay a large one-time fee for. You might get a minimal amount of included support over a short period of time, and you might get major bug fixes for free through service packs and patches, but you won’t get the same level of service that you’ll get through an open source company. Certainly you can pay a lot more to get a little extra service, but it’s not the same. Proprietary software companies are built on the traditional “physical goods” philosophy that you make a great product and sell it as such. Windows is Microsoft’s best attempt at producing an operating system that it hopes you will be compelled to buy. But what about a company like Canonical or Red Hat? They are not financially compelled to produce a superior product — instead they aim for superior services.
Neither of these models is going to succeed in the long run. Once you’ve created the best product imaginable — as Adobe has done with the majority of its creative tools — it is very difficult to continue making money off of future upgrades. Macromedia Studio MX was the apex for Flash, Dreamweaver, FreeHand, and Fireworks, but there have been three upgrades since then. Each upgrade adds little things, but costs hundreds of dollars. Gone are the days when new versions brought huge, disruptive changes in proprietary desktop software. This model is not financially viable over the long-term, but as a user, at least I have the satisfaction of knowing that I’m buying someone’s best attempt at producing a great product. I rarely get that impression with open source software. I don’t think the ultimate design philosophy has been invented yet; I very much look forward to experiencing it, though.
While researching the details of the new Adobe Creative Suite 3, I discovered an Adobe employee’s long list of reasons why CS3 is not 64-bit. Some of them are valid, but when he regurgitated the tired old argument that compiling a program for a 64-bit environment does not make it faster, I had to wonder if he’s just making up excuses for code quality problems.
Compiling a program for a 64-bit environment dramatically increases its performance in any kind of filtering, sorting, encoding, or encryption operations. I’ve proven this in the past (more than once, actually). Almost every program in Adobe Creative Suite 3 does at least three of these four memory-intensive operations and would benefit in some way from being recompiled for 64-bit Windows Vista.
Another lame excuse the Adobe guy came up with was that 64-bit Windows Vista has poor driver support. What does that have to do with Creative Suite 3? And since when has poor operating system quality stopped Adobe from releasing software for that platform? Heck, Adobe itself isn’t afraid to release poor-quality software — I recall my first month with Dreamweaver MX 2004 being riddled with crashes and a few non-working features, and how many times has the Flash Player plug-in crashed your Web browser? Strange how Adobe is suddenly so concerned with operating system quality and driver support when the company has repeatedly chosen to ignore the desktop and workstation operating system with the broadest native hardware support — Linux.
One of the valid reasons the Adobe blogger lists for a lack of 64-bit support in Adobe products is the assertion that the company can’t afford the cost to test or distribute a separate 64-bit binary. The challenge introduced by supporting two operating system platforms that offer different bit-ness is also a valid and appropriate concern. But please, Adobe blogger, don’t tell us that there’s no performance advantage and that Vista 64-bit isn’t good enough for you. In the recent past, people like this were hawking similar absurdities about multi-CPU and multi-core desktop processors, but today it’s impossible to find a desktop OS that isn’t configured to take advantage of multiple CPU cores. As of this writing it is extremely difficult to buy or build a desktop computer that does not have a 64-bit instruction set ala AMD64 or EM64T. How much longer do we have to deal with poorly programmed “all the world is x86″ software?
The editor in chief of PC Magazine announced his departure last week, coupled with an editorial on his turnaround of opinion on Windows Vista. A longtime friend of his told me (and publicly wrote the same) that this is a significant change of opinion — that this editor had been in love with Windows since version 3.0, and it would take a lot to break that affection. I’ve been trying to find the brighter side of Vista since I first started testing it, but no matter how hard I try, I keep coming to the conclusion that Windows Vista just is not worth the money to buy, or the trouble to use.
I have to use Vista about once a week on average, almost always so that I can test some new desktop application. Lately it has been the new Adobe Creative Suite 3, so I’ve had more seat time with Vista lately than I’ve had since I wrote the Windows Vista review for Software in Review. Right now I’m working with the 64-bit edition to see if I can gain a better understanding of all of its problems in comparison to the trouble that Linux and BSD operating systems have in 64-bit mode. So far, my conclusion is that Vista has many more (and more visible) problems than any other 64-bit AMD64/EM64T operating system I have used recently. Vista is in the 64-bit stone age — it has driver problems that BSD and Linux OSes have not had since the first generation of the Athlon 64 and Opteron were new. I have a Diamond sound card in the Vista test system that does not work under any conditions because Diamond won’t write a Vista driver, and Microsoft doesn’t have a generic sound driver that will work with it in 64-bit mode. Linux does. FreeBSD does. Heck, I think OpenBSD does too.
Every time I use it, I keep thinking that I’m going to like Vista this time, even though it’s done nothing but frustrate me every other time I’ve used it. I think years of Linux and BSD customization has instilled in me the sentiment that if the software isn’t working as intended, that it is probably my fault somehow. I haven’t read the instructions, or I’m not changing the right options, or there is a problem in an area that I am not considering. This is how it was with DOS, and to a large extent Windows 95 and 98 (networking aside), but with Vista there is no longer enough room for user error to assume that you are the problem. Vista’s design is such that if there is a problem with the way the system is operating, you are not empowered to find out what is causing the trouble, nor are you able to fix it. Instead you’re trapped in a maze of automatic wizards with too few options, and nondescript warning messages that are unable to help you with anything.
My father’s opinion mirrors mine. He bought a new laptop computer with Vista preloaded on it, and liked “that new Vista” at first. After a few weeks of frustration and neverending network problems, he called and asked how he could get rid of it and put XP on the machine. He, too, would like to switch to Linux, but he needs some really expensive proprietary hardware control programs that only work on Windows and don’t operate correctly through a virtual machine. It really sucks when vendor lock-in extends well beyond the product a vendor sells.
The former PC Magazine editor’s solution was to switch back to Windows XP and think about switching permanently to Linux. Going back to XP is a temporary necessity, but switching to Linux is a long-term necessity for any technically able user who needs more that just “Web and email” in his desktop computing life (proprietary industrial hardware control and analysis software aside). Windows Vista really is that awful that switching to a dramatically different operating environment is a serious consideration.
In preparing to read and review O’Reilly’s The Myths of Innovation, I had the chance to interview its author, Scott Berkun. Scott worked on Internet Explorer for Microsoft back in the mid-1990s, is the author of The Art of Project Management, and currently teaches “creative thinking” at the University of Washington. In this interview, Scott Berkun answers some questions about innovation at Microsoft and in the open source software world.
You used to work for Microsoft. Could you provide some examples of good and bad methods of innovation that you experienced there?
Scott Berkun: The best method by far is avoiding the i-word (innovation) altogether. Focus on solving a problem. If it’s a good, important, hard problem to solve, you’ll be plenty innovative without ever having to say the word. You’ll be so focused on solving a problem that you’ll invent and create as a secondary need to solve the problem, and that’s the best, most common method of innovation I’ve found in history. Da Vinci, Edison, and Tim Berners-Lee didn’t use the i-word much, and neither should anyone else. In fact, innovation is over-rated anyway; be good, be useful, be reliable, and you’ll beat the pants off your competitors. Doing those 3 things alone is beyond 90% of what’s out there now.
The most successful innovative teams I worked on at MSFT were the early days on Internet Explorer, around 1995-1998. We just picked very clear, but hard problems, and had managers that supported individuals taking initiative in trying to solve them. Internet Explorer has a muddied reputation today given its abandonment from 2000 to 2005, but back in the 90’s we were paving new ground in every single release in a back and forth war with Netscape. The secrets were clear goals, smart people, and high trust in each other.
The worst thing in the world is to throw the innovation word down — innovation teams, innovation task forces, etc. That tends to put people in ivory towers instead of helping them run low to the ground, where customers and real important problems are. Successful innovation depends on understanding people and their problems more than it does the ability to create technological wonderments.
In your book, you mention that Internet Explorer is the dominant Web browser design, though it is aging and other browsers like Firefox and Opera are taking more risks and being more innovative. Since Opera doesn’t make any money from desktop PC Web browsers, and Firefox is owned and controlled by a not-for-profit foundation, what do you suppose the motivation is for innovation in these projects? Are people naturally impelled to innovate regardless of financial reward?
SB: Creators have always had personal motivations – very few creative minds throughout history got paid well for pursuing their ideas (talk to Van Gogh, Mellvile, Wittman, Guttenberg, etc.), so it’s not surprising that many programmers are willing to volunteer their time. I think creatives live to see their ideas used by others, and open source development excels at providing those kinds of opportunities.
About Firefox: While I’m a very happy Firefox user, its core design — certainly at the user experience level — isn’t far from the early Mosaic/Netscape/Internet Explorer designs. It wont make the innovation history books as the beginning of a new generation of browser design. It’s certainly a better browser, but there’s not enough fundamental change to call it an innovative browser. Opera is way more deserving of that title, although Opera has so much creativity going on its design, that from a user experience perspective it could do with less innovation.
It is generally believed in the open source community that the “benevolent dictator” approach of software project leaders like Linus Torvalds is the most successful method of attracting innovative changes from a large body of contributors. Is this true, in your experience, or would it be better to take a more democratic approach?
SB: First, the honest, but cop-out answer: There is no single answer to this — it depends heavily on both the culture of people involved and the goals that they have. Anyone passionately advocating an approach without studying the terrain is a fool.
More troublesome is the popular confusion of democracy with equality, a comparison which has always been false. Sure, everyone gets one vote, but in all democracies some votes are way more influential than others (true for Greeks, Romans, Americans, etc.). It’s natural for any large group of people to have a small group of leaders at its core — people who are more committed and invested than others, and whose opinions carry more weight. If you want rapid change, you do want more centralized authority, as the number of approvals needed for change is smaller and the pace is faster. But if you want sustainability, you need checks and balances. Finding the balance is the central challenge of management and it’s an intuitive, experience-based skillset. Wise leaders in open source projects, or any “people herding” type activity, can learn much from studying political science and sociology, as the pattern language of success here has little to do with technology — it’s group dynamics of human beings.
You might shoot me for this, but I’m skeptical that open source draws more innovative changes from contributors than other systems of software development draw from theirs. Open source certainly attracts contributors, and increases the pool of people involved, but most contributions are so isolated in scale, and in impact on users, that it’s hard to consider them “innovations.” Perhaps open source as a model can be called an innovation, but most of the development work, bug fixes, and feature additions involved are relatively ordinary development work, just like on any other software project. Most open source projects have locked trees, which means if a big innovative change is going to make it in, it’s the choice of the gatekeepers, not the democratic masses: which is the same story in a non-open source environment. Apple is perhaps the icon of innovative engineering in 2007, but their model is about as far from open-source as possible. The gatekeepers in both cases drive how much innovation goes out the door, so I always look to the gates. Whoever is standing there is the real story of innovation.
Do you think that being able to see and modify a program’s source code is a good method of innovation?
SB: Sure. Understanding how things work is the fastest way to learn and gives people who come later reusable, proven methods for doing things. But at the same time, it provides sets of assumptions that are more efficient to follow than to reconsider or reinvent. So depending on what level of innovation we’re talking about (a feature? a product? a line of products? a paradigm?) access to source code has different levels of value. And there’s also the value of mystery — sometimes a locked box forces people to be more creative since they have to invent their own approach. Being angry at that locked box and wanting to figure it out can drive people to innovate who’d be bored if they had permission to take it apart and see the source (as the legions of hackers and reverse-engineers out there can attest).
What’s the question I didn’t ask? What would you say to software developers that you didn’t say in your book?
SB: Software engineers are super bright, but suffer from their education – we’re taught (I’m a CMU computer science grad) a myopic view of not only our world, but even the history of our field. I wrote The Myths of Innovation as a concise, funny, crash course in the history of how we got here, applying relevant history to explain the patterns of innovation we see today. That kind of foundation is essential to improving the odds of progress, and its absence is the greatest liability of would-be inventors, creators and programmers everywhere. Whether people get that piece of innovation knowledge from me or someone else, it’s critical to their goals to get it. I’d love for programmers to kick ass and live up to their dreams of changing the world, but they need tactics derived from innovation history to make it happen.
The Mambo content management system (CMS) is among the most popular Web publishing tools in use today. It’s easy to install, configure, and use on a basic level, but runs into various problems with complex configurations. Learning Mambo seeks to prepare readers for configuring almost every aspect of Mambo, but it falls short in important ways.
Writing analysis
Learning Mambo starts out with a basic overview of the system, and establishes its primary example — a site for the fictional Zak Springs Golf Club. Chapter 2 is an overlong description of how to install Mambo on your local machine; instructions for uploading the site to a remote server are not given until the very last chapter. The middle of the book concentrates on exploring and configuring Mambo through its backend interface, and installing new templates and add-ons via the extremely easy-to-use interface. The last — and most useful — parts of the book give some tips and advice for customizing Mambo on a deeper level by hacking some of its files.
The language in Learning Mambo is at times jumbled and difficult to follow. It probably could have done with a good editorial cleanup to eliminate unnecessary words, phrases, and ambiguities. This book is by no means unreadable, but it’s also far from its maximum potential in terms of use of language.
Putting the book to the test
The main problem with Learning Mambo is that most of its content covers obvious subjects, or topics that are already thoroughly documented through the Mambo help system. The remaining information is useful to people who are new to content management systems, but it won’t solve all of their problems. Learning Mambo frustratingly ignores Mambo’s dirty secrets, like the bugs in the menu and SEF systems that show permissions errors when you delete a menu or move content to a new category, or the RSS feed module’s non-SEF compliance, or the difficulty in upgrading to a new version, or the horribly bad scalability of the Mamboboard forum component, to name a few. These are the problems that experienced Mambo administrators have been dealing with for years, and I speak for all of them when I say that we would gladly have paid $45 for a book that would have told us how to solve them without spending hours hacking PHP files and scouring various forums for clues.
Aside from the several parts of the book that concentrate on obvious or elementary topics, Learning Mambo gives a lot of detailed advice for hacking various Mambo functions and components. I wish these Mambo hacks were more detailed and wide-ranging in subject matter, but even as they are, these tips are the book’s saving grace.
Despite the shortcomings of its content, Learning Mambo is easy to follow along with, and doesn’t have any glaring errors or omissions aside from what has already been mentioned above.
Conclusions
Learning Mambo functions well as a basic introduction to Mambo. However, Mambo is easy enough to use and figure out on this level that a book is unnecessary — let alone a book that costs a whopping $45. If you’re serious about creating a popular, monetized Web site with Mambo, this book has little useful information to offer you. If you’re looking for a good Mambo primer, Wiley’s much less expensive Mambo Visual Blueprint may be a better choice, though even with that book you will still have to discover Mambo’s dirty secrets on your own.
There is a vast body of computer software that can no longer be used on modern computers and operating systems. Some of these programs are still great, even by today’s higher standards. As time goes on and companies forget about their old products, or are bought out by larger corporations that abandon unusable assets, we will reach a point at which the greatest desktop software ever made is no longer usable.
Though this topic has been on my mind for years, it came up again recently when I discovered that a program that I thought was great — Macromedia Freehand — is being killed off in favor of Adobe Illustrator. Freehand fans have known this since Adobe’s acquisition of Macromedia many months ago, and I was peripherally aware of this fact, but it didn’t really hit home until it was time to review the new round of Macromedia tools. I’ve got Illustrator CS3 here for review, but I haven’t gotten to use it yet and don’t yet know if it’s truly a replacement for Freehand. I suspect that it isn’t; Freehand was a vector drawing tool that focused on aiding Web page design. All of the programs in the Macromedia Studio suite were designed at their core to be about creating content for the Web. Illustrator, on the other hand, has always been focused on being a great vector graphics program with a slight bias toward print media. Both have their merits, and I would expect fans of each to say that their favorite is the superior program. Killing off Freehand won’t make people like Illustrator, though, especially if it does not have the same functionality. Removing Freehand diminishes the usefulness of both Flash and Dreamweaver, particularly for people who were used to using the whole Macromedia suite to design Web sites.
You can’t write an article about dead software without mentioning BeOS. I wasn’t into Be systems when the company was still alive, but ever since I saw the open source Haiku rewrite of BeOS for x86 machines, I’ve been convinced that this is a superior desktop operating system design. It is not a hodgepodge of various open source programs like Linux, nor is it a hodgepodge of various proprietary programs from a variety of different companies like a Windows environment generally is. Its modular design keeps BeOS from being a huge and unmanageable project like FreeBSD, and gives it security and stability that Apple OS X can’t ever hope to match. Be, Inc. was killed off by both Microsoft and Apple through separate means, and its software assets were sold to what was PalmSource, or what is now known as Access. Presumably Access still has the BeOS source code someplace, but won’t give it out to anyone — or even license it out to companies that want to sell updated versions. Rumor had it that Access was going to use the old BeOS code in a new mobile device operating system, but it appears as though those plans were cancelled in favor of a Linux-based solution. So what will become of BeOS? Access won’t answer any media inquiries about BeOS, so we may never know… except to honor it as another inhabitant of the proprietary software graveyard.
Near and dear to my heart are the old Sierra On-Line PC games. This was the company that defined and pioneered electronic role-playing adventure games. They had an idea for a MMORPG that predated World of Warcraft by several years, but never found a way to build the infrastructure to support it. Sierra also had the first graphical online gaming service called The Sierra Network, but though it was popular, it was not profitable. There were so many tragedies at the old Sierra On-Line that a technophile could not hear them all in one sitting without shedding a tear. The greatest among these misfortunes was that Sierra went public, was bought out (eventually) by Vivendi/Universal, and killed off the adventure game genre. All those old DOS games are lost to history, their adventures and stories confined to past-EOL floppy disks and abandoned 20MB hard drives.
It didn’t have to be this way — these companies could have released the source code for products that they never intend to use again, allowing the people who paid between $20 and $60 (in 1980s money) to continue to enjoy the products they purchased beyond their initial limitations. The proprietary software graveyard does not have to exist, but it does exist, and continues to grow because of the senseless selfishness and blindness of a few ignorant software corporations.
Now that The SCO Group’s Linux lawsuit has been gutted due to a ruling that says Novell owns the Unix copyrights, I bet the companies that paid protection money to SCO for proprietary Linux licenses and Unix rights (Sun Microsystems, EV1Servers) have that “I’ve been robbed” feeling right now.
The first and only name that comes to mind when considering the topic of buying SCO’s Linux licenses is EV1Servers. Here’s the official SCO press release on the matter. In short, EV1Servers bought Linux licenses for its Linux servers. The immediate reaction from EV1’s clients was disgust, and several of them cancelled their hosting agreements and moved to other service providers. The EV1Servers CEO, Robert Marsh, publicly regretted the deal soon after he finalized it, though it’s likely that he was more concerned with losing customers than with saying no to SCO’s baseless request for license fees.
If SCO did not own the Unix copyrights and there was no Unix code in Linux, then is EV1Servers entitled to a refund? Sadly, no, because the license agreement stated that refunds are no possible under any conditions — including the possibility that SCO doesn’t own any code in Linux. That wouldn’t necessarily stop EV1 from suing to get their money back, being that the deal was made under false pretenses, but somehow I doubt Robert Marsh will pursue it.
A few years ago I interviewed Scott McNealy, then-CEO of Sun Microsystems, at the Solaris 10 launch event in San Francisco. Though the article I wrote was long and covered many subjects, here’s a passage from it that is relevant to today’s discussion:
“What proprietary code had to be taken out of Solaris in preparation for open sourcing it?” McNealy responded by saying that the process of open sourcing Solaris actually started five years ago. “There were hundreds of encumbrances to open sourcing Solaris. Some of them we had to buy out, others we had to eliminate. We had to pay SCO more money so we could open the code — I couldn’t say anything about that at the time, but now I can tell you that we paid them that license fee to expand our rights to the code,” he said, referring to the February 2003 multimillion-dollar purchase of expanded Unix SVR4 license rights from the SCO Group.
If SCO did not own the Unix copyrights, then what did Sun pay for? Will Sun get its money back from SCO, and then pay it to Novell for the same rights? What will become of Solaris if it contains code that was licensed under the OpenSolaris CDDL when in fact it actually belongs to Novell?
The longer the SCO debacle continues, the more of a mess it becomes.
