The Open Road

For all the billions enterprises spend on IT each year, they arguably get far inferior software than Facebook, Twitter, Google, and other consumer Web companies make available for free. In part, the consumer Web can deliver exceptional value for so little because it piggybacks on the expensive infrastructure built by others.

Is it time for enterprise software to "pull a Google" and build solutions on the consumer Web?

It may sound preposterous, but consider just how good the software you use at work is compared to the software you use at home. It's not even close. The consumer Web wins every single time.

For those who think there must be some trade-off in software quality when brown-bagging with the consumer Web instead of using white-glove dining with expensive SAP or Oracle, they're right. There is.

But the trade-off favors consumer-facing applications, as Alfresco CTO and co-founder (and my colleague) John Newton highlights:

The whole idea of enterprise software in the 21st century seems anachronistic. The term enterprise really only took hold in the 90s in order to describe systems that were able to scale beyond the department. It meant big, powerful, flexible, but it also meant big, clunky, and expensive.

As Web 2.0 sites with their cheap (read free), simple, but scalable platforms scaled to millions of users in a matter of months, the whole idea of only being able to support thousands of users and take years to implement became ludicrous. Being enterprise--meaning you can support your heavyweight infrastructure of other enterprise parts--also seems less interesting when you consider that the largest databases on the planet run on MySQL using a concept called "Sharding."

Sure, there are problems with the consumer Web. ZDNet, for example, points out that Twitter's security model isn't fully formed yet, and could introduce security breaches into enterprise software that leverages it.

But let's not kid ourselves that enterprises aren't already at risk--and, perhaps, equally at risk--from the "secure, enterprise-grade" software they shell out thousands or millions of dollars for every year.

And let's also not pretend that enterprise workers are going to ignore the sleek, highly usable consumer Web in favor of the clunky systems IT foists upon them. They're not.

Nor should they. I already find myself communicating with colleagues, customers, and partners over Facebook and Twitter, and I imagine you are, too. It's simply more efficient that way.

Rather than fight this, IBM et al. should build applications on top of the consumer Web. Or maybe a security overlay is all that's needed. Something that secures the communication endpoints while leaving employees free to interact with their peers at other companies using the consumer Web.

Novell is doing this with its Pulse service for Google Wave, a testament to just how innovative software can be when it isn't locked behind a firewall by IT. Others should follow suit, and not create clones of the consumer Web as Tibco has with its Twitter clone, Tibbr.

Web 2.0 Journal notes six megatrends affecting enterprise IT, including now-familiar themes like open-source development and cloud computing. The consumer Web should be there, too. It may well be the future of enterprise software. And perhaps it should be.

Today's cloud-computing vendors focus on infrastructure, but that won't be the case for long. It can't be. As competing vendors seek to differentiate themselves, they're going to move "up the stack" into applications.

It's like the history of enterprise computing, played out in months and years instead of decades.

Oracle arguably set this strategy in motion when it acquired its way to a complete infrastructure-plus-applications portfolio to lower customer acquisition costs and improve its competitive differentiation for CIOs. IBM and Microsoft also went that route, though to differing degrees and in different ways.

Cloud-computing platform vendors are going to have to do the same thing, except they don't have the luxury of waiting.

It's not enough for cloud vendors to build the infrastructure and pray, "Field of Dreams" style, that customers will come. They won't. Not without applications and a host of other issues worked out for them, not by them.

Even Google, born in the cloud, recognizes this. Instead of forcing government customers into its public cloud, the company is building a dedicated cloud for government organizations in the U.S. Google's reasoning?

We also want to do our part to make it easier for government to transition to cloud computing. We recognize that government agencies have unique regulatory and compliance requirements for IT systems, and cloud computing is no exception. So we've invested a lot of time in understanding government's needs and how they relate to cloud computing. To help meet those requirements we're taking two important steps....

One step is certification, and the other is dedicated hosting. As much as Google may hope that its other prospective Google Apps customers won't have "unique...requirements," they do (or think they do). it's a losing battle to tell them otherwise, at least in the short term. If an enterprise giant like GE demands a private cloud, GE is going to get it.

