The latest discussion that surrounds the question "Is the term open source dead or dying?" is interesting, but the question makes no sense to me. http://opensource.sys-con.com/read/342346.htm You might as well be asking whether the color green will become obsolete. What's often being missed in the debate, though Robert Douglass put his finger on it, is open source is an idea not a tangible thing. It exists outside of what people think of it. My iPod can die, but the music lives on. In that respect, dead or dying has no meaning in relation to open source. Once an idea hatches, it can't die.

Lately I’ve been thinking about how the open source values of choice and flexibility might be affected by enterprise uptake of open source and the evolution of open source business models.  As we talk to enterprises we find that more and more of them are following the advice of industry analysts who recommend evaluating open source on an equal footing with commercial software.  This often means that organizations are looking for the same types of services for open source that they are used to getting from commercial vendors.  They want a trusted supplier, technical support agreements with specific service levels, product updates, and indemnification, to name a few. 

As a result, commercial open source companies, including OpenLogic, are looking to provide all of these commercial-grade services that enterprises want.  There’s nothing wrong with that—that’s just the market at work to meet a need.  But not surprisingly, along the way the commercial open source vendors start to look a lot like commercial vendors.  In terms of the set of commercial-grade services you can access, getting the Red Hat Application Stack from RedHat doesn’t look much different than getting a stack of components from Microsoft.  (Note that I’m not trying comment on the relative quality or functionality of these options—I’ll leave that argument to others).  Sure, you can look at the source code with the open source solution, but the reality is that most enterprises prefer not to change the source code.

So if the commercial-grade wrapper starts to look the same, how do some of the open source benefits like choice and flexibility provide additional value to customers?  The reality is that if a particular product category has only one commercial open source option with the wrapper of commercial-grade services, then the benefit of choice and flexibility for enterprises is lost.  If you look at today’s commercial open source alternatives, there are clearly a few categories—Linux distributions, databases, CRM systems—that do provide choice among commercial-grade open source alternatives.  In other categories, the open source choices can get pretty thin.   

Maintaining choice in open source is important for several reasons:

• Different options allow enterprises to meet different business and technical needs, which can vary a great deal from company to company.
• Choice leads to competition that drives innovation in open source projects.
• Vendor lock-in, whether by traditional commercial software vendors or commercial open source companies, increases costs for enterprises.  Choice eliminates lock-in and drives down costs for the enterprise. 

At OpenLogic, we’ve adopted the mantra of choice and flexibility, and that mantra impacts the decisions we make.  For example, our library of hundreds of certified open source packages offers a wide range of choices in each product category.  Whether the need is an application framework, development tools, application servers or testing tools, the enterprise has more than one choice.  And all of those choices are wrapped with the commercial-grade services—certification, support, indemnification and maintenance—that enterprises want.  This ensures that enterprises don’t need to choose between commercial-grade and non-commercial grade open source.  Instead, the choice is between multiple commercial-grade open source options.

We hope that as open source evolves, so too will the business models continue to evolve so that open source solutions continue to offer companies the benefits of choice and flexibility.

The top-10 OSS packages (Linux, Apache, MySQL, PHP, JBoss, etc) get all the glory; everyone knows about them and they deserve the limelight, no doubt. But it's the little guys who also do some really nice stuff and come to the rescue, too. Usually, I'm looking for something ultra-cool in open source land to talk about and it's not hard to find good topics, but sometimes the tasks you need to accomplish are simply rote. Take generating an FAQ, for example. Recently, I wanted to find a package that could do a reasonable job at managing the entries of an FAQ online. This problem lives right in that area where buying something to do the job just grates on my nerves, but hand-coding the HTML for an FAQ isn't exactly what I would call a good use of my time, and it's something that ought to "just be there"(TM). [BTW - I also have the theory that all vacuum cleaners should be free. After all, you're making the world a better place by vacuuming, so you should not have to add insult to good deed by having to buy a vacuum cleaner, right? Same with FAQs.] The first problem you hit when you want to find something like this is figuring out what to call it. If you search for "FAQ manager", "FAQ management", "FAQ maker", "FAQ Software" you get FAQ's on pointy-headed bad managers, good managers, and FAQs on anything that can make something, software-related FAQs, but it's tough to find software that's a manager of FAQs. If you think "it's just content" and start down the CMS search path, you'll get buried trying to find a CMS that is light enough to deal with the lowly FAQ. I found that this genre of software is generally found under the category of a knowledge base or knowledge management. After that honed down the search space, I was still left with many options which spanned the gambit from really crude Perl scripts, abandoned projects and sites, to full-blown knowledge management systems. I haven't evaluated them all, or even a minor percentage of them, but I did find a very nice package, KnowledgebasePublisher, actively developed, that does just what I want and wanted to draw your attention to it since it might work for you, too. First, it's a great fit for shared hosted web sites since most are running the prereqs. It's a PHP/MySQL package whose database is easily installable through phpMyAdmin, a web-based MySQL database manager most shared web-hosts support. You untar the package on your web site, upload the SQL schema through phpMyAdmin, run through a simple web-based install and configure page and it's running. I think it took maybe 10 minutes to get it up and running. After that, you can set up categories, articles, upload attachments to articles and do most of the standard FAQ things you'd expect. You can also tag articles with keywords and metadata descriptions which serves two purposes. One, KnowledgebasePublisher has a built-in search functionality so once into the FAQ page, you can search for specific items. Two, the metadata keywords and description will get generated into the meta tags of the HTML when the article is expanded. Your corporate search engines might appreciate that if they pay attention to metatags. Finally, you can easily integrate it into the look and feel of your site since it's template based. You create an HTML template and slap one simple {} macro into the body where you want it, point the system to use that template, and viola, your FAQ has an embedded look. It's also got CSS files you can use to modify the look and style of the FAQ itself. There are quite a few other nice features including automatically generating RSS feeds to articles in your knowledge base, email templates, feedback and comment options, but the core of easily managing an FAQ is in this package and it's not so bloated with features (like most CMSs) it makes sense to use it just for the FAQ portion of a basic web-sites. So the next time you need to make a humble FAQ, consider the yeoman, KnowledgebasePublisher.

