The Open Source Commandments: 2012 Edition

Editor's Note: The original version of this article was published in 2008.

This weekend, the Passover again falls upon us. For those of us Jews that celebrate the holiday, it is most associated with a ceremonial meal spent with family, where we recite the story passed down to us over hundreds of generations from Maxwell House haggadahs chronicling the exodus from Egypt as slaves of the Pharaoh.

Personally, I find the entire experience somewhat draining, because if you really do it the way its supposed to be done, it takes at least ninety minutes to read through before you even get to the Matzo Balls, grandma’s brisket and the Potato Kugel (Click for my favorite recipes) and then you have at least another hour of group reading to go.

To add insult to injury, you get to finish the entire anxiety-inducing trial of patience by watching hyperactive children (who have been sitting still for over 3 hours) unleash their pent up energy.

I look forward to these ADHD tykes race around the house for twenty minutes, smashing everything in their path trying to find two broken pieces of stale unleavened edible sheet rock so they can ransom a ten (is it still ten these days? A Franklin with the current currency devaluation perhaps?) dollar bill from grandpa.

The Joyva Jelly Rings, Manischewitz macaroons, flourless chocolate cake and the ensuing heartburn from a schmaltz-laden meal are but a small parting consolation prize for the voluntary mental exhaustion.

• Also Read: Why the next version of Android will not be called Kugel

My favorite part of Passover, however, is the mandatory re-watching the classic 1956 academy award-winning film, Cecil B. DeMille’s The Ten Commandments starring Charlton Heston as Moses and Yul Brynner as the Pharaoh Rameses.

The special effects and the miniatures and sets on this movie would cost hundreds of millions of dollars to produce today, and it just wouldn’t be the same done in CGI and with “new school” Hollywood actors.

My favorite scene in that movie is when Moses goes up to Mt. Sinai and receives the tablets from the Lord, which are inscribed with fiery balls shot by the finger of the Almighty, Blessed be He. Publishing on demand! Cool.

While I would hardly classify myself as a monotheistic deity on the level of the God of Abraham or even worthy of making statements of such cultural magnitude upon high, I would like to take this opportunity, perhaps, as we approach the Passover season, to make some suggestions for Commandments that future generations of technologists and technology companies wishing to pursue Open Source community activities might want to follow.

Thou Shalt Not Be An Aggressive Monopolist

Back in 2008, when I wrote the original version of this piece, Microsoft certainly got the smiting it deserved from the European Union for its monopolistic practices, to the tune of over 2.6 billion dollars in accumulated fines.

Single vendor leadership position and domination of key markets in any industry are very frequently unavoidable, by virtue of a company’s expertise and duration they’ve been in business, as well as external economic factors which cause industry consolidation.

Examples of this include AT&T in the telecommunications industry (a case of where a monopoly was broken and re-integrated itself through the act of industry consolidation due to economic forces 20 years later) and IBM establishing itself as the dominant provider of mainframe computers despite the existence of several competitors, such as UNIVAC/Sperry/Burroughs.

UNIVAC eventually merged and found the government contracting business more profitable than selling hardware — and became the service-oriented Unisys in 1986 (although they still maintain their ClearPath business for customers who still need it).

• Also Read: A Look Back at UNIVAC and the birth of the computer industry

Nevertheless, strong-arm and lock-in tactics such as those used in the past by Microsoft -- and now employed by companies like Apple and Oracle (which are waging war with their competitors via the weaponization of patents) are most certainly one of the least effective ways of preserving your business model long term.

Continuing to show industry leadership is one thing, but do not attempt to squash the little guy or other players in the process, because then the community will just plain hate you. If your product is good, it will stand on its own merits, although a hundred million dollars per year worth of marketing never hurts.

Thou Shalt Not Keep Thy Protocols and Systems Closed