This same pragmatism will drive Google and other cloud-infrastructure providers to build out their application suites. Why? Because enterprises that move to the cloud expect to see applications follow them there. Today, however, most enterprise applications don't work well in the cloud, leaving would-be enterprises buyers all dressed up with nowhere to go, in terms of the ability to run desired applications.

Vendors are jockeying to satisfy this demand for cloud-based applications. Google is already well on its way with Gmail and the rest of its Apps, and has been in the market lately for more, but others like Cisco, Microsoft, VMware, and IBM will be jumping into the M&A market to round out their offerings in order to deliver increasingly full application suites.

Microsoft has been actively courting developers to build cloud-ready applications for its Azure platform, while VMware bought into the Spring developer community for the same purpose. But in the winner-takes-most cloud platform war, the best short-term strategy is to provide applications, and not simply hope they get built.

Perhaps this is one reason IBM CEO Sam Palmisano claims to be undisturbed by Google's rise. IBM already has Lotus and more running in the cloud, and has a strong hold on enterprise wallets.

Microsoft is arguably best positioned in such a battle [as]...it has the applications...that enterprises already use. What it doesn't have, at least, not yet, is experience running these applications in significant cloud deployments. But that will come.

Some, like Red Hat or Amazon, may elect to sit it out and stick to their infrastructure-only guns, but such vows of paucity won't help potential service provider customers, and threaten to position them out of the longer-term battle for enterprise customers. Amazon can afford to refrain from seeking enterprise customers; Red Hat can't.

Microsoft is arguably best positioned in such a battle, at least from a portfolio perspective. After all, it has the applications--e.g., Exchange/Outlook, SharePoint, Office--that enterprises already use. What it doesn't have, at least, not yet, is experience running these applications in significant cloud deployments. But that will come.

Until it does, expect the big cloud-infrastructure vendors to buy competitive application offerings so as to distinguish their platforms to hosting and service providers. Sure, they can sell hosted Exchange, but that's a recipe for entrenching Microsoft in the cloud, just as happened on the "desktop" and server. Cisco et al. don't have much appetite for reliving Microsoft's glory.

Who are the likely targets? Zoho just became belle of the ball, of course, but there are others. I'd expect any application with either a significant following, like Acquia's Drupal, or significant cloud/hosting experience, like SugarCRM (Disclosure: I am an adviser to SugarCRM), to be up for grabs.

Follow me on Twitter @mjasay.

Canonical, creator of the Ubuntu Linux distribution, has taken its share of criticism for not being innovative enough for some in the Linux community. In 2010, however, Canonical's focus on design and packaging will come to be seen as a seriously shrewd strategy as it helps to take Linux to the masses.

The reason? The innovation that pays is changing, and UI matters more and more.

When we think of innovation, we normally think of traditional research and development (R&D), complete with a white-coated scientist or pizza-gobbling engineer.

As Apple, Google, and other highly successful software companies demonstrate, however, today's innovation opportunities may lie more in user interface than traditional R&D. Google's emissary to the start-up world, Don Dodge, hints at this in a discussion of the various email systems he has used:

[O]ver my career, my first email thing was Vax Mail, which was awesome at the time, it was revolutionary. I went from Vax Mail, to Outlook, to Lotus Notes when I was working for Ray Ozzie, then back to Outlook again, and now Gmail. Email is a pretty straightforward application. They have basically the same features, it's all a question of user interface.

Sure, there are differences under the hood between Google's Gmail and Microsoft's Outlook, but the innovation that matters most today may well be the "superficial" e-mail experience that these different systems offer.

Back to Canonical and Ubuntu.

Canonical's founder, Mark Shuttleworth, understands that innovation is shifting from core research to the user experience, as he's opined on his blog. He has set his sights high, not content to replicate the Windows PC or Mac experience, for example, but has instead insisted on surpassing it.

The money for Canonical is in packaging open-source technology, not necessarily in creating the technology in the first place. The Linux world should be grateful, given Red Hat's and Novell's focus on the data center.

Linux benefits when mainstream users buy into it. Or, rather, when they use it without thinking about "it."

No one cares that their TiVo devices runs Linux. It just does. No one cares that the Kindle runs Linux, either. They care about the functionality these devices deliver. That's the way it should be.

