Open source applications on the march

I remember a few years ago speculating that open source applications would never happen: not a wide enough development community with interest and aptitude in writing that kind of software. (I mention it here.) In short, I had bought into the open source myth that open source is all about hordes of developers contributing code to this project and that out of love and benevolence.

Older and wiser now....

In the past week I've learned about Coupa, an open source self-requisitioning procurement system; DimDim, an open source web conferencing solution, DabbleDB, a...well, I'm not exactly sure what it is (maybe a thneed? It does cool things with data), and a range of others.

We are now forming a world where every software product we buy will be open source. I'd say there will always be proprietary software, but I'm not sure as to why anymore. Now that the business models are firming up for open source, why would you ever care to weaken your competitive advantage by keeping code closed?

That said, this begs a larger question: what happens to open source competition once all the code is open? My bet? Product innovation will return to the fore as the primary decision driver. The difference will be that this innovation will not lock you in...it will just lock competitors out.

Making Sales While Making Friends: My OSCON2006 presentation

Earlier this week I delivered a presentation at OSCON 2006 entitled "Making Sales While Making Friends: Lessons Learned from Open Source Businesses." I've been involved with commercial open source since 1998, and have learned a lot over the years (including how to fail spectacularly and slightly more gracefully). I'm in the middle of a string of successes, though, and figured now was the time to pretend to know-it-all. You can view my OSCON 2006 presentation here. It was an extension of some JBoss analysis I did recently, as well as an attempt to pass on some of the lessons I've learned so that the next round of open source commercialization will avoid my mistakes.

My basic premise is that an open source business is hard work, and requires that entrepreneurs spend as much time thinking about the "second sale" as they do about the first sale. In the proprietary world, you sell a big upfront license and then promptly forget about the customer. In open source, however, every business model variant I've seen requires ongoing customer service to help ensure a "second sale" (i.e., renewal of an "Enterprise" license or support contract).

There is a range of ways to help secure a second sale, but the most popular of which (but still nascent) is the "network" offering. Hyperic offers the infrastructure to build such a network - others (including Red Hat, MySQL, and SugarCRM) have built their own. A network offers real value to the customer, above and beyond support, and should be on the shopping list of every open source company.

I argued that the type of sales model an open source company has should directly correlate with its market penetration...



...which is perhaps best measured by its downloads:



Regardless of the sales infrastructure (starting with inside sales, usually, and moving to direct sales over time), marketing is critical to success, because marketing improves conversion rates and builds deal size as brand value intersects with download rates:



I also suggested that startups be realistic about outside development assistance. The Sourceforge (and other) data doesn't lie: you're going to do the bulk of your core development work. You need to worry about building a user community. The development assistance will come, and it is significant, but don't wait for someone else to build your product for you. (As I've written before, some projects - like SugarCRM - see a lot of partner-assisted development. In Alfresco's case, nearly all of our outside development comes from our customers. Not sure as to the reason for the difference....)



Despite my incessant harping on Silicon Valley, I argue that you need to be where your market is, and today the paying open source market is overwhelmingly in the US (with Europe starting to catch up):



And, among other things, I revisited the idea of what it takes to make a successful open source project, commercial or otherwise:



There's more to the presentation which you can see in the download above, but this was the baseline "gist" of it. I really enjoyed giving the presentation, and expect to give a revised version at OSBC 2007. See you then/there.

Licensing issues: Of intentions and workarounds

So, the big flap today is that Linus doesn't like GPLv3 (Draft 2), as Stephen Shankland (CNET) reports. As it turns out, there's much to dislike in GPLv3. Linus just happens to not like the hardware regulations it puts forth:

GPLv3 "basically says, 'We don't want access just to your software modifications. We want access to your hardware, too,'" Torvalds said. "I don't think it's my place as a software developer to judge how hardware works around it."

Nor do I. You can feel in the GPL a desire to force people to think like Stallman (and Eben, for whom I have a huge amount of respect). That "force" is fine, albeit a little uncomfortable at times, when applied to its direct responsibility: software modifications of GPL'd software. It becomes irresponsible and overly ambitious when it extends to hardware.

This is true, in part, because it puts the FSF in the game of judging intentions. A license should never try to gauge intentions - it's ill-equipped to do so.