It took the fourth plague of EU fines in February of 2008 to make Microsoft see the error of its ways and to force it to cooperate with projects such as SAMBA and open its networking protocols so that Linux and other UNIX-like OSes could have perfect compatibility with Microsoft’s CIFS/SMB implementation and directory services.

Much like good old Pharaoh, they finally said Uncle, and gave up the specs before the inevitable slaying of the first born, which would have been the next logical step.

Microsoft is hardly the sole practitioner of closed protocols and APIs, although traditionally they get the lion’s share of scorn in this area.

The Insanely Great Apple has many undocumented API calls into iOS, which in the past has made application development for the platform a clever exercise in reverse engineering, and anyone even trying to play in that space has found their App removed from the App Store.

You want to try to hook a non-Apple device into iTunes or iCloud? Fuhgedaboudit.

And as much as Google can play cool about being Open Source with Android, the company made some seriously strategic blunders last year by keeping Honeycomb, version 3 of Android closed source. That's one way to really tick off your developer fan base, by reneging on your promises.

Google eventually came around and released Ice Cream Sandwich, version 4.0 into the Android Open Source Project (AOSP) but let's hope that what happened with Honeycomb was just a bump in the road and it won't happen again.

Thou Shalt not Proliferate Useless Licenses

Microsoft has its own useless Shared Source license, but they are hardly the worst offender in this area because they have the least amount of Open Source software currently in the wild. And the company has changed its tune considerably in the last several years, particularly by making significant contributions to the Linux kernel to make the Open-Source OS a first-class citizen on their Hyper-V virtualization platform.

• Also Read: Who helps make Linux? Microsoft.

Given the fact there are now over 50 OSI-compliant licenses, it makes no sense at all to complicate the ecosystem any further, particularly if it is incompatible with the major licenses in use - (L)GPL(2)(3), Mozilla, Apache, Xorg, BSD, et cetera.

If anything, we should aspire to eliminate vanity Open Source licenses.

When this article was originally written, Sun released Java into GPL2 as the OpenJDK, and it was one of the last great acts before the failing company was absorbed by Oracle.

However, it received ten plagues of frogs and wild beasts because of the utter GPL-incompatible train wreck that was the CDDL that OpenSolaris used to be licensed under.

This was perceived as particularly obnoxious by the Open Source community not just because OpenSolaris incorporated many GPL-compatible projects into its distribution, such as GNOME and Xorg, but it was also impossible for projects such as Linux to incorporate Solaris CDDL code.

As it turned out, OpenSolaris was nuked by Oracle after Sun was acquired. Had OpenSolaris been GPLed, that OS might still have had a future in the Open Source community today. The independent Illumos Project is trying hard to keep it alive, but they haven't made a ton of progress getting community buy-in.

All take and no give Open Source licenses suck. So sayeth the Almighty.

Thou Shalt not Threaten Open Source Software Vendors, Projects and End-Users

While this could be incorporated into the first commandment, as most of the saber recent rattling in this area has been attributable to Microsoft, they are not the only company to have done this.

SCOwas actually been a much more flagrant violator of this commandment than Microsoft had ever been, by sending extortion letters and filing lawsuits to end users of Linux distributions for violating their supposed (and now since fully dismissed claims of) intellectual property rights.

If you want to make nice with the Open Source community — or any large group of potential customers for that matter, threats and litigiousness are never a particularly good ways of going about it.

• Also Read: Ten Catastrophes, All-Time Worst Tech Industry Executive Decisions

You might end up with pestilence, darkness, fire and brimstone — or in SCO’s case — bankruptcy and complete insolvency.

[The Commandments Continue: Contributions from the Passover Penguins]»

After eating the heavy meal and unbuckling our belts to make room for dessert, much like during the American secular holiday of Thanksgiving, we often discuss the affairs of the day, and how they pertain to our identity and future as Jews.

If we were to imagine that Tux and his family were enjoying a Passover Seder, what issues would they discuss?