Canonical's opportunity is to make Linux so easy that it becomes completely invisible to the end user. And Canonical may well be the best positioned to do this, among its open-source peers.

Neither Red Hat nor Novell employs an executive to focus on consumer products. Canonical does. No other open-source company has had its CEO discard the executive mantle to "focus [his] Canonical energy on product design," as Canonical recently did.

Hence, perhaps no other open-source vendor is better positioned to capitalize on the rising (and changing) Netbook market or other open-source friendly consumer markets.

Red Hat dominates the enterprise Linux market. Let it.

Canonical could well be set to dominate the consumer Linux market, a potentially massive market that demands a single-minded focus on design. It's a big bet, but one that Shuttleworth is committed to making.

Open source has long been an important development methodology. The biggest surprise of 2009, however, was just how quickly it took center stage as a business strategy in the larger software economy.

The reason? Google.

It's not as if open source as a business strategy is anything new. After all, the industry has been chattering about the business benefits of open source for nearly 10 years.

But not on Google scale. And not with the cachet and brand of Google blessing the idea. Despite the impressive sales and profits that Red Hat and other traditional open-source companies consistently deliver, the industry needed Google to take open source out of the realm of geekdom and into the boardroom.

Even Google needed Google. The Mountain View software and advertising giant has been involved with open source for years, running its Summer of Code and hiring up the best and brightest open-source developers, like Guido van Rossum and Greg Stein.

In 2008, however, Google stopped treating open source like a cute science project and source of cheap raw materials to power its search business, and instead started to actively court developers.

Open source stopped being a sideshow for Google and instead became the main event.

The developers were needed to create a groundswell of support for Google products like Android, and to dismantle the house that Bill Gates and Steve Ballmer built.

It's working. In fact, I suspect it's working far better than even Google suspected it would. It's certainly working at a scale that I never imagined we'd see in 2009.

All of which makes me think that 2010 will be the year that the rest of the industry follows Google's lead and starts to use open source as a fundamental business strategy, and not simply a plaything to placate "the community."

So, instead of Microsoft experimenting with fringe products like its open-source CMS Oxite, perhaps we'll see Microsoft open source an ad server (or acquire OpenX?) in an attempt to open-source Google's core, just as Google has been opening up Android, Chrome OS, and other products that undermine Microsoft's profit centers.

Perhaps we'll see SAP open-source software that kidney punches Oracle, while Oracle finally gets its way with MySQL and uses it to sucker-punch Microsoft's SQL Server.

And so on.

The big surprise of 2009 was how open source stepped up its game to become Google's primary business strategy, and not simply a sideshow developer strategy. The big news of 2010 will be how quickly other technology vendors will follow its lead, making 2010 the year of mountains of new, open-source code...and a hugely entertaining spectacle.

Google loves Apache.

Lost in the flutter over Google's hymn to openness is an intriguing factoid on open-source licensing:

Though many of the programs hosted on Google Code are licensed under the GNU General Public License (GPL), when Google wants to open-source its software, it turns to the Apache Software License version 2.0.

Why?

Google's Jonathan Rosenberg elucidates:

When we open source our code we use standard, open Apache 2.0 licensing, which means we don't control the code. Others can take our open source code, modify it, close it up and ship it as their own. Android is a classic example of this....

Control. Apache is a signal that a company is prepared to fully remove its hands from a software project's steering wheel. The GNU General Public License (GPL), a more widely used open-source license, tells a different story.

Glyn Moody correctly articulates that "the GNU GPL gives a disproportionate advantage to the company that owns the copyright." Bingo.

In fact, as I wrote back in 2006, the GPL is the closest thing to traditional copyright ever devised in open-source licensing:

Please keep in mind that the supposed paragon of software freedom [GPL] is also the license that most tightly imposes a distinct lack of freedom on downstream users. If you're a capitalist like me, you probably like this fact. But if you're a software developer...?

Google, at the top of its game (and with its profits firmly secured by a very proprietary revenue stream), doesn't need to constrain its development community with the GPL. Indeed, doing so would be counterproductive, given the persistent privacy concerns that hover over its every action.