During my "You're a Girl!" talk I usually point out that flaming (deliberately rude emails or posts) tends to turn women and other newcomers away from open source software.  When I get asked why people flame, I usually cite a study that found that people are much more likely to be rude online than in person.  Unfortunately I could never remember what study that was nor where I read it.  Well, the New York Times came to the rescue.  Flame First, Think Later quotes several studies and says they've discovered it's the following aspects of online communication that make people more likely to flame:

• the anonymity of a Web pseudonym;
• invisibility to others;
• the time lag between sending an e-mail message and getting feedback;
• the exaggerated sense of self from being alone; and
• the lack of any online authority figure.

So I'm no longer sure who all asked the question about why people are more likely to flame and be rude online than in person, but hopefully you read my blog or the New York Times! :)

Seth Godin published an ebook under a Creative Commons license.  His intention was to make it free - he wanted people to read it and he didn't want them to have to pay for it.  Imagine his surprise when he discovered a hard copy of his book available for sale on Amazon!  Turns out the license he chose not only allows people to read his book for free but it also allows them to sell print copies on Amazon without his permission.

I see this all the time with open source projects.  They want their code to be free but they pick a license without fully understanding the consequences.  One of the most common misunderstandings we see is "public domain."  People pick a "public domain" license because they want their software to be completely unencumbered by restrictions.  However, you can't really put something in the public domain.*  The minute you typed the code into your computer, it was copyrighted.  By you.  And now that you hold the copyright you have to assign a license to it (or you will continue to hold all the rights) but you can't just disown it and put it into the public domain.  So what people do is try to pick a license that is almost like putting it into the public domain but it doesn't really work.   By picking a license that tries to emulate the public domain, you end up giving up lots of rights and people can do most anything with your software.  Somebody might end up selling your software on Amazon without your permission.  To top it all off, unlike most open source licenses with the public domain emulator licenses, you can revoke that license at any time - so people looking for open source software might not be comfortable using your software.   You are much better off picking one of the OSI licenses that more closely matches your intentions.  If you really want to give it away, try the MIT license.  If you really want your code to remain open, try the GPL. 

*One exception: software written by government employees is automatically in the public domain. 

Big Disclaimer:  I am not an attorney.  This is not legal advice.  You should consult your attorney if you need help!

BusinessWeek has an interesting slideshow, From Corner Office to Female Startup, about women who have left executive positions at large companies and started their own successful startups.  It was interesting to see what types of jobs they left and what types of companies they created.  The companies ranged from migrane medication manufacturers to Build-a-Bear.

So, I go to install the SpringIDE plugin, using the Callisto installation directions. I get part of the way through it, and receive an error, informing me that an internal error regarding the update manager's zip deflater has occurred, and it can't go on. After a bit of googling… I find this entry on Colin's blog, and follow Olivier's advice. So, I do a 'mv /usr/local/jdk1.5.0_11-64/bin/unpack22 /usr/local/jdk1.5.0_11-64/bin/unpack22.findme' (Java HotSpt 64-Bit Server VM build 1.5.0_11-b03, mixed mode running on SLED 10 by the way), try the eclipse update manager process again, and voila, it works.