The Exodus from Windows and the Linux desktop to Post-PC and Tablet Computing? The Cloud? Feature set enhancements for Kernel 4.0? Android Version 5? Open webOS?

Or maybe Mark ShuttleworthorLinus Torvalds for President in 2016?

While all of these are valid topics, I decided that we should try to finish the Open Source Commandments, based on reader feedback.

Thou Shalt Finish Thy Code and Not Leave Thy People with a Plague of Bugs

“Thou shalt not abandon thy project once it is past the fun stage… Thou shalt reject the false projects of thine WoW guild and fix thine bug-plagued code. Thou shalt not whine when no one else volunteers to help”.

I have to say, this is one that really stuck out. One of the biggest criticisms of Open Source software is the huge amount of abandonware compared to the number of active projects.

Of SourceForge.net’s300,000+ registered projects, a very large number of these are inactive or single-user compared to those that are continuously developed or successful multi-developer projects. Much of the same can also be said for projects hosted at Google Code as well.

On Freecode, a popular Open Source binary download site, a great deal of projects have been pruned and many are also inactive, reflecting its nearly 5,000 pages of total projects listed.

If you’re going to produce an Open Source piece of software, be committed to developing it, and do not abandon it and your users the second real life starts to interfere. You should plan for a backup strategy to continue maintenance and development if you cannot continue to do it yourself.

Thou Shalt Write Good Open Source Documentation

"I love open source and use it for almost everything. I run multiple systems with every major Linux BSD, and whatever else is worth research. But I am very perturbed at the way that OSS designers fail to document things properly. PLEASE write documentation that starts from the beginning. I hate OSS that insists on an intimate relationship with my computers before they have properly introduced themselves! Please, start all docs by explaining in plain English what the OSS is about and what it does."

Amen,my dear follower, thousayeth the truth. but I think this is true of many programming and software projects, not just Open Source ones.

Document, Document, Document. I don’t care if you do it in comment files, PDFs, Word, AODF, OOXML, ASCII, EBCDIC, Vellum or Papyrus, but write it all down, even if your writing skills suck. I know that this could be challenging in and of itself for a geek, but find a girlfriend, boyfriend or a spouse (I found this to be a particularly good justification for marriage) to edit your materials if necessary.

Thou Shalt Offer a GUI

"The causal user should never be forced to use the command-line for anything."

While the console shell is one of the most powerful interfaces in existence for people who know how to utilize it properly, I have to agree that if you are going to produce an end-user application, it should not require use of the console.

There are so many great console utilities out there that could easily be automated or controlled with a simple pyGTK or TCL/TK GUI.

If you want to see how console can be enhanced with a nice GUI, Microsoft actually has some cool stuff in store with the ISE in the next version ofPowerShell which is forthcoming in Windows 8, which comes pre-loaded with over 2000 "commandlets" and has context-sensitive help.

I know it’s beneath you hardcore console minimalists, but if you want to see your software get used, offer at least a basic GUI to front-end it. Get someone else to write it if you hate GUIs that much. It’s no secret that programmers can often be bribed with pizza and Chinese food (manna) to produce quality results.

He Who Professes To Be a Friend of Open Source Shalt Liveth the Lifestyle

This is one of the biggest problems I have with companies that profess to be embracing or participating in “Open Source” and yet fall short of how an Open Source practitioner should behave. They have to engage themselves with the community and not just throw their code to the wind, they have to release often and incorporate external participation, and they have to be able to produce the source code when asked for.

I can’t tell you how often I see companies that embark on Linux or Open Source projects absolutely blow it on these very simple things. A good friend of mine, QT/KDE programmer extraordinaire Benjamin Meyer, has published a list of Commandments of his own for how to best manage Open Source projects. I suggest you give it a nice read.

I think we’re up to 8 Commandments now. What shall the final two be? It’s time for coffee, jelly rings and macaroons. Yea, verily, speaketh thy mind upon this virtual papyrus.