This same attempt is made by those who denigrate "attribution licenses" like SugarCRM's. Some cry foul because they believe the intent of the license is to make it difficult to commercially profit from Sugar's code without giving them a share. Whatever the intent (which, frankly, is probably designed simply to afford Sugar credit for the work it has done - if you're not going to contribute code or cash back to Sugar, why not at least contribute credit?), it is not the business of open source licenses to try to guess at the intentions of the software's users.

According to the Open Source Definition:

The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software.

This, to me, is the bedrock of open source. It is, in Brian Behlendorf's terms, "the right to fork." Does Sugar's license enable this right to fork? Absolutely. Is it similarly required to ensure that the modified code can make money from that software? Absolutely not. That is beyond the license. So, do I think Sugar's license is open source? You bet.

Neither the FSF nor the OSI nor anyone else should be in the business of trying to contemplate every bad intention and hedging against it. I believe OSI's open source definition shows the right way: focus on maximizing freedom, not on finding every possible way to guarantee it. A license will fail at that endeavor.

The FSF should not waste time on supposed bad intentions, but should instead invest in promoting the good ones. I thought the original GPL did an excellent job of this. It needs to stop over-engineering fixes to something that isn't fundamentally broken.

Alfresco hiring two positions - help is appreciated

A certain company I know (starts with an "A," ends with an "O," and has "lfresc" in the middle) is looking for a mid-level marcomms person, as well as a technical support person. On the latter, this company would prefer someone with a solid engineering background (in the JBoss tradition). I want someone that will know a lot of the answers to the problems customers will ask.

Thoughts? Ping me at first dot last at alfresco dot com. Doesn't matter where you're located, though Pacific Timezone would be nice.

(No more hiring announcements on this blog, I promise.)

Greenplum, Sun, and a challenge to Jonathan Schwartz

In case you missed the news, Greenplum and Sun have teamed up to deliver a monster of a business intelligence/data warehousing appliance. What's it called? Well, that's the downside: "The Data Warehouse Appliance." If you're still awake after reading the name, you'll still be blown away by the performance (and the price). Those, at least, are interesting: capable of scanning 1 terabyte of data in 60 seconds and can easily scale to hundreds of terabytes of usable database capacity (10-50X performance boost over the Terradata/etc. competition).

What will it run you? Well, you won't find it at CompUSA, but it's pretty cheap (relative to the competition) all the same. From the press release:

Initial configurations will deliver usable database capacities of 10, 40 and 100TB. Pricing for the 40TB and 100TB configurations begins at $15,000 per usable terabyte, and pricing for the 10TB configuration starts at $25,000 per usable terabyte. Ideal industries for this solution include telecommunications, financial services, retail and Internet services.

As I've written elsewhere, this isn't something that Oracle will be able to match any time soon. Its databases simply aren't set up to handle this kind of load. Greenplum is able to do it because it has the luxury of fine-tuning a PostgreSQL database to fit this need. In this way, we get to orders of magnitude price/performance benefits over the proprietary competition.

Since when is open source not about innovation and product strength?

All of which makes me wonder why Sun isn't doing more of this. That is, why isn't Sun striking up partnerships with MySQL, Alfresco, Red Hat (Yes, Red Hat), SugarCRM, JasperSoft, JBoss, etc.? Why not a campaign that says, "Open source runs fastest on Sun?"

Is there a big market for this today? Not really. Will there be tomorrow? Absolutely. The trajectories of open source's most successful companies are fantastic - revenues are doubling every year (if not more than doubling).

So why isn't Sun, which has done so much internally to support open source, doing more to highlight how well open source applications, application servers, databases, etc. run on Sun? Even Microsoft is doing this.

Jonathan?

Open source web conferencing: DimDim

I've been tracking a cool startup since Linuxworld Boston, and was glad to see them formally launch at OSCON today. DimDim is the company, and they are to WebEx and web conferencing what SugarCRM is to Salesforce.com and Alfresco is to Sharepoint (and Documentum):

An open source, value-rich competitor that should keep the proprietary competition up at night.

The product is still in alpha, but will go beta in September and production in November. I saw a demo today, and thought it was fantastic. Still some rough edges to work out, but remarkably well designed and it performed quite well. By November, I hope to cancel my WebEx account (WebEx crashes on us at least once per demo...) and move to DimDim. Frankly, my experience with WebEx has been so bad that I'll be using the alpha version of DimDim. It could still crash every other demo and be 100% better than WebEx. :-)

Under the covers, DimDim is yet another story of a successful, cohesive development team going from nada to alpha in just a few months. In their case, it took them three engineers and six months to get to a solid alpha. This is similar to Alfresco and SugarCRM, both of which had exceptionally short initial development cycles because of a strong development team that has worked together before and intelligent use of existing open source software (In DimDim's case, they leveraged open source code libraries (e.g. log4J), components (quartz scheduling component) and pre-packaged products (Helix Streaming Server)).

A few other things I like:

1. DimDim is presence aware, and will integrate all major instant messaging systems.
   
   
2. They're going for 100% transparency as a company, with code 100% open source, roadmap and technical documentation available online, etc.
   
   
3. Ajax-based web meeting console. No client-side application necessary.
   
   
4. They have the coolest logo of any of the open source companies, including my own. I'd like a T-shirt, please. :-)

Of the applications I use every day, web conferencing ranks up there as one of the top five. Email, browser, IM, VOIP, and web conferencing. It's how we interact with our customers, and how we often provide support. I'm therefore very grateful that we'll have a strong, credible open source alternative to the proprietary systems on the market.

Good work, DimDim!

Digium...the next big thing?

Tim O'Reilly just got done introducing Mark Spencer (founder, Asterisk and CEO, Digium), and called Asterisk one of the most disruptive technologies in the world today. High praise from the high priest of technology.

I couldn't help but notice an eerie similarity between Linus Torvalds (left) and Mark (right).

You know, I didn't see Linus during Mark's presentation. Could it be a new form of world domination?

Boats passing in the night: MySQL and PostgreSQL (Greenplum)

I'm listening to Scott Yara talk about Greenplum's commercialization of the PostgreSQL database, and comparing it to what Paul Weinstein (EVP, Business Development, MySQL). I had always viewed the two projects - MySQL and PostgreSQL - as direct competitors, and figured both were also competing with DB2 and Oracle. This is clearly not the case, at least, not for these two companies.

Who does MySQL compete with? With no one. Marten is on the record as saying that

We continue to have most of our deployments in areas where there was no database before. Either the application didn't use a database earlier, or the application is new. We are now seeing more and more migrations from old databases, but the majority of our installations are greenfield use.

Marten has also stated that he's not interested in competing with Oracle - his goal is not to become the cheaper, "good enough" competitor to Oracle. He's looking to be the backbone of the web - a market that isn't well suited to monolithic databases like Oracle and DB2.

Greenplum, for its part, is taking PostgreSQL and making it into a business intelligence/data warehousing workhorse. This would seem to be easier for Oracle or DB2 to compete against, but would require both to rearchitect their databases for a purpose not originally intended. In other words, it would be insanely expensive and would take a long time.

In both cases, both companies are thriving on "asymmetric competition." They're competing on their own terms, not the incumbents'.

Honest dual licensing (Fabrizio/Funambol)

Fabrizio has one of the best posts I've yet seen on open source licensing. It's one of the most candid posts I've ever seen on open source licensing (and candor is something all software companies need - open and closed).

Fabrizio traces the contours of open source licensing, honing in on dual licensing strategies. He astutely observes that a dual-license strategy works well for MySQL (or a product that is embeddable), because there the "trigger" is clear: you either pay your way out of the GPL (or similarly restrictive license) or you contribute code back. Simple.

Open source applications, as Fabrizio notes, are different. There is no obvious trigger (You'll need to read Fabrizio's post to discover the non-obvious trigger that he comes up with) for either contributing back or buying. So what do you do?

In Alfresco's case, we moved to a 100% open source model for various reasons (not the one Fabrizio suggests - the model was financially quite good to us). One was that it correlated better to our personal beliefs - I, in particularly, never liked the mixed-source message I had to say while at my previous employer. It never felt right.

Beyond this, however, there were solid development reasons for moving to a 100% open source model. We didn't need to worry about what was free and what wasn't. We just had to worry about writing the best possible software.

All of this (and other things I could say) doesn't answer Fabrizio's implicit insight: there needs to be a purchase or contribution trigger for open source applications. What is it? I have my ideas, and like Fabrizio's. Thoughts?

We can't open up because we're too monolithic (Yahoo! and Google)

Tim just finished the Ghost in the Machine: The Impact of Open Source on Web 2.0 session. It's part of the Executive Briefing that I helped Tim put together (and which, btw, is completely filled - a huge success), and proved to be insightful.

One particular thing bothered me, however. I kept hearing Jeremy from Yahoo! and Chris from Google talk about how they don't open up code because "no one would understand our code, or be able to make use of it - it's too specific to a massive web company."

Oh, really? Who is to say? Shouldn't the market decide the relevance of code? Aren't Yahoo! and Google missing the point or, rather, conveniently looking past it? Open source isn't about beneficent companies giving code to the impoverished underclass. It's about working on code collaboratively within a community.

Jeremy eventually owned up to a reason that I found much more compelling - disappointing, but compelling. Jeremy said that Yahoo's applications are tightly bound together, making it difficult to open one piece without giving away information about how the remainder is written, or making it useless because knowing 1/10th of the application wouldn't be helpful (because of all the unknown code).

All of which means, as Tim pointed out, that these companies have failed to write code according to a cardinal open source principle: modularity. Yahoo! and Google can't open source more code because their code is too tightly bound together - layer upon layer upon layer requiring layer upon layer upon layer. This doesn't mean that Yahoo! and Google are bad, but it is disappointing that they are such heavy users of open source, and have architected themselves into a corner that makes giving back impossible or problematic.

Tim O'Reilly opens up OSCON

Tim is in the middle of his opening keynote at OSCON, talking about the Big Ideas that are driving open source.

Tim just made an interesting point, one that I first heard r0ml make years ago at eGOVOS: open soure is about efficient free markets, not licenses. Why does open source work (and why does Web 2.0 properly architected, work)? Because it feeds off the self-interest - not generosity - of individual developers. People scratch their own itches, and the overall community of software grows. Just as Adam Smith and free market economists have always said it would.

He had a few other interesting points:

• How do we reinvent open source for a world where software is "performed," rather than distributed?
  
  
• Open source will increasingly intersect with the web through mash-ups. Open APIs may overtake open source. Google uses open source to build itself, but is a proprietary company.
  
  
• One other open phenomenon involves closed applications, but opening the frameworks used to build them. (Like 37Signals and Ruby on Rails.)

Clearly, open source (in Tim's mind) is about much more than source code and licenses to govern its use. My question (and Tim's): what does this mean for the future? Where do we go from here?

The secret of successful open source companies (The JBoss example)

At OSCON next week, I'm giving a presentation entitled Making Sales While Making Friends: Lessons Learned from Open Source Businesses. I'm in the middle of preparing it, and also reflecting on some conversations I had earlier this week with sales executives from MySQL, Red Hat, JasperSoft, and SugarCRM.

In the course of those conversations, I was surprised by how differently we supposedly similar open source companies run our operations. We're each an open source company, but with varying licensing, sales, and support models. That's a good thing.

But it's also a perplexing thing if you're trying to weave together a common theme between them.

After our meeting, I spent some time on Sourceforge, pulling download data and correlating it to company revenues for these and other open source companies. After awhile, similarities started to emerge from the data.

Let's use JBoss as an example. Here are the company's downloads over the course of the project:

The red numbers underneath reflect revenue increases year over year. (All the numbers are available out on the web - you just have to dig.) Assuming Red Hat's CFO was telling the truth (and he wouldn't last long if he weren't), JBoss went from next to nothing in revenues (2001) to $60M. (Btw, this is pretty incredible for any company, much less one that started giving away its software only a few short years ago, and has stubbornly persisted in giving it away for free. Nice work, Marc.)

How? I took a walk through the Wayback Machine, to see remember what was happening over the past five years at JBoss, and see how the rising revenues correlate with downloads, product releases, etc.

The most intriguing thing I found is that there has never been any magic formula at JBoss (or at the other successful open source vendors). JBoss made great software. The media picked up on that and reported it. People heard about JBoss, and then downloaded JBoss' software. The biggest spikes in the downloads correspond to significant product releases (usually developer preview versions got the most traction upfront). The biggest spikes (or, rather, gradual but insistent rise) in revenues came 6-9 months after JBoss had started working with HP and Novell.

What I actually find almost shocking in the data is that JBoss' downloads have stayed relatively constant over time. It's not like they jumped 10X each year, or even 2X. They just slowly, incrementally grew. So, contrary to the argument that open source is a volume game, I'm coming to believe that while volume is important to get you through your initial hiccups and customer wins, the real measure of a successful open source company is its ability to convert whatever volume of downloads/would-be customers it has.

JBoss never had the tens of millions of downloads that Red Hat or MySQL have, but it was able to convert a significant percentage of its 50,000 - 100,000 downloads per month into paying customers.

How? Well, one way is simply through brand. The more momentum JBoss has enjoyed, the better its conversion rates have been. That's why the numbers from 2005 to 2006 rise so rapidly - it has established itself as the open source application server to beat. (You can actually trace the download activity to analyst reports and other news JBoss highlighted on its website through the Wayback Machine.)

The other equally important way is through push. That initial 3X JBoss enjoyed seems to stem, in significant part, from the added marketing Marc did back in early 2003 in the support services JBoss offered:

Knowledge from the source. JBG services are delivered directly by the developers of the code. JBoss Group consultants spend 50% of their time writing Free Software and 50% of their time consulting. This is a novel and unique service in the software industry.

Purchasing JBG services is a value added investment in your people and your IT infrastructure. It is transfer of real information from our teams to your teams. Spend your money on knowledge not empty licenses.

January 30, 2003. JBoss Landing Page.

You can also see sales start to accelerate after Matrix, Accel, and Intel Capital invested $10M in JBoss back in February 2004. The company started to ramp its sales force, and revenues followed.

All of which confirms something I'll be presenting at OSCON. (It also, I think, confirms much of what Larry was arguing in his post about "natural revenue growth.") Below I've mocked up a (very) rough idea of what the appropriate sales model is for the number of downloads your company has:

The more volume, the less bandwidth (and need) you have to reach out in a direct way to your user base. The less volume, the more need to "push" sales to maximize conversion rates on the few downloads you have (all the while doing what JBoss did to increase downloads: build a fantastic product and try to get the media and analysts to notice so that people will know to download it and try it out).

The secret sauce, then, for JBoss and all successful open source companies is an exceptional product. Next, be sure to build momentum for your brand so that conversion rates (and sales) rise even as downloads level off. JBoss is the perfect example of a company that has done this exceptionally well, along with its new owner, Red Hat. In this way, creating a successful open source company really isn't dramatically different from building a strong closed-source company. The difference is in all open source's other benefits that give you unfair competitive advantage. But that's another blog entry.

Two industries, two different directions

A recent court ruling will have me watching almost no movies going forward. A recent software trend has me using a lot more software.

The use is directly proportional to the copyright owners' willingness to open up.

In the former case, you may have heard (on Slashdot or elsewhere) that the multi-year fight with the Directors Guild is over: there will be no movie editing allowed (except for TV, airplanes, or whatever else gives Spielberg a big upfront check :-). All the players who scream for IP freedom (including Larry, Mr. "Remix") in software are strangely (or not so strangely) silent in defending CleanFilms, CleanFlicks, and their ilk. (Who wants to protect conservatives, after all?) Without a lobby, the judge decided and these companies go out of business.

As a prude when it comes to movies, I'm now out of the market. Oh, well, my life was fine during the years before the editing companies came along. I'm sure I'll survive without Hollywood.

What is interesting to me is technology's trend in the opposite direction, toward open source and open standards, with real money attached to the trend. Yes, I know the core issue is about "integrity" of one's work. When Spielberg throws in a gratuitous sex scene to achieve a PG-13 or R rating (because it will help ticket sales if it has that rating, not the scene), he wants to be sure no one can think of him without thinking of his silly pandering to the box office. Fine.

But it's this rigid control of a copyrighted work's future - its "integrity," as it were - that is precisely what the technology world is abandoning (through open source, Web 2.0 mash-ups, etc.), and to excellent effect. So, of interest to me is that one set of copyright holders is deliberately letting go of the reins to make money (software), while the other camp is tightening restrictions. The results speak for themselves (in movies and in music.) Is there a lesson here?

So, while I used to use the slide below in my presentations, I don't think I can anymore. The point of the slide was to show that we should learn from the entertainment industry's mistakes, not replicate them.

Apparently, we (software) have. The entertainment industry is closing up...and shutting down revenues. The software industry? Well, even Microsoft is opening up. Sales will continue to rise as we learn to master the new model of openness. The tradeoff is that we'll have lots of software to use, but nothing to watch or listen to. :-)

Novell vs. JBoss (Computer Business Review)

First off, where did Computer Business Review come from? I've been pining for interesting commentary and news on open source that isn't a regurgitation of press releases, and CBR consistently delivers it. Matthew Aslett (No relation, despite the similarity in names :-) is doing an exceptional job.

Case in point: I think he's the one who broke the news that Novell's SLES 10 doesn't include JBoss 4.0. Now, he's the one hounding the two to find out why.

As for the Novell vs. JBoss decision, it seems fairly pedestrian, as Justin Steinman (of Novell) explains:

As part of the SUSE Linux Enterprise development process, we evaluate the licensing for each package that we ship in our distribution. While packages like JBoss are distributed under the LGPL license, there are many components which are proprietary technologies from third parties.

We found several components in JBoss4 that fit this profile. We checked with JBoss and the two areas in question, the SRP security extensions and the application client, ship under licenses that have questionable redistribution rights for Novell.

We didn't want to modify the JBoss package and we couldn't get legal clarification until March 29, 2006. At that time, it was too late to include JBoss4 in SUSE Linux Enterprise Server 10, as the SLES 10 beta test was well underway....

Our decision not to ship JBoss4 in SLES10 was made on March 29. The Red Hat acquisition of JBoss was announced on April 10. There is no connection between the removal of JBoss4 from SLES10 and the acquisition of JBoss by Red Hat.

So, for those looking for mystery, anger, finger-pointing, and what-not, you're going to be disappointed. I'm sure Novell wasn't happy with the Red Hat acquisition of JBoss, but that's life in software (open or closed).

Pickaxes and shovels, Part II: Krugle

I spent a productive hour with Krugle yesterday, meeting with a few members of management: Steve Larsen (CEO), Laura Merling (VP, Business Development - yes, that Laura Merling), and Ken Krugler (CTO). I have to admit: I went into the meeting with low expectations. In Ken's words, I figured a vertical search engine focused on open source and development might be interesting, but not useful (with "use" translating into dollars).

I was wrong.

First off, Krugle is more than a vertical search engine. It does that, and it does it extremely well. Krugle aggregates the many and various open source software repositories (Sourceforge being just one of them), indexes them, and makes them easily, productively searchable. So, if I know I need a utility to convert documents to PDFs, or need a special library to do X, Y, or Z, I can easily find it using Krugle.

Even more interestingly, once I find the code itself, as well as relevant how-tos, I can actually select this grouping of tabs in Krugle and email a link of that composite of information to someone. So, if I'm trying to show a friend, customer, partner, or whomever how to integrate JasperSoft with OpenOffice, it becomes super-easy to aggregate that information, package it, and send it over to someone as a unified URL. Nice.

I would argue that as Krugle grows and improves, it will become as critical to development as the IDE. There will simply be no reason to not facilitate development using Krugle.

Keep in mind, however, that Krugle is not relegated to the airy confines of the uber-elite developers. Krugle is something that system administrators or casual developers/programmers can use to get their jobs done. Krugle provides access to the world of code samples, tech notes, etc. that can help someone get their job done, e.g., I'm a system administrator that knows I need something for my Linux installations to facilitate monitoring of those servers. I go into Krugle, type in a relevant search, and up pops relevant projects and their descriptions (as well as licensing information, strength of the project measured in active developers, downloads, comments from other developers, etc.), code from various projects that I can immediately drop in, tech notes that describe how others have done the same thing, etc.

It's like having the entire world of open source on your hard drive. Quickly accessible.

So, that's search. Where I think Krugle gets even more useful is as a tech support option. Krugle centralizes forum/wiki/etc. support for the world of open source projects, giving users a one-stop shop for Alfresco, SugarCRM, JasperSoft, MySQL, etc. (online) support. Krugle takes it a step further, however, and allows its users to add comments to the support pages ("Follow steps 1-4, but instead of 5, reboot and type "XXXXX" into the command line"). Krugle thereby enables user-generated support pages and enriches the support of both project-based and company-based open source products.

There's more, but this is getting a bit long. The short of it is that Krugle is doing some exciting things relative to open source search, development, and support. Done right, Krugle should become a central aspect of open source development going forward.

P.S. My biggest question going into the meeting was how Krugle plans to make money. The immediate answer is "advertising," but the longer-term, more interesting answer is many and varied. Tech companies (proprietary or open source) should consider Krugle to beef up and improve their developer support (or just technical support) offerings. That's just one OEM possibility - I can see several others. I can also see enterprise IT licensing Krugle as a natural complement to their development tools.

From national security threat to national interest....

Computer Business Review has an interesting review of the United States Department of Defense report "Open Technology Development". [PDF] If you haven't read it, you need to take a look. It is one of the most clear-sighted documents on open source that I've yet read, and should banish CIO doubts as to the core benefits of open source: cost savings, security, speed of development, robustness of development, etc.

SCO and others have been crying 'Foul' on the US government's increasing adoption of open source, suggesting (as Darl McBride writes here in his letter to the US Senate and House)

"I assert that open source software - available widely through the Internet - has the potential to provide our nation's enemies or potential enemies with computing capabilities that are restricted by US law."

Think that's a bit silly? Try this one, from the CEO of Green Hills Software:

"Now that foreign intelligence agencies and terrorists know that Linux is going to control our most advanced defense systems, they can use fake identities to contribute subversive software that will soon be incorporated into our most advanced defense systems."

Apparently O'Dowd (Green Hills CEO) has never actually taken the time to learn how open source and, specifically, Linux, operates. But we'll forgive his abject ignorance on the condition that someone pays his tuition to head back to school at some point. He needs it.

Anyway, back to the Department of Defense's report. It has a treasure trove of insight, nicely counterbalancing the ignorance noted above:

Currently within DoD, there is no internal distribution policy or mechanism for DoD developed and paid for software code. By not enabling internal distribution, DoD creates an arbitrary scarcity of its own software code, which increases the development and maintenance costs of information technology across the Department.

Other negative consequences include lock-in to obsolete proprietary technologies, the inability to extend existing capabilities in months vs. years, and snarls of interoperability that stem from the opacity and stove-piping of information systems....

Software code has become central to the warfighter's ability to conduct missions. If this shift is going to be an advantage, rather than an Achilles' heel, DoD must pursue an active strategy to manage its software knowledge base and foster an internal culture of open interfaces, modularity and reuse. This entails a parallel shift in acquisitions methodologies and business process to facilitate discovery and re-use of software code across DoD.

The national security implications of open technology development (OTD) are clear: increased technological agility for warfighters, more robust and competitive options for program managers, and higher levels of accountability in the defense industrial base....

DoD needs to use open technology design and development methodologies to increase the speed at which military systems are delivered to the warfighter, and accelerate the development of new, adaptive capabilities that leverage DoD's massive investments in software infrastructure.

To be fair, the DoD is not talking about open source exclusively in this report. It is talking more broadly about open development:

In the private sector, changes in design methodologies for software development are enabling enormous gains in productivity and efficiency. Individuals and companies are able to leverage open technology platforms to rapidly deploy new solutions and capabilities to improve their competitive advantage. These open technology platforms may be open source or proprietary software applications with open standards and published interfaces that allow the rapid development of new capabilities by third parties without coordination agreements.

It's the mash-up mentality, in some ways, that seems to appeal most to the DoD. But it's not just about "Web 2.0" thinking. It's about how to make the DoD a participant in the wider software community, thereby saving development cycles and development dollars, as this fascinating excerpt indicates:

DoD has two competing interests:

1. Provide for the defense of the U.S., and;
   
2. Support and grow the U.S. industrial base, which provides materiel and systems so that DoD can accomplish its mission.

These trade-offs are well understood for physical goods and services, but not as well understood for digital ones. DoD can easily calculate the cost difference between developing or acquiring a physical good or service by simply comparing make or buy costs. There is however a fundamental difference between physical and digital products. Digital goods (software code, music, movies, etc.) once created can be copied perfectly with relative ease: limiting distribution enforces scarcity, but that scarcity is arbitrary and negotiated, rather than an innate property of the product. Software's ability to be replicated also means it can be incorporated into other software systems without "using up" the original component, as one would with physical components.

The business model of purchasing physical goods and services has served DoD well in the past; but it falls short when applied to software acquisition. By treating DoD-developed software code as a physical good, DoD is limiting and restricting the ability of the market to compete for the provision of new and innovative solutions and capabilities. By enabling industry to leverage an open code development model, DoD would provide the market incentives to increase the agility and competitiveness of the industrial base.

Currently within DoD, there is no internal distribution policy or mechanism for DoD developed and paid for software code. By not enabling internal distribution, DoD creates an arbitrary scarcity of its own software code, which increases the development and maintenance costs of information technology across the Department. Other negative consequences include lock-in to obsolete proprietary technologies, the inability to extend existing capabilities in months vs. years, and snarls of interoperability that stem from the opacity and stove-piping of information systems.

DoD needs to evaluate the impact that locking into one set of proprietary standards or products may have to its ability to react and respond to adversaries and more importantly, to technological change that is accelerating regardless of military conflict. In order to remain competitive in a rapidly shifting technological landscape (including the disruptive technologies leveraged by our adversaries), DoD's software development and business processes must break out of the industrial-era acquisitions mold.

Amazing stuff. The DoD summarizes as follows, and shows a clear understanding of open source's benefits:

To summarize: OSS and open source development methodologies are important to the National Security and National Interest of the U.S. for the following reasons:

• Enhances agility of IT industries to more rapidly adapt and change to user needed capabilities.
  
  
• Strengthens the industrial base by not protecting industry from competition. Makes industry more likely to compete on ideas and execution versus product lock-in.
  
  
• Adoption recognizes a change in our position with regard to balance of trade of IT.
  
  
• Enables DoD to secure the infrastructure and increase security by understanding what is actually in the source code of software installed in DoD networks.
  
  
• Rapidly respond to adversary actions as well as rapid changes in the technology industrial base.

Amen. Now if you're a CIO tasked with saving money and resources for a large or small enterprise, wouldn't it seem prudent to follow the lead of an organization tasked with saving taxpayers' money and lives? Yeah. Me, too.

Hyperic goes open source

Hyperic just went open source, and is positioned to do very well.

Why? Well, I see Hyperic as the quintessential "49er" beneficiary. You remember the cliche: those that made money in the Gold Rush were those selling pickaxes and shovels, rather than those wielding them. Hyperic provides the tools open source companies need to succeed. Namely:

The Hyperic HQ open source management platform provides a suite of free inventory auto-discovery, monitoring, alerting and portal tools that can be deployed out of the box in less than an hour, using plug-ins for the specific commercial and/or open source IT assets used in the customerÂ’s network. Support for products without plug-ins can be rapidly added to Hyperic HQ through its free open source development kit.

What does this mean? Well, it means, for one thing, that open source companies will be better able to track where their downloads are going. One of the big frustrations in any open source company is the lack of data about who is using its product, and for what. Hyperic gives vendors (with the approval of their customers, of course) the ability to gather aggregate data on how their software is being deployed, or whether the downloads are just that: downloads that sit on a user's hard drive but never get moved into evaluation/pilot/production.

The Hyperic solution also enables vendors to better manage bug fixes (both reporting and patch management back out to the customers), customer support (as envisaged above), and a range of other things. These are some hefty "pickaxes and shovels," and available under GPL (v2).

The biggest gun in open source services?

Bet you didn't think "Unisys" when you read that subject line, but it's true, all the same. Unisys has done a great job reinventing itself and extending its brand and expertise into new territory, most recently open source software. The firm has strong and growing relationships with MySQL and JBoss, and will increasingly be seen as one of the primary go-to partners for open source.

Julie Giera of Forrester has an interesting report on Unisys' open source services. The report deals primarily with Unisys, but also has interesting things to say about the larger open source services market.

On Unisys she says:

Unisys has announced a set of service offerings, called OASIS, for companies with open source platforms. It is the first time that a major IT service provider has offered a fully integrated set of services - including installation, configuration, maintenance, and enhancement - for a predefined open source stack. Competitors like HP and IBM have long had a menu of open source services that customers could choose from, but they have been reluctant to put a stake in the ground around a specific set of open source components. The OASIS announcement is an early indication that the open source services market is starting to mature. Through the OASIS offerings, open source customers can expect to achieve some of the same benefits as commercial software customers - predictability, cost savings, and strong service-level guarantees. With the OASIS set of services offerings, Forrester believes that Unisys should be on the shortlist of vendors for open source services.

Fine and interesting. But Giera also takes the analysis a step further, identifying key requirements underpinning the open source services broker:

• Open source choices delight, and confound, the CIO. Companies have many more software choices available to them today, in the form of both commercial software products and open source projects. Forrester believes that in the next two years entire enterprise application suites targeted to specific vertical industries will be available in the open source community. But since open source can be changed by anyone, the version control and feature/function planning that IT managers have come to depend on in commercial software markets doesn't necessarily exist. Of course, distributors like Red Hat are trying to dampen some of that unpredictability by applying change and release management processes to some of the more popular open source components. But the rigidity that comes with standardization flies in the face of some of the core tenets of open source - namely freedom and choice.
  
  
• IT service providers have tried to be all things to all people. It has proven difficult for IT services vendors like IBM to appear supportive of customer choice and freedom on the one hand, while at the same time driving standardization. In a recent discussion with IBM, Forrester was told "we don't want to alienate the open source community" by creating a standard services offering around one specific open source stack. IBM, like its rival HP, is concerned that if it creates a standard set of services around a predefined stack, it will be accused of forcing open source customers into an IBM-defined set of choices. IBM wants to avoid even the perception that it might be limiting customer options for software; especially since it has long been a cheerleader for open source, and it's been a proprietary software vendor for even longer.

This sort of ambivalence - born of the best intentions, I have no doubt - can't persist in services companies. As Giera notes, "[S]ervice providers have to standardize the platform they're supporting. In fact, the differences between supporting a standard platform and supporting a nonstandard platform are as high as 40% over the life of the code. That's a huge number, especially if you consider that some IT applications can live for 10 years or more." This is the route Unisys is taking, and it's the same route taken by several of the smaller (but still highly successful) open source SIs like Cignex, Enomaly, Rivet Logic, Novacoast, etc.

To be successful in services (and software), you must pick your battles. Or, in open source terms, you must pick your packages/projects. You can't be all things to all people. I know, because I tried once. When at Novell, we struggled with the decision to support KDE or GNOME, and ended up straddling both (unsuccessfully, in my opinion). It burned development cycles, caused wasteful internal debate, and confused customers. Ultimately, GNOME won out by executive fiat. It should have happened much sooner, as at Red Hat.

So, you need to figure out how to be a few significant things to a decent swath of the buying population. That's where the money is, and Unisys is going about open source services in an optimal way.

Finding good bands and good software

A good friend from Stanford, Lincoln Davies, turned me on to Clap Your Hands Say Yeah today, and I've been listening ever since. What a great sound. If you're into Radiohead, The Shins, White Stripes, etc. (as I am), you'll probably really like their sound.

I've used Pandora before for this same purpose - music discovery - and it works much the same as Lincoln's informal advice. (Except Pandora doesn't abuse my basketball prowess while advising on music.)

Why doesn't open source work the same? You like Plone? You'll really like SugarCRM (or whatever), and here's why. Nothing like that exists (of which I'm aware) today in open source. Ohioh (weak name) aims to help us discover the relative strength of a project, and Krugle helps you find great code in the first place, but there are no matching engines (again, of which I'm aware) to coordinate needs and preferences with open source software.

I suppose this is what SIs and analysts do (and I know some do it quite well), but surely there's a first-try method available somewhere? Or should be?

Giving employees room to breathe open source

One of the most important requirements for any startup is hiring exceptional people. Hire weak people, and the company rises to the level of their incompetence. Hire exceptional people, and the company is elevated to the level of their expertise.

So how do you hire well in open source, given that - outside the realm of developers - very few business people actually have open source experience?

This is a question that I've had to answer repeatedly of late, as I've been hiring Alfresco's North and South American sales and business development organization. I have been very fortunate thus far, hiring three of the best people I've ever worked with: Luis Sala (Solutions Engineering), Jason Hardin (Inside Sales), and Martin Musierowicz aka "Mark" (Alliances).

What do most of Alfresco's employees have in common? Not a minute of open source experience. (Martin (JBoss) and Jason (Novell) are exceptions to this rule, as both came from open source companies.)

Despite this void, they've managed to pick up the open source strategy and mindset very well, and use it to good advantage against old employers (now our competitors) in the Enterprise Content Management market. The same is true of many of the hires at MySQL, SugarCRM, Funambol, etc.

The interesting part of this is that they were each mostly incapable of effectively competing with open source, or turning their companies to open source, while still with their proprietary ex-employers. During my three years at Novell, I was amazed at how hard it was to culturally shift people from a proprietary mindset to an open source one, and even more surprised by how difficult it was to change bureaucratic things like sales compensation models, distribution models, etc.

In short, people can change relatively easily in the open source world, if you take them out of a proprietary company. But proprietary companies, themselves, find it excruciatingly difficult to change. The same people struggle to embrace open source while locked within a proprietary company, and thrive with open source outside these companies. You just have to offer them a way out.

I'm therefore finding that a great place to find excellent talent for an open source company is within one's direct competitors, or within vendors that compete in the same industry, but in a different niche of the industry. Whatever the competitive company's position, there are scads of employees at all levels of the organization who dearly want to get out and thrive with open source (starting with the CEO :-). So long as they're not constrained by a non-compete, and provided they are stellar performers, odds are they'll kick tail for an open source company.

Now, if you're a proprietary software company, wondering how to morph into an open source-friendly organization, you're going to find it very difficult. In fact, I would argue that your best bet is to isolate a group within the company and allow that company to experiment with open source separate from the rest of your company. Give them free rein. If the trial succeeds and the division/subsidiary/whatever grows, try grafting it back into the main branch of the tree and let them run amok.

Novell sort of did this with Ximian - the deal made no financial sense but lots of cultural sense as the Ximian team ran wild through Novell's staid culture and shook things up. Ximian may have accelerated Novell's transition to an open source company by two years (i.e., it only took two years instead of an estimated four years it otherwise would have taken).

In short, it's very hard for a proprietary company to embrace open source, for a wide range of different reasons. This gives open source a competitive advantage over them. And it also means that proprietary companies that want to open up are probably going to be most successful if they give employees room to do so...in isolation from the stultifying culture and processes of the closed source company.

Young, strappin' entrepreneurs

Do you have to be 14 to start a Google? No, according to some research cited by Will Price on his blog.

creativity comes in two distinct types - quick and dramatic and careful and quiet. David Galenson, an economist at the University of Chicago, analyzed the creative output of leading artists. He plotted the relationship between an artist's age and the value of their paintings. He quickly realized the artists clustered into two distinct groups - conceptualists, who did their breakthrough work early in life and then declined and experimentalists - who developed slowly, experimented and iterated, and peaked later in life. In the former camp are artists such as Mozart (age 30), Andy Warhol (33), Picasso (26), F. Scott Fitzgerald (29), and in the latter camp are figures such as Twain (50), Cezzanne (64), and Beethoven (54).

Conceputalists rewrite the rule book and in their extreme creativity revolutionize their area of focus and specialty. Experimentalists innovate more incrementally and while not as radical do infact generate great creativity over much longer periods of time. It is fascinating to apply the two mental constructs to the high-tech industry.

So, abbreviating far too much (and far too sloppily), you get the young entrepreuners who rock the world because they don't know any better, and the "old" entrepreneurs who innovate on the world as it is, because they know the world too well.

At 33, I guess I'm hamstrung in the middle. Too young to know it all, and too old to not know better.

The best day of OSCON...ever

I've been fortunate to be able to help Tim put together the Open Source Executive Briefing for the O'Reilly Open Source Convention this year. Fortunate because my views of open source tend not to stray far from "What will make my company more money today?" Tim, of course, tends to think in terms of years and decades, not days and weeks. So working with him has helped me see a bit farther out into the darkness to see where open source is going.

The picture is very, very bright.

However, most people will continue plodding along in their "open source is about commodification" mode, missing out on the bigger picture(s), unless they attend. There are very few events that I think can fundamentally change the way you look at, invest in, and monetize open source technology. This will be one of them. If you're an investor, you must be there. Same with any software executive. If you're not there, you're going to be left behind on the next big waves in open source.

July 25. Portland, Oregon. Only 12 more days to register, book travel, etc.

So, what will be talking about? The Executive Briefing is divided into four major divisions, corresponding to the O'Reilly Radar:

• Open Source as Assymmetric Competition. - For years the software industry has largely competed on the basis of symmetry: Oracle versus IBM in databases; BEA versus IBM in application servers; etc. Feature wars, price wars, but not true competition wars. That is, competing by playing a different game, with different rules. Open source enables an alternative battleground upon which to compete, with community, code, and culture the new competitive tools. This session brings together the top open source executives deploying these tactics of asymmetric competition, to learn from their experience. We'll also ask them how they respond in turn to the possibility of asymmetric competition from Web 2.0 platforms and applications, and to the operational needs of businesses delivering software as a service? Finally, we'd like to ask them the converse of what we asked Google and Yahoo!: Are you guys working together closely enough? Speakers include: Michael Tiemann (Red Hat), Marten Mickos (MySQL), David Skok (Matrix Partners, investor in JBoss), Jim Buckmaster (Craigslist), Bill Hilf (Microsoft), and others.
  
  
• Operations as Advantage - In a world where software is delivered as a service, the quality of a company's operational infrastructure is a key source of competitive advantage. Is this a world where scale matters? In a recent interview, Debra Chrapaty, the VP of Operations for Microsoft's Windows Live, contended that in the future, being a developer on someone's platform will mean being hosted on their infrastructure, and suggested that only a few companies will have the scale to compete. At OSCON this year, we're going to hash through this idea with some of the most exciting thinkers (and companies) in the industry: Ian Wilkes (Second Life), Brian Behlendorf (CollabNet), Javier Soltero (Hyperic), and others.
  
  
• Open Data - Tim has long believed that "data is the Intel Inside" of Web 2.0 applications, the source of competitive advantage and lock in. As a consequence, he also believes that it won't be long before "open data" becomes as hot-button an issue as open source software has been. He'll be grilling Chad Dickerson of Yahoo! on Flickr's decision to not allow Zoomr, a competitor to Flickr, to use Flickr's own web services API to help users to move their photos from Flickr to Zoomr. Flickr's been a pioneer in open web services, but they drew the line there. Was this the first shot in the "open data" wars? And how can open source companies make money from data, not source?
  
  
• Open Source and Web 2.0 - Everyone knows that Google, Yahoo!, and many other "Web 2.0" companies are built on top of open source, but how exactly do they use it? What's more, how do they apply principles from open source to other aspects of their business? How does a Web 2.0 business differ from a traditional software business? In this conversation with Chris DiBona, Open Source Program Manager for Google, Jeremy Zawodny, open source point man in Developer Relations for Yahoo!, and Jim Buckmaster, CEO of Craigslist, we'll explore these topics and more. We'll also put them in the hot seat: how do they give back to open source projects when source code alone isn't enough for people to recreate the application?

It's going to be one of the most exciting (and intellectually stimulating) open source days I've ever attended. Where else will you have Irwin Gross commenting on an observation that the output of the United States keeps getting lighter (as in weight), and how this begs for more efficient software markets? Or Tim O'Reilly pointing to 5-10 of the rising leaders in open source, and why they're so interesting to him? Or Mike Schroepfer, Vice President of Engineering, Mozilla, talking about how Mozilla has transformed Firefox from just-another-browser into a leading web platform?

Answer. Nowhere. And given how much of an OSBC bigot I am, that's saying something.

You can register for the Executive Briefing here. And you should. :-)

Open source support: Best practice

However you dress it up, at the end of the day open source is about support. It's therefore critical that open source companies invest heavily in support.

How? JBoss provides the answer. (Here's the layout of JBoss' support offerings.)

Who do you get when you ping JBoss for support? You get a core engineer. At JBoss, engineers commit to spend 25% of their time supporting customers. (At Google, they commit to spending 20% of their time thinking up also-ran applications - ouch! I'd rather get the support engineer.) The head of support, then, is primarily responsible for corraling engineers to ensure they're spending at least 25% of their time on customers - current, not future. They don't hire low-end support people - they hire engineers who also do support.

This is an exceptional model (one that we're trying to emulate). The benefits are obvious:

1. Customers don't have to waste time with someone that can't understand their issues. They quickly get to the very engineers who wrote the product.
   
   
2. JBoss (now Red Hat) benefits because customers want to buy from the source of the code.
   
   
3. JBoss engineers benefit because they get to hear from real people with real problems with their software. Engineers can fall into a "My code has no problems" mentality. Talking with customers helps them see how it (mal)functions in the real world, helping them develop better products.

Again, whether you're using an "on-ramp" (SugarCRM) model or a Red Hat model or whatever, support is the core of an open source company. JBoss shows how to do it right.

Off-topic: Who scored the most?

FWIW, I'm actually starting a football blog wherein to capture my random thoughts on football and why Fabrizio is wrong about everything (when it comes to football). So, this particular blog (and InfoWorld) should be less cluttered with tortured analogies to open source and football. (I've invited Fabrizio, Will, and Nick to start, and have been trying to get John Mark's new email address to invite him, too. [You heard it here first - John Mark has left LinuxWorld to run Hyperic's developer community outreach. If you're in open source, and have strong opinions on the beautiful game, ping me.)

In the meantime, which club scored the most goals in the World Cup? I'm sorry to say that it wasn't Arsenal, though we were close. As Victor Predictor reports, Chelsea scraped through on the top, with Arsenal and Real Madrid tied for second. (Had either Henry or Zidane done their jobs in the final, either Arsenal or Real Madrid would have tied for first.)

The moral of the story? If you want to watch high-scoring football, you shouldn't be watching the Serie A (15) or Bundesliga (13). You should be watching the Premiership (27 goals). If you must, you can condescend to watch La Liga (22). Ligue 1? Don't even bother. The good players from Ligue 1 en France end up playing for Arsenal, anyway.

Of course, football isn't exciting because of the goals, but rather because of the lack of them. Anyone can win on any given day.

Applications at Internet speed

Something happened to me today that I thought never would: I stopped loving Apple's iChat. Actually, I still love the application, but I decided to start playing with Adium and discovered open source nirvana.

The problem with iChat is that it doesn't change often enough for me. I get updates and new features when Apple decides to release them. Adium, however, has a wealth of add-ons that iChat simply can't match. It's a bit like Safari and Firefox (or IE and Firefox, if you're still using a Windows machine) - Safari is an exceptionally cool browser, but it's whatever Apple wants it to be at a certain point in time. It has no intention to allow others to make it into different things. (If it would allow me to close tabs by clicking on the tab icon, instead of the x to the right of the browser, I'd be sold completely.)

In short, I like Adium and Firefox because I get a larger innovation community around the products.

Keep in mind that a commercial entity can do this, too. Mozilla is, in fact, a commercial entity. But it requires a company to architect its product for extensibility, and it requires the company to take a (mostly) hands-off approach to what its core is extended to do. (Love it or hate it, Microsoft actually does a reasonably good job of enabling third-party innovation around Outlook and some of its other products. It could do much better, but at least it tries to let others innovate around its products before it obliterates those partners. :-)

The operations advantage (Tim O'Reilly)

Great post today from Tim, talking about the unsexy world of operations, and how it will help companies (like Microsoft) compete. Here's a blurb:

I spoke last week with Debra Chrapaty, the VP of Operations for Windows Live, to explore one of the big ideas I have about Web 2.0, namely that once we move to software as a service, everything we thought we knew about competitive advantage has to be rethought. Operations becomes the elephant in the room. Debra agrees. She's absolutely convinced that what she does is one of the big differentiators for Microsoft going forward. Here are a couple of the most provocative assertions from our conversation:

1. Being a developer "on someone's platform" may ultimately mean running your app in their data center, not just using their APIs.
   
   
2. Internet-scale applications are pushing the envelope on operational competence, but enterprise-class applications will follow. And here, Microsoft has a key advantage over open source, because the Windows Live team and the Windows Server and tools team work far more closely together than open source projects work with companies like Yahoo!, Amazon, or Google.

I agree. At a more pedantic level, one of the great differentiators in open source today is execution: Red Hat has it, as have the other top open source companies. Many are turning to Hyperic now as a way to automate "network" functions of their open source experience. It's all a recognition of the importance of operational excellence.

Check out the rest of Tim's post for his insights on this issue. And if you really want to hear the topic discussed, you really need to join us at O'Reilly's Open Source Executive Radar event (July 25 in Portland, OR). Should be exceptional.

Put the ball in the back of the net

I've learned a lot from Fabrizio this past year. Mostly as we've dickered and debated soccer (football). And yes, I've normally won, Fabrizio, whatever your memory may tell you. :-)

The primary thing I've learned is that the bad calls, the missed chances, the percentages of possession, etc. don't matter at the end of the game. At the end of the game, the team that puts the ball in the back of the net wins. I was rooting for France yesterday, and they controlled most of the game. But it didn't matter - Italy put the ball in the back of the net more. So they won. Reality bites.



In business it's the same. We may complain about diving and unfair referreeing ("Microsoft plays unfair!"). We can tell everyone that our team has dominated the match ("Our technology is far superior to Microsoft!"). We can bemoan this or that missed customer win ("We had them sold, and then Microsoft came in and cut us out with a massive discount!").

But at the end of the game, it only matters who managed to put the ball in the back of the net. Those who play well don't have to whine about a referree's bad call, because their goals speak for themselves. Those that score don't have to fret about all the times they didn't.

Open source companies are particularly well suited to "score" sales, not merely downloads, missed chances, etc. It's our time to score - repeatedly - in the software business match. I don't want to be one of the four Yorkshiremen talking about how hard life was when I was competing - I want to compete now and win.

Those wild and crazy VCs!

The Wall Street Journal ran hilarious story [Subscription required] on Saturday (intentionally or unintentionally so, I'm still not sure) on venture capitalists who try to fit in with youth culture to get in on the best deals. It starts in this way:

Venture capitalist David Cowan is a professed chess-playing nerd who studied math and computer science at Harvard. Last year, though, he decided he needed a crash course in getting hip.

For the first time, the 40-year-old downloaded songs from Apple's iTunes online-music store and put some games on his cellphone. He started writing an irreverent blog, called "Who has time for this?" with observations on everything from computer security to his dead cat. He urged readers to give their own felines "a little extra tuna" in memory of his departed pet, Snoopy. Finally, the suburban father of three ventured out to a few high-tech networking parties, including one packed with Stanford University students and beer kegs.

His goal: to fit in with the young entrepreneurs who are suddenly the stars of Silicon Valley, with their hot Web startups aimed at teenagers and young adults. They have begun showing up at his firm, Bessemer Venture Partners of Menlo Park, Calif., dressed in T-shirts and flip-flops to pitch ideas, like mobile-phone services that help young people locate each other when they're out on the town.

A lot of questions are begged by this article, and by David's approach:

1. Since when is the latest youthquake a prime opportunity for investment? (For all the raving about MySpace, last I heard it's only doing $30M or so in revenues, and struggling to boost that because teens are on to the next next big thing - one thing I've learned about kids, their loyalties are fickle. MySpace is no different.)
   
   
2. Why must one act like a juvenile to give a juvenile money?
   
   
3. Aren't the grown-ups the ones with all the cash?

I know there are good answers to each of these questions, but I'm not sure any of them point to a compelling reason for VCs to do things like this:

Forty-year-old and 50-year-old venture capitalists -- often more accustomed to private jets and second homes than to hanging out with kids in bars -- are now heading to beer-soaked parties to meet 20-year-old techies. One investment firm invited entrepreneurs to a hip-hop concert. Another venture capitalist, sensing a networking opportunity, is organizing a bowling team to compete in a new league formed by young startup executives.

or

...To stop embarrassing themselves with the young crowd, some investors are outsourcing networking activities to new, under-30 "associates," hired specifically to talk the talk with the youthful Internet leaders and hang out with them. "They wear black" and fit in at cool San Francisco clubs and restaurants, says Wes Raffel, 50, a partner with Advanced Technology Ventures in Palo Alto.

I have some advice for those tragically unhip VCs that desperately want to be cool:

1. Give it up. If you have kids of your own, you already know you're not cool. I have four kids who still think I'm funny but think me less and less cool with each passing day.
   
   
2. Speaking of your own kids, watch them. Spend more time at home rather than at "beer-soaked parties." Your kids will be a better barometer of "cool" than a 20-something ex-Googler. Anyone that can read those Google billboards is "uncool" in the rest of the country. :-)
   
   
3. Try visiting family out of state. There are lots of uncool people off the coasts - these people are a market, too. In fact, they're actually a bigger market.

I suspect that most VCs aren't like the caricatures in this article. I've been fortunate to raise money from grown-ups over the year (Robin Vasan at Mayfield, Kevin Comolli at Accel, etc.). In fact, all of the VCs I know are uncool, intelligent, hard-working people. Not one of them has ever invited me to a Snoop Doggy Dog concert (though I wouldn't say no to a Chelsea match, Kevin. :-) In the end, my companies have taken venture money from those we felt best qualified to help grow our businesses, not those that pretended to be teenagers.

Same is true of David and others. David is a smart guy. People want his investment for that reason, and not because he's hanging with the homies at parties. (At any rate, David redeems himself at the end of the article:

After trying different ways to understand the younger set, he drew the line at getting onto the MySpace.com social networking site, where young teens -- and what some parents say are adult predators -- hang out. "I think for a 40-year-old to build a MySpace profile is a little bit creepy," he says.

Indeed.)

Self-policing in open source

One of my OSBC partners, Brett Haskins, has started The Project, an online short film competition. (Some of the films are excellent. Take a look.)

One of my favorites - Citizen's Arrest - reminds me of open source self-policing of IP violations:

[Click on the JPEG to watch the movie.]

Actually, open source policing works much more effectively than this short video depicts. I had a prospective customer ping me the other day about open source IP safety - what's to keep some rogue developer from dropping malicious code into Alfresco, SugarCRM, Linux, or Project-of-your-choice?

Everything. I'm actually surprised this question still comes up. Here's the gist of what I told him:

1. Transparency. This is the foundation of all open source security. If someone, somehow manages to get malicious code, or someone else's IP, into an open source project, it's very easy to spot the problem and resolve it. Before a lawsuit happens. But this will rarely happen (except in roll-your-eyes cases like SCO) because...
   
   
2. It's simply not possible to commit code to a project without a lot of credibility on that project. IBM developers two years contributing to Linux before they were taken seriously and given "committer" status. I know few evil, rogue developers (OK, I don't actually know any) that would have the patience to invest two years in a project, just to subvert it. For lesser, but important, projects (anything from Plone to Mule) may require less time, but the principle is the same: it is not easy to get committer status on good projects.
   
   
3. You'd have to sneak it past the marshall. Nearly all open source projects have some one person that makes the ultimate decision on whether code is accepted or not. Linus for Linux. Or a company if it's a commercial open source project. It's not the case that people can just drop code and run. Well, they can, but it won't make its way into the code base. And speaking of companies...
   
   
4. Since when is a proprietary company more trustworthy than an open source one? Or more careful? Many of the enterprise-facing open source projects today are driven by corporations, which corporations care just as much as Microsoft et al. about security, IP integrity, etc. The fact that we choose to open source our code doesn't minimize our commitment to ensuring the code we deliver is safe. On the contrary, it probably makes us more aware of these factors and driven to remove concerns.

In sum, open source - from an IP infringement perspective - is systematically set up to be safe to us. That said, it's a fair question to ask your open source vendor if it has policies in place to ensure the integrity of its copyright ownership. Just don't be surprised when the answer is, "Of course."

Silicon Valley and open source wish fulfillment

I'm not sure what it is, but Silicon Valley so desperately wants to be the center of everything, that sometimes it has to resort to myths to keep itself there. Where? Exactly. That's the question. It's a question I didn't think could be all that controversial when I said it at OSBC London, but now that it has been slashdotted, I guess it's officially a Big Deal. For 3.5 seconds.

Dana had a good response to my post about Europe remaining the center of open source. Now a few others have jumped on the bandwagon, and their critiques aren't quite as salient.

Matthew Aslett tries (and fails, though he never claimed his method was perfect) to illustrate on a map that I'm wrong. But Matthew fails to illustrate the relative importance/success of companies and their origins. MySQL, Red Hat, JBoss, Digium, Alfresco, Sourcefire, SugarCRM - these are the disproportionate "winners" in open source (so far) - and only one started in the Valley (SugarCRM). Even if I add to this list with companies that are rising fast - Funambol, Ubuntu, etc. - I still come up short with Valley-founded companies.

So, while there are a lot of (new) open source companies take in the Valley, it doesn't change the fact that the biggest open source stories don't come from the US. SugarCRM is the exception, not the rule. If we were to add a revenue component to Matthew's mashup (expanding the size of the balloon according to revenues), it would be hard to see Europe and the East Coast of the US because of the bloated balloons, while the Valley would be a connect-the-dots exercise, with only SugarCRM ballooning out.

Will I need to change my opinion two years from now, since Silicon Valley VCs have invested in 3.2 trillion open source companies in the past two years (potentially raising my earlier $1.3 billion open source investment number to $2+ billion). Perhaps. But I'm hoping that open source companies won't feel the need to bleat their way to the Valley to get funding. Stay close to customers. Open source needs more diversity, not less.

This is the primary reason I disagree with the eminent Robert Scoble, who weighs in on the issue here and I think gets nicely swatted by Matthew Aslett. Very politely. Scoble tries to make the point that there's just something about the Valley that really, really does make it the center of everything. Like over-compensation, housing over-saturation, and lots of GroupThink (my words, not his :-). But that's precisely what makes open source so attractive - the prospect of a product coming to resemble the disparate qualities of its disparate developer and user base. Who wants an open source monoculture? Not I. (Nor Dawn.)

Open source theolatry and the threat of monoculture

I've been troubled recently by persistent theolatry in the open source world. We're getting better, but we have a long way to go.

"Theolatry" is a non-word that I stumbled across recently while reading Thomas Hardy's fantastic Tess of the d'Ubervilles. It basically means the undue idolatry of theology/right thinking/doctrine in religion.

Every time I think we've moved beyond dogma in open source, I come across a blog, a hallway conversation, or something that makes me think we're back in the Stone Ages of open source.

My company, Alfresco, went 100% open source earlier this year. Not because we're open source bigots, but rather because it was a wise business decision.

When we compete with Microsoft and other competitors, it's on the basis of the strength of our product and open source as a superior way of doing business, not on the basis of ideology and FUD. Open source is about pragmatism, not dogma.

On a separate but related note, I've also been concerned by a creeping monoculture in open source business. Many open source companies use the same lawyers, same advisors, same VCs, and same business models. This is to be expected, to a certain extent. You want to have a leg up in starting any business - why not tap into the most experienced minds and money in open source?

I agree with this thinking. However, I don't think we're anywhere near saturation in good ideas as to how to run an open source business. I therefore worry when people (including me) come out with lists of the "Three Open Source Business Models" and such. Why three? Because we haven't thought of #s 4-25 yet. I'd hate to be the cause for impeding someone's thought progress toward the next big thing in open source.

Same thing with licensing models. There is no one right answer. (We use the MPL, though I prefer the GPL. You need use neither.)

So take a look at the succesful open source companies out there - Red Hat, SugarCRM, Alfresco, Digium, JBoss, etc. - and learn from them, but don't mimic them. Odds are, you're much smarter than any of us. Learn from our mistakes - don't copy them.

And you thought the SCO lawsuit was bad...

I'm all for world peace. And I admit to being Christian. (Though I never knew Christ also goes by "Steve." Guess I haven't been as diligent in my New Testament reading lately as I should be....) But I'm not sure this is the right way to achieve world peace. :-)



P.S. This is a real lawsuit that was recently filed in Utah. And I think it has about as much chance of winning as SCO does.

Microsoft: Shutting up the critics by opening up

Hell is feeling chilly today. Microsoft, long known to have the mark of the beast written in its forehead, has gone and done something that makes it feel like a Leave It to Beaver rerun: it has opened up Office file formats. (Aw, shucks!)

Well, not directly, but at midnight PDT last night, Microsoft released on Sourceforgea tool - the Open XML Translator - that translates Microsoft Office files into the Open Document Format, and vice versa. Few have been clamoring for this, but Microsoft was bumping into governments that had to offer ODF compatibility, even if just one citizen wanted it. (You can try it out here.)

Big news? I think so (though Microsoft does not - nary a word about the move on its news/press release page). It means that file-level lock-in can be made obsolete (though it does require people to actually use the tool - more on that below). It also demonstrates a real commitment on Microsoft's part to participate in the open source community: the Open XML Translator is being housed on Sourceforge (answering critics who thought its CodePlex a threat to Sourceforge), and is licensed with a BSD (not Microsoft) license. BSD is the most permissive of all licenses (and, hence, the least capitalistic).

Microsoft, in making this move, must have recognized that it would cannibalize little to none of its Office sales, because almost no one is going to bother to make the file conversions - having the ability to do so will be enough. The company also recognized that it now has a far bigger lock-in threat than Office formats ever aspired to be: Sharepoint. With Sharepoint, Microsoft can lock in a company regardless of the file formats that company uses - .ODF, .XLS, .DOC, .PDF, .ETC. Because Sharepoint creates a closed network of documents - it is lock-in at the network/corporate level, and is far more pernicious than Office could hope to be.

I assume this will change the world very little. It will, however, make it much easier for my company, Alfresco, to ensure 100% file compatibility when we do document conversions within our Enterprise Content Management system. I'm sure we won't be alone in taking advantage of the BSD license on Open XML Translator - it should open up a wide range of opportunities for companies in the content business.

Off-topic: Fabrizio vs. Matt: Round II

Fabrizio lost his last bet with me: Arsenal vs. Juventus. Now our respective teams (France and Italy) are playing each other in the World Cup final.

So, Fabrizio. You still haven't delivered on your last loss. Time to go double or nothing? :-)

Location matters?

Dana Blankenhorn has taken me to task for suggesting that open source companies in Europe need not kowtow to American VCs and set up shop in the US. Dana intelligently questions:

This leads me to a question. Would JBOSS have been likely to merge with RedHat if it were in France? RedHat is based in Raleigh, with offices in Boston, and Fleury chose the buy-out instead of going public earlier this year.

What kind of deal would JBOSS have made if it were based in France? What if it had been in San Jose?

I will argue that it would be a different deal. Where you stand does depend on where you sit. So if Silicon Valley were not home to so many well-funded VCs, how would America be doing in open source?

I take that critique and ask Dana another: Would Red Hat have been as interested in JBoss if JBoss were headquartered in Silicon Valley? Red Hat has never seemed to care much for the Valley. If the end-game is to be acquired by IBM, Red Hat, etc., by Dana's reasoning, it's best to set up shop close to them. Silicon Valley is not the center of their universes (for the most part). As a vendor, I want to be closest to customers. They are the ones that will make my company attractive to any acquirer or public market in the first place, not where my real estate lies. (And, if I take BusinessWeek's word on it, real estate hardly matters at all anymore.)

Good companies will always find a buyer, whether on the public markets or the private markets, no matter their location. I'm not sure why it matters where the VCs are - it's convenient for the VCs to be able to drive up 101 for board meetings, but I'm not sure VC convenience should be the metric by which a company determines its ideal headquarters. (A big apology to my VC friends! :-)

Also, by Dana's reasoning, no one but the US gets to benefit from open source (on the sell-side). That reasoning cannot possibly be right or even healthy for open source. Who wants open source completed built in America's interest and image? Not I, and I consider myself a full-blooded American.

Open source success: proof is not in the downloads

Fabrizio has a great post on a few critical elements to open source success. Fabrizio is CEO (and founder) of Funambol, one of the most interesting open source startups. (Think RIM/Blackberry killer.)

Fabrizio is a smart guy. I agree with most of what he says. In this particular post, however, I'm starting to question what he says about volume. (Which means I'm questioning myself, too, as I've said the same thing before.) Is it truly the case that only the biggest markets can support open source?

I don't think so. The more I do open source business, the less inclined I am to fall in with the prevailing logic that you have to have a massive market to commoditize. Because open source need not be about commofication. In fact, the best open source companies will be those that innovate new products/projects and, hence, markets. You don't need a "community" of millions to be successful - you need a committed community, whatever its size. And you need that community to license your software and/or provide feedback.

Funambol has had 500,000 downloads; Alfresco has had 300,000 in just 8 months. Does this guarantee us success? Of course not. I'm not even convinced that downloads strongly hint at success. There are all sorts of heavily downloaded projects that will never make anyone a dime, even when a company is behind them.

Why? Because at the end of the day, a good company is not about how well it gives things away, but rather how well it converts would-be users into happy buyers. This means that the company's product must be exceptional. It's not good enough to be a cheap imitation of a good product. Open source products should be on par or better than their proprietary counterparts. Many are. (So, I would argue that Fabrizio is successful because his team has built a great product and people want to buy it. Not because they give it away. Is there a correlation between how good a product is and the number of downloads it gets? Sure. But downloads don't automatically translate into sales.)

There is no magic pixie dust in open source that turns weak companies into strong ones, or lame products into good ones. It still takes time, as Fabrizio indicates, and a lot of hard work. How can you evaluate whether an open source company is successful? The same way you measure a closed-source company: sales/customers. Which is why Funambol is doing great.

JBoss/Red Hat sued, and still the sky doesn't fall

If you're a Red Hat employee, you knew that something was amiss last week when the stock price entered into a 10% nose dive. It wasn't the quarterly results that were at issue (not really), but rather a lawsuit against Red Hat for patent infringement in JBoss' Hibernate 3.0. The patent in question involves an "Object model mapping and runtime engine for employing relational database with object oriented software."

The company behind the lawsuit, FireStar Software, has at least one thing in common with SCO. It, too, lacks a real business, though it's not as bad as SCO on that count. And it, too, has a past with Microsoft, though I emphatically don't believe Microsoft has anything to do with this lawsuit. It's just one piddly company suing a great company to try to make up for its lack of success licensing software.

The real story here is the non-story: open source companies can get sued for patent infringement, just like everyone else, with source code availability being a complete non-issue in the equation. JBoss isn't being sued because someone nefariously dropped code into the Hibernate code base - that's not possible with any credible open source project. No, they're getting sued because (allegedly) one of their developers wrote code that (allegedly) violates FireStar's patents. The suit could have happened to anyone. It just happened to happen to JBoss.

Red Hat's stock will recover. Look at the company's financials: it has hit the ball so far out of the park that it's now orbiting the planet. This is a momentary blip. Unfortunate, yes, but part of being a grown-up software company is that every loser and their dog will sue you. There are worse things in life.

Off-topic: The winning mentality

England just lost their quarter-final match in the World Cup. They didn't lose to Portugal, the team they were playing. They lost to themselves. When the match started winding down toward a penalty shoot-out (about 62 minutes into the game, mind you, when Rooney foolishy got himself red-carded), they had already lost.

Crouch (Yes, I know I think he's rubbish as a player) and Lennon (despite the fact that he plays for Tottenham, he's fantastic) were the only players on the field - besides the England defense - who believed they could win. Lampard, so amazing for Chelsea, has been MIA in the World Cup. Gerrard, such a fighter for Liverpool, got religion in mid-game and prayed for the end. And Beckham's hair was mussed up.

So when Lampard, Hargreaves, Carragher, and Gerrard took their PKs, small wonder that only Hargreaves put his in. He wasn't part of Sven's starting 11 for most of the World Cup, and so hadn't been infected by Sven's losing ways.

What would I have done differently? I would have put Lennon on earlier. You can't play Beckham just because he makes one free-kick per game. You need someone who is going to work all 90/120 minutes. Someone with energy.

I also would have put Walcott in for at least the second overtime. He's completely untested in professional football, but he has pace, and Lennon's pace against Portugal was the only thing that seemed to dismay them. So give them an insanely fast player to try to score, rather than hoping you can win on penalties. (In case you didn't know, England has been knocked out of nearly all tournaments in the past decade or so on penalty shootouts. They have zero confidence in PKs - why not try to win before you get to that point?) I would have replaced Lampard with Walcott - let Lampard rebuild his confidence in some other game. Not this one. Not with the game on the line.

Anyway, I know 98% of those who regularly read this blog have never watched a football/soccer match, and so couldn't care less about this post. I was just so distraught by England's foolish loss that I figured I'd get it out.

At least now I won't be conflicted when France spanks Brazil, giving them an easy game against Portugal (which is not a team worthy of the semi-finals - they hardly tested England, and that's saying something, given how poorly England has played).