Anyone who understands what's going on here and why what I did works, please tell me. I don't get it, but it went and ahead and installed what I needed, so I just moved on.

On a lighter note… I spend a good portion of my day listening to music courtesy of Pandora, which, as a side note, uses OpenLaszlo for its UI as I understand it. So, today I was listening to my Kid Rock station… a fairly interesting station in terms of how they pick which music ought to play. Interesting because it has such of wide range of music because of his style, from rappish to rockish, it has played everything from Sir Mix a Lot, to Naughty by Nature, to Beastie Boys, to Jet, to Limp Bizkit, to Saliva, to Metallica. Anyway, I'm going about my business, getting work done… and all of sudden I feel like throwing up a little in my mouth because the song is so bad. I alt+tab over to Pandora, and sure enough, I find none other than the song Lifeline… by David Hasselhoff… from the Baywatch album.

Ooph… can somebody tell me how in the world that happened? This is a case where Pandora users need more than just the 'Thumbs Down' button. We need a "Are you kidding me that you actually played this? Something slipped past QA button."

I suppose CIOs are an easy target to poke, because they sure are getting beat up over Open Source lately.

What they do get about Open Source, however, is how it's coming into their organization.  They realize that no matter what kind of mandates and policies they create to keep Open Source out, it still comes in through their developers.

First, their developers will simply download it from sourceforge.net or apache.org.  If those sites are blocked, they'll find mirror sites or use anonymous proxies.  If that doesn't work for some reason, they'll burn it to CDs at home and bring it in that way.  Or perhaps a USB thumb drive will do the trick.  If all else fails, they'll bring in a personal laptop and do all their work on it and email the results to their work computer to check into the source code control system.

In other words, the best developers will never be thwarted.  They'll quit before succumbing to rules and regulations that prevent them from getting the job done.

In my experience, it's far easy to work with them than against them.  Good CIOs understand this and try to create policies that help direct, manage, and track Open Source usage rather than threaten termination or law suits.

BTW, I know the threats don't work because we have a number of Fortune 100 customers that tried that approach only to find that the Open Source usage simply goes underground.  As soon as they brought us in to manage the Open Source and provide amnesty, they found dozens or hundreds of skunkwork projects using a myriad of Open Source components completely under the radar.

That's what should really scare CIOs: not knowing what they have in production.  It's better to shed some light on the subject so they can acquire the appopriate training and support for their people than to force them to hide in dark corners like a fleet of rebels waiting to attack at the first sign of weakness.

So in defense of good CIOs everywhere, I think they understand this.  They don't want their best developers to leave, but they also need to implement a standard of care in their enterprise.  That's why I'm talking to more of them every week.

Charles Babcock of InformationWeek recently posted on How to Tell the Open Source Winners from the Losers in which he discusses a 9-point checklist that potential users of Open Source projects should complete before making the plunge.

I like the idea of a simple checklist that can help people quickly decide whether to use a particular component.  At OpenLogic, we follow a rigorous 42-point Certification Process (registration required) that includes our version of a checklist. 

Among other things, we check the viability of each Open Source component in our library.  By "viability", I mean that we examine the project community's:

• structure
• processes
• size
• longevity
• responsiveness to basic questions
• frequency of bug fix releases
• proclivity to provide timely and helpful support
• license(s)
• documentation
• much more

I certainly agree with Charles that there's a wide variety of Open Source projects out there, many of which have little or no real community behind them.  Anybody about to adopt a new component from a community is well-advised to do a little background research first.

With dozens of alternatives available in practically every category of software, there's no reason to assume that the first one you come across or hear about from a colleague is the best one for your situation.  Spend a few hours doing your non-technical homework before committing your valuable time and energy to a project that might not be around next year.

Strata Chalup gave a talk titled "The Secret of Programming" at the Women in Open Source Mini-Conference.  Strata's talk was impressive in two ways.  It wasn't a prepared talk.  She just opened up the floor to questions - questions about anything related to open source.  (Although now that I think about it, I don't think she limited it to open source.) The two things that struck me were:

• One, people asked questions.  Questions that I think in most settings they might have been afraid of being judged as "stupid questions."  I don't know if it was the fact that the audience was almost all women, or if it was the fact that Strata was a woman or if was the way she asked the question and polled the audience.  But people asked questions from how does html really work to RSS Feeds to Wine.  (Wine as in the Windows on Linux program, not the stuff you drink!)
• The second impressive thing was that Strata answered all of the questions in a very clear way.  Even when she was corrected by the audience (by two of the very few men in the room!) she corrected her answer and proceeded to explain how the new model worked.  I was impressed.

Strata and I also exchanged "pretty cards" as she put it.  It was the first time I had run across anyone else with Moo cards.