Open Source Commandments II: Passover Penguins
However, another big tradition, after eating the heavy meal and unbuckling our belts to make room for dessert, much like during the American secular holiday of Thanksgiving, we discuss the affairs of the day, and how they pertain to our identity and future as Jews. Well, 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 UNIX? Microsoft's Open Source strategy and its bid for Yahoo? Homebrew Macintoshes? Feature set enhancements for Kernel 3.0? Mark Shuttleworth for President in 2012? While all of these are valid topics, I decided that we should try to finish the Open Source Commandments, so I picked a select few from your responses and added a few new ones of my own.
Thou Shalt Clicketh on the "Read the rest of this entry" link below for more.
Thou Shalt Finish Thy Code and Not Leave Thy People with a Plague of Bugs (reader archerjoe)
"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's, 175,000+ registered projects, a very large number of these are inactive or single-user compared to those that are continuously developed or successful. On Freshmeat, Sourceforge's companion Open Source binary download site, a great deal of projects have been pruned, reflecting its 44,000 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 (reader farseas)
I love open OSS and use it for almost everything. I run multiple systems with every major Linux distro, Solaris, Nexenta OS, 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, Farseas sayeth 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. (readers tmmcorn, shryko)
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 with tmmcorn 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. 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 (Rabbi Perlow)
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.
Corporations Shalt Mentor and Not Controlleth the Source. (Rabbi Perlow)
While I've often beaten up on Sun Microsystems for their centrist, controlling strategy on how they manage their Open Source projects, they are far from the only violator in this area. Despite its early promises to create a not-for-profit Foundation for Fedora to give the distribution independence, Red Hat still continues to hold it close to the vest and continues to deny it its independence., and I believe that this is a primary reason why Ubuntu has eclipsed it as the end-user distribution of choice. And while Novell has allowed OpenSUSE to be on a comparatively longer leash, it is still very much pinned under the company's Teutonic boots. If OpenSUSE wants to grow its user base, it should "out-Fedora" the Fedora project and create an independent foundation, where Novell is a mentor and strong contributor, with representatives on its advisory board and officers in which it has significant influence, but not in a position where it can completely control its direction entirely.I think we're up to 9 Commandments now. What shall the final one be? It's time for coffee, jelly rings and macaroons. Yea, verily, speaketh thy mind upon this virtual papyrus.