Google needs to demonstrate a lack of control. Apache helps it do so.

This shouldn't be underestimated. Microsoft, having lived on the regulator's rack for so long, may be anxious to ensure Google gets to know U.S. and European regulators, too. Apache licensing could help.

Apache licensing is one of the cards played by MySQL co-founder Monty Widenius with European regulators recently: Apache puts original developers and downstream developers on equal footing, so why not keep Oracle from snuffing out MySQL's life by relicensing it under Apache instead of the GPL?

It was a jaundiced card for Widenius to play, but it would be a decent card for Google to play against claims that it's too dominant. (Competition is "just a click (or a fork) away....)

Rosenberg writes that because of Google's open-source licensing, "others can use our software as a base for their own products if we fail to innovate adequately." True. Google is clearly betting on its ability to innovate fast, which is incidentally also the very thing that makes the prospect of seeing its code forked so remote.

Even if competitors are technically and legally capable of taking Google's code and using it to create competing products, the truth is that it's very hard to fork fast-moving code, especially if you're not an active contributor to that code. Google understands this. It's the savviest open-source company around.

Ubuntu has led the Linux community's efforts to improve on form, not simply function, and thereby make the Linux experience as good or better than Mac OS X in terms of usability. Mark Shuttleworth, founder and CEO of Canonical, the company set up to shepherd development and commercialization of Ubuntu, is the heart of that effort.

As announced on Thursday, however, Shuttleworth is resigning as Canonical CEO to focus on improving the Ubuntu user experience:

From March next year, I'll focus my Canonical energy on product design, partnerships and customers. Those are the areas that I enjoy most and also the areas where I can best shape the impact we have on open source and the technology market.

Is this good or bad for Ubuntu? And what about Canonical?

Canonical is reportedly doing $30 million per year in sales, and is working on some significant projects that may establish it as the de facto Linux distribution for Netbooks, if it isn't already. (Ubuntu is arguably the community choice for personal computers.)

Even so, Linux still has a long way to go to match the user experience of Mac OS X, or even Windows. Shuttleworth has given me a sneak peak of his vision for where Ubuntu can go from a UI perspective.

I was blown away. This is a man who "gets it."

Even so, he and the Ubuntu community still have a ways to go to match Microsoft or Apple in user experience, and certainly in market share. To get there, Ubuntu needs Canonical, and Canonical needs Shuttleworth fixated on improving Ubuntu's user experience.

When I asked what his resignation as CEO means for Ubuntu, and his involvement with it, Shuttleworth responded:

I don't expect to be less visible, just have stronger management for the business units.

As reported by CNET and as reported on Canonical's corporate blog, Jane Silber, currently Canonical's COO, will replace Shuttleworth as CEO. A search for a new COO will commence in the first few months of 2010.

This, I believe, is an opportunity for Canonical to tighten its focus. While Shuttleworth suggests that Silber's appointment "doesn't mark a change of direction," perhaps it should. With over 300 employees and products that span mobile, Netbooks and other personal computers, cloud computing, enterprise servers, and more, Canonical has its fingers in a lot of pots.

It's possible that the operations-minded Silber may channel Ubuntu's ambition into a few products where Ubuntu can dominate.

When I asked her for comment, Silber indicated that the move is more evolutionary than revolutionary:

This move should not be read as a precursor to a paring back in markets or as a dramatic shift in strategy. We continue to be committed to making Ubuntu the best possible platform, and to ensuring that Canonical provides high quality engineering, online and professional services to Ubuntu partners and customers worldwide....

I will still bring an operations discipline to company, but I will assume more responsibility and authority for the overall performance of the company including, I expect, greater participation in executive level sales and business development.

That involvement--i.e., working with customers and hearing them demand focus and discipline--may well prod Silber to instigate the changes she initially has disavowed.

Red Hat is instructive. Though many of us would like to see it broaden its focus, the company remains rooted in the enterprise server and middleware markets. Canonical, in my view, should take a lesson from Red Hat and channel some of its energy into fewer markets, markets where it can thrive.

Regardless of what happens, stay tuned to see how Shuttleworth's design aesthetic, now set to overdrive, can impact the cozy duopolies in "desktop" (Apple and Microsoft), servers (Red Hat and Microsoft), and more. With more time to focus on what customers and partners want, Canonical and Ubuntu may be set to take a more commanding position in the market.

Google is perhaps the world's largest open-source company. That does not, however, make it the most open. Not even if Google says it's so.

The company is fond of believing itself different. And perhaps it is. For all of its stumbles over privacy concerns, it's still the company that insists it will "not be evil." I give its executives the benefit of the doubt that it really does want to be open, as revealed in a blog published Monday by Senior Vice President Jonathan Rosenberg.

But the irony of Google's position is that it's very open...until it needs to make a buck. Or a billion of them. At that point it's just as closed as its competitors. Perhaps more so.

Rosenberg doesn't shy away from the inconsistency, arguing that Google is closed when it's for its customers' own good:

While we are committed to opening the code for our developer tools, not all Google products are open source. Our goal is to keep the Internet open, which promotes choice and competition and keeps users and developers from getting locked in. In many cases, most notably our search and ads products, opening up the code would not contribute to these goals and would actually hurt users. The search and advertising markets are already highly competitive with very low switching costs, so users and advertisers already have plenty of choice and are not locked in. Not to mention the fact that opening up these systems would allow people to "game" our algorithms to manipulate search and ads quality rankings, reducing our quality for everyone.

Am I the only one that just had Napoleon of "Animal Farm" flash through their minds while reading that statement? Some animals are more equal than others, and some companies know better than others when to keep code closed.

It's not that Rosenberg is wrong. It's just that his embarrassment at admitting Google likes the revenue that results from closed systems ties his arguments up in knots, as Gartner's Brian Prentice highlights:

I don't think Rosenberg is making any attempt to mislead. I think he's thinking out loud and trying to reconcile the paradox he's created for himself--that open systems win even though Google's success is so clearly the result of being strategically closed.

Prentice adds further color:

The truth is that closed systems still win. Open systems, practically speaking, are basically good for making others lose.

The art of business in the 21st century is figuring out how to open up your suppliers' and competitors' business while keeping yours tightly sealed. And in that endeavor Google has proven highly successful.

From Red Hat to Facebook, from Google to Microsoft, from MySQL to Oracle, the same lesson applies: openness is exceptional for creating developer interest, lead generation, and many other things, but some element of proprietary still pays the bills. The big ones, anyway.

No exceptions.

Google is a fantastic company that groks the strategic benefits of openness better than most, and certainly better than its lumbering counterpart in Redmond.

But it's not exceptional in understanding open on-ramps and closed exits. Other important businesses like IBM have been leveraging such principles for years (even before Hewlett-Packard's Martin Fink explained the strategy in "The Business and Economics of Linux and Open Source").

Google isn't original with the business strategy. It's just better at it than most. It's open...until closed takes over to pay the bills.

Follow me on Twitter @mjasay.

Whether you're an enterprise or a consumer, ultimately your big concern in buying technology is "Will it do what I want it to do?" Sometimes components matter, but most people most of the time just want something that works.

Gartner's consistently engaging Brian Prentice suggests this is already happening with open-source software. Vendors care about it because open source gives them high-quality, low-cost components with which to build solutions for customers. Customers may notice the lower price tag, but they don't invest much thought into why the price is lower.

I'm going to assume that at some point over the last 20 years you bought a car. So, how important was the car maker's use of just-in-time manufacturing to your purchase decision? I'm going to go out on a limb here and say it was of no consideration at all.

Well, I think we're fast approaching the point where open source to software will be like JIT to automotive manufacturing. While it will critical to the producers of software, woven into the fabric of its operations, it will be of no importance at the point of consumption.

As hard as this might be to accept, open source is not a value proposition in its own right.

As hinted above, this is mostly true. Customers do care about the things that open source offers (lower cost, higher quality, etc.). But they probably don't recognize (or care) that these benefits stem from open source, per se.

Consider the Web. Open-source software provides the fundamental building blocks for nearly all Web services like Facebook, Amazon, etc., not to mention the infrastructure for public and private clouds.

End customers aren't asking for open source on the Web or in the cloud. They're asking for well-managed services that solve their problems. It's the vendors who care, because it allows them to grow highly scalable businesses at a modest cost.

Indeed, many of the customer benefits of open source (i.e., the ability to view, modify, and redistribute code) disappear or get muted on the Web and in the cloud. This hasn't stopped customers from buying into the Web/cloud.

Red Hat may disagree. It's apparently betting that customers care about components in the cloud. Why else would Red Hat Enterprise Linux pricing be much more expensive than Windows on Amazon EC2, despite being much cheaper for on-premises deployments, as IBM's Savio Rodrigues finds?

But I suspect Red Hat will need to change its pricing, as the OS is even more commoditized in the cloud than it has been for on-premises deployments. Both Red Hat and Microsoft will race to the bottom in pricing, with the emphasis being on the applications that run on them.

After all, this is the thing that drives customers' purchasing decisions. Red Hat knows this, which is why it (rightly) makes a big deal of the huge ecosystem of applications that run on RHEL.

In the cloud, even more attention is focused on service that customers use. Open source, in such a world, is essential infrastructure, but it's infrastructure that every vendor shares or will soon share, making the battle all about end-user facing applications, and not about developer-facing open-source components.

This is a very good thing. It means we can get back to focusing on solving customer problems, rather than fetishing and battling over open-source licenses. It's about time.

Editors' note: This is a guest column. See John Mark Walker's bio below.

Quick, what were you doing on December 9, 1999? If you actually remember, then there's a good chance that you're an old-school Linux type. If you don't have any idea, then read on, and you'll discover what you missed.

I'll never forget where I was--at ground zero of the apex of dot-com ridiculousness. While I and all of my co-workers were in the office that day, about the only thing we accomplished was writing 15 gazillion Perl-based variations on the theme of stock tickers that displayed the price of LNUX, updated at regular intervals. Well, that and drinking champagne. Words cannot adequately express what it's like to look around the office and know that everyone in the building is a newly minted millionaire--on paper, at least.

Ten years ago today, shares of LNUX, the Nasdaq symbol for VA Linux Systems, went on sale to the eagerly awaiting public. You may recall that VA Linux Systems was the company that combined Linux, open-source software, and Intel-based hardware. Just six months prior to VA's initial public offering, Red Hat Software had gone public with a very successful IPO.

We were in the middle of the open-source pixie dust revolution, when many flagging companies jumped on the open-source bandwagon in a desperate attempt to recapture past magic. It was this phenomenon that led to the general conflation of the late-1990s open-source boom with the dot-com bubble, and it would be a few years before most industry analysts, pundits, and beat reporters figured out that there was a difference.

But back to IPO day. I strolled into work sometime after 9:30 that morning and was immediately greeted by Pay, my manager, with some astounding news. We all guessed that the day would be significant, but none of us were prepared for the tsunami of blissful, surreal numbness rushing to greet us.

He showed me a sheet of paper faxed that morning from the investment bank's office (truly ground zero on that day), that was copied ad nauseum and shoved into disbelieving faces. I'll never forget what was on it: just a simple table with 2 columns. The column on the left was a list of investors, and the column on the right was the price they bid for our stock. The numbers were astronomical: $320, $250, $200, $300, $290.

Curiously, some investor didn't get the memo and bid a paltry $50. We laughed at that because it was really funny--at the time. A year later, and I would recall that lone investor for an entirely different reason: on December 8, 2000, LNUX closed the day at $8.49.

On IPO day, we could all do the math, and on that day, the math was in our favor. The official IPO price was $30, and most of us owned options on shares with a much lower strike price. We had all won the lottery, hit the jackpot, (insert gambling metaphor here). Or so we thought. What actually happened was, as Don Marti so artfully described it, we had all become players in a game none of us truly understood.

To this day, the VA Linux IPO remains the Nasdaq's most successful, in terms of its first-day gain, but what does that success really mean, in the context of events that have taken place since? At the time, the LNUX IPO was lumped in with the rest of dot-com mania and treated as the poster child for the insanity that gripped the market.

The New York Times summed up that view best with its report on the IPO, "A Tiny Company with Dim Prospects Goes Public with a Bang." (Note: the Times has since changed the headline, but we remember the original.)

You'll be unsurprised to know that we viewed things slightly differently. But as the stock price plummeted, we went from a sign of the audacity of the times to a symbol of wasted effort, a gloomy future, and everything that was wrong with the go-go '90s. We were somehow expected to repent for the misdeeds of others.

It is simply wrong to view VA Linux as a dot-com vehicle or to attach a greater symbolism to its downfall. It was really neither; it was simply the dramatic rise and fall of a company that overreached. It was a real company that made real things and believed very strongly that open source was going to be a major component of IT very soon.

That we executed poorly and paid dearly for it does not diminish the original ideas behind the company. While VA was not profitable after the IPO, it was certainly not because of revenue. In fact, revenue growth was strong, but our unrealistic growth plan--to become Dell in less than two years--did us in. Only the convenience of timing allows VA Linux Systems to be mentioned in the same breath as eToys, Pets.com or Webvan. The revenue of those was rather paltry, in comparison.

To put the VA Linux IPO in its proper context, let's rewind and remember what was going on at the time:

• Red Hat had a great IPO the summer of 1999.
• IBM had jumped into bed with Apache and had started its first big push with Linux.
• Oracle and most other major database players had released native versions for Linux.
• A year earlier, Dan Kusnetzky famously authored the famous IDC report showing explosive Linux growth of 212 percent.

And yet, in spite of these obvious signs of traction and increasing market share with real customer demand, Linux and the rest of the open-source "bandwagon" were treated like Summer of Love refuse that had never really come down from the acid hits.

Every article about Linux included (stupid, irrelevant) questions about whether it would replace Windows 98. There was a widespread belief among industry observers that open source was fueled by the dot-com bubble and would wither away when the bubble burst. Every article referenced a ragged band of hippie programmers who did it out of love or ideology and just wanted to beat the evil empire.

At that time, no one had really figured out what was driving open-source development. It's worth pointing out that we card-carrying members of "the" open-source community played our part in that perception. Who can forget the famous Windows Refund Day? And if you never smelled Richard Stallman or Eric Raymond at a conference, then you clearly missed out.

It was a heady time of uncertainty, doubt, and eternal optimism. A time of green-field bliss, of "Linux without limits," and there was no problem that a few lines of Perl (Practical Extraction and Report Language) couldn't solve. After all, "the geek shall inherit the earth." It must be true; I read it on a T-shirt.

It truly was a time of the almighty individual weaving his magic and changing the world--and if you were lucky, getting paid well for it. We were young and naive, and those of us endowed with Y chromosomes were high on testosterone. We truly believed that we were on the right side of history but were too stupid to realize our own limitations. This was a blessing and a curse.

That unyielding belief in the omnipotence of writing code gave our army the energy to slay dragons we wouldn't have otherwise, but it also gave us the chutzpah to tackle issues that we ultimately could not solve. Case in point: that time when someone who shall remain anonymous tried to rewrite our ERP system from scratch. In Perl. He didn't last very long.

As it turns out, we were right about the open-source thing, but we somehow forgot the other history lesson: the one about how being on the leading edge of something successful doesn't mean you'll enjoy all, most, or indeed, any success. Those who ultimately reaped the benefits of open-source proliferation did so because they were smarter and took a more conservative approach.

The 10th anniversary of Red Hat's IPO passed without much fanfare last summer, probably because its management is too busy running a successful company to really take the time to pause and reflect. VA Linux Systems, meanwhile, was devastated by the tech bust because those start-up companies were a significant percentage or our revenue.

VA Linux Ssytems changed its name in 2001 to VA Software, after jettisoning the hardware business entirely, and it focused on selling licenses for SourceForge Enterprise. And when that didn't work out, it became SourceForge, a collection of Web sites deriving revenue entirely from ad sales. And it has since changed its name again, to Geeknet.

For the veterans of the VA Linux IPO, we're left to ponder what might have been and savor the unreal moments, while deriving some small consolation from the fact that our instincts were right: open source was not a fad; it was just the beginning. It's not going away, and VA Linux was ahead of its time. Small consolation, indeed.