Two Can Play this Game - Trial By Fire 2

Part two of a continuing series on unique business challenges facing open source projects and businesses.

Let's say that you have a successful open source project or business: Customers love the low cost and flexbility. Venture capitalists are beating a path to your door. Even slashdotters think you're cool.

Then, one morning, you wake up and find that--

A commercial ISV waives licensing fees on a competing product.

Think it can't happen? Ask yourself this:

1. How many razor companies give away the razor to sell blades?
2. How many printer companies give away the printer to sell cartridges?
3. How many cell phone comopanies give away the phone to sell services?
   

In every industry, imitation is the sincerest form of capitalism. If there really are enough profits from services to forego licensing, how long would it take your competitors to figure it out as well?

This is a risk every open source project and open source software company needs to plan for.

If your open source strategy is just about the lowest price, then you have a real problem. Once your competitors respond by waiving licensing costs, what advantage do you have?

Fortunately, open source can be about more than just price. Because it creates a high level of user involvement, an open source project can provide some unique benefits that are priceless. For example:

• Can community testing and patches help you produce higher-quality software?
• Can community input focus your development efforts and make you more efficient?
• Has the open source development process made your code more modular and cleaner?
• Does your source code really offer customers greater flexibility?
• Can you build a global, distributed development model and innovate faster, better than your competition?
• Are your users more loyal because they are part of a real community, rather than just passive licensees? Will they go evangelize for you?
  

In other words, do you have a real community, or do you just offer free stuff? This will determine whether your project (and company) is more like Amazon.com or a Pets.com.


In the end, your commercial competitors may be doing you a favor by waiving their licensing fees. They will draw away users who were just interested in "free." Now you can focus on a core customer base which really appreciates the true value of your offering. By re-focusing on its needs, you will eventually emerge stronger.

Open Source Transitions - Trial By Fire 1

Part one of a continuing series on critical challenges that are unique to open source projects and businesses.

In the beginning, an open source project is created by a single developer, a small group, or a startup. The initial creators write the code, put it out there, and hope that others will adopt it. In the meantime, they do everything from designing new features, writing code, reviewing and committing them, fixing bugs, writing documentation, and providing support on mailing lists.

Unfortunately, it usually ends here. Most open source projects languish and are eventually abandoned by their creators.

Fortunately, though, this open source project succeeds. Many users download it and start working with it. The mailing lists get busy. After a while, a community develops around the project. The original creators bask in the glory of their successful project and are (hopefully) successful themselves from it, selling everything from books to consulting services to value-added commercial products.

Then, the project comes to a transition point. As community members become more involved with the project, they are ready to play a bigger role. They start planning and developing new features themselves, writing their own documentations and how-to guides, answering emails on the mailing lists, and so on.

What happens now?

At a minimum, the project creators need to pull back from their earlier hands-on roles. They need to let others do the day-to-day work of fixing bugs, writing documentation, and providing support. At the same time, they must still shepherd the project. Only they can set the right direction for the project. They still must invest in strategic development to push the project along. They must maintain high standards for the documentation, code, and support. And they must do all this while continuing to build and nurture the community.

This is not easy to do. It is very similar to the transition that most entrepreneurs face as their businesses grow and they must relinquish day-to-day tasks to focus on the bigger picture. Many entrepreneurs can't or doesn't want to do this and eventually move on.

This transition is even harder when the original creators have built businesses around their project. They may be selling support services, documentation, or commercially-licensed versions with premium features based on their open source project. What happens when the community starts to create free (or nearly free) alternatives to the founders' offerings? Here are some options:

1. Squash the competition. The knee jerk reaction. Use your position as the maintainer of the project to shut out competing efforts. Or, spread FUD around community efforts, with statements like "It's so great to see all this involvement, but..." But is this productive? Should you really be expending valuable resources to create something that would otherwise be free?
   
2. Keep competing offerings. Inertia at work. Even though the community has produced a free alternative, you continue to spend money to develop, maintain, and sell your version. Hopefully, you can leverage your position in the community (essentially, your brand) to do so. You're still paying for something that should be free, though. And if your project continues to be successful, the community will eventually grow large enough to overtake you. In that case, your expensive but inferior offerings could actually end up damaging your brand. (This has happened to a major vendor whose name I will not mention here.)
   
3. Replace your offering with the community's. Like Gordon Gekko said in Wall Street, "Never get emotional about a stock." Once better code, features, documentation, or support become available from the community, drop yours and adopt its. This would, however, significantly affect your ROI. It may also embolden others to start competing with you.
4. Give back to your community. Periodically gift proprietary code and documentation back to the community. You can create goodwill, enhance your brand, and eliminate potential competitors. But then how do you convince someone to continue to pay for proprietary offerings when, sooner or later, you might make it free?

The challenges in managing this transition successfully are:

1. Can the original creators of the project let go of their own ego and emotions and let others play a bigger role?
2. Can they encourage the right people to get involved? Can they filter out weak ideas while avoiding a fork in the project?
3. Can they repeatedly re-focus their resources correctly on core versus non-core competencies? Can they successfully extract value from their core strengths, while getting others to produce non-core offerings?

This is not an easy transition for any entrepreneur. It is especially difficult with open source projects, since people don't have to work with you.

The Next Microsoft

Apparently, a popular question asked of hopeful software start-ups is:

How will you become the next Microsoft?

One imagines a young, optimistic entrepreneur, slightly flustered, starting to talk about how he will eventually one day own a dominant technology platform. Ahh, the dreams of youth.

It is a very natural question to ask—Microsoft is without doubt the most successful software company of all time. It owns the core platform for PCs with Windows and Office, dominates access to the Internet with Internet Explorer, has a large presence online with MSN, and commands a vast following in the developer community with Visual Basic, C#, and Visual Studio tools. Why wouldn't someone want to be the next Microsoft?

Imagine, though, if someone had asked the young Bill Gates and Paul Allen:

How will you become the next IBM?

Did two flustered youngsters describe a strategy to build a world-dominating hardware business and bundle software and services along with it?

Strange as it may seem today, this question was just as natural back in those days. IBM had dominated all of computing, with its mainframe computers and hardware, OS/360, business applications, and services. It was so dominant that it too was the subject of lengthy anti-trust litigation. And even in the late 1980's, people spoke of "starting the next IBM."

Indeed, someone must have been asking this question back in the mid-1970's, because most successful startups of that era, including DEC, Wang, Data General, followed the IBM model and offered bundled hardware, operating systems, applications, and services. Microsoft was actually an oddity: not only did it specialize in the then non-existent personal computer sector, it only produced software. The rest, as they say, is history.

In fact, both IBM and Microsoft are products of their times. The IBM model was a product of the 1950's, when computing itself was in its infancy. It bet big on the very concept that businesses would want computers and produced such great hits as the System/360 mainframes, OS/360, JCL, MVS, COBOL, etc.

The Microsoft model was also a product of its time, this time the late 1970's. Microsoft realized that, unlike IBM's big corporate computing customers, the PC user will care a lot more about ease of use and features. It bet big and won big with DOS and then Windows, standardized the nascent personal computer industry, and used that standard to its fullest advantage.

Similarly, today's startup must be a product of our time. So, maybe a better question to ask is: “if Bill Gates and Paul Allen were starting over today, what kind of a business would they start?”

My guess? They would sit around a dinner table and ask themselves:

What do eBay, Yahoo, Google, PayPal, iTunes, and Skype have in common?

What do you think?

Can't We All Get Along?

This part is a true story:

Last night I was on an American Airlines flight from Newark to Los Angeles, and it was delayed for three hours because of a faulty altimeter. (An altimeter measures the plane's altitude.) Apparently, American did not have an altimeter in its Newark maintenace facility, so it had to have one driven from JFK, which is an hour away on a good day. Needless to say, yesterday was not a good day.

When we finally pulled into the gate at LAX around midnight, I went up to the pilot and spoke with him briefly. He confirmed what I had suspected all along:

1. The Boeing 757's altimeter is a standard part which is used by all the major airlines, including American, United, Delta, and Continental.
2. Since Newark is one of Continental's main hubs, there were probably several altimeters in the Continental maintenance facility.
3. If American had been able to borrow or buy an altimeter from Continental's facility, we would have been in the air with only a one hour delay. There are, however, no agreements between airlines for sharing parts and maintenance resources.

This part is my analysis:

It seems that if (1) and (2) above are true, then American and Continental could both benefit by sharing Continental's maintenance facility at Newark. American has a relatively small presence at Newark and could eliminate the high fixed costs of supporting its own maintenance facility for such a small presence. Continental, in turn, could earn a higher return on its larger maintenance facility at its Newark hub by charging a premium for these parts to the other airlines and improving parts turnover. And the 200 passengers on our flight last night would have been less irate, and the unfortunate flight crew would not have had to face their ire.

But I was not one of the irate passengers. First of all, I had a great weekend in New York and was glad to be coming home. Second of all, from what little I know, I thought we really did need the altimeter to fly. Finally, because I'm in the software industry, I realized that I should not be the one to cast a stone.

Think about it. The airline industry actually has standard parts such as an "altimeter." They have the technology standards required for interoperability. What they are lacking is the social organization for interoperability, in the form of maintenance facilities and inventories sharing agreements.

The lack of sharing agreements between airlines is a high hurdle to overcome, of course, but not nearly as high as those for interoperability in the software industry. In our industry, many participants continue to fight even common technological standards, trying to put up walls and moats around their own proprietary technologies and standards. Needless to say, a social organization or culture of sharing is much farther away still.

If we, as customers, would like that from vendors in other industries, why wouldn't our customers want the same thing from us? Don't our customers want the ability to select and use applications and components from a variety of vendors to meet their needs?

Are we going to be late getting them there as well?

Open Source Business Conference (OSBC)

My friend told me that the first thing he looks for in an industry is a conference. "Once there is a conference, you know it's a real industry."

So it was with great excitement that I went to the second annual Open Source Business Conference. In the Gilded Age splendor of the Westin St. Francis, about 700 excited open source enthusiasts, curious to cautious to optimistic venture capitalists, hopeful entrepreneurs, sagacious lawyers, and fast-typing journalists mingled.

Here's my summary of the conference:

1. Open source is a legimitate business now. Few at the conference tried to justify that "free" can also mean "business." (In that sense, software has finally joined the rest of American industry, where businesses are built on things other than intellectual property secrets.)
   
2. The users, in this case CIO's of some very large organizations, were very excited about open source and simply wanted more of it--more projects, more support, more services to help identify projects. (Though, to be fair, they are a biased sampling of CIO's out there.)
   
3. Venture capitalists have seized on the fact that open source is a great distribution model and could potentially do away with the inefficiencies of sales and marketing in software. One statistic cited was that software licensing revenues are 76% of software sales & marketing revenues. Translation: users are paying vendors to sell to them. This is fundamentally inefficient, and they view open source as a direct, more efficient model of selling software.
   
4. Business models of services around open source are well established. (Curiously, in the Geoffrey Moore talk, the audience rated "open source service businesses" as more mature than any open source project such as Linux or MySQL.)
   
5. There was also active interest in deployment tools, management tools, devices, appliances, on-demand (hosting) businesses around open source software.
6. There was real disagreement over the future of open source in applications. One VC, the keynote speaker, was enthusiastic about it. The other VCs, in the panel discussion, were less so.
7. When a correspondent from The New York Times asked the VC panel why this time it would be different, one responded that the valley is a "manic-depressive" place. All of the VCs are publicly cautious about open source. One noted the open source is fundamentally "capital frugal, intellect intensive" (which I agree with very much.) At the same time, they were lots of VCs there talking to projects and entrepreneurs, so who knows?

I came back from the conference wanting more. It seems that the "open source" industry, if there is indeed such a thing, is still in the early stages, and people are still groping at the right business models. It's wonderful that services, appliances, deployment tools, etc. are well-established business concepts now. It's wonderful that VCs are willing to fund them.

But the conference largely skirted the ultimate power of the open source process: how will it fundamentally alter the dynamics--the economic relationships--in the software industry? In other words, not just sales and marketing, but also how software could be created and financed and how software companies can be organized and managed.

Could open source created a more frictionless model for the software industry? Instead of requiring huge investments to produce software and then hoping that users will buy them (and investing more money to convince people to buy them), could software be more of a demand-driven industry? A similar transformation is occurring in just about every other industry, from manufacturing to retailing to construction. Could it also happen in software? Could open source make it happen?

And then, from there--could open source unleash new creativity and help create whole new ways that software can benefit people and businesses? Software has become a living, breathing part of all our lives and all our businesses. Such creativity could surely be the greatest gift open source could bestow upon us all.

I think it could do both--create a more frictionless, demand-driven, "pulled" software industry and unleash new creativity in the industry. It will take new forms of not just software development but also organization of the industry. It will change how software companies are started, financed, and managed.

And that's the most exciting thing, as I look ahead to the future of open source. I hope to be part of inventing that future.

Open Source and the Road to Mainstream

I keep coming back to the notion that open source is following its enabling technology, the Internet, from academia into the mainstream. The road to mainstream will, in my opinion, be similar as well. Specifically, it will resemble the road of the online retail industry.

In the beginning, of course, nobody believed that people would buy things online. Then startups such as Amazon.com showed that people, in fact, did buy things online, and eCommerce took off as its own industry. (Remember the days of the "Internet analyst"?) Next, established retailers responded by setting up separate online subsidiaries of their own, partly in hopes of cashing out in the dot-com boom, but also because they could not integrate online easily with their stores. (Remember when online purchases couldn't be returned in the stores?) Finally, eCommerce became mainstream, as startups such as Amazon.com have matured into multi-billion businesses, and established retailers such as Wal-Mart and Staples have fully embraced online as part of their core business. Whereas once there was an "eCommerce" industry, all retailers today speak of "multi-channel", "bricks and clicks," "clicks and mortar" strategies of integrated selling through online, catalog, and store channels. The reason? Simple--that's what the customers wanted: lower prices and convenience.

What is interesting is that eCommerce became mainstream not because the startups displaced the established retailers, but because established retailers have fully embraced eCommerce. Consumers shop online at amazon.com as well barnesandnoble.com, target.com, staples.com, etc. etc. In fact, the top retailers from an annual list compiled by Internet Retailer, the trade publication of eCommerce, is a who's who of major established retailers.

Open source software will follow a similar evolution. Originally, of course, nobody believed there could be businesses around open source. Now we are past that and into the second phase and third phase, where venture capitalists are funding open source startups and traditional software vendors are responding with open source projects of their own. The logical final phase would be traditional software vendors embracing the open source model as an integral part of their business, taking from and contributing to open source projects. Then open source will simply be mainstream. It's not clear when this will happen, but it is a matter of time. The reason? Again, simple--what the customers want: lower prices, better software.

One really interesting company to watch is Novell. Here is a billion dollar software company that is literally betting its future on open source. It is not just releasing existing software to open source, but rather adopting open source as the core of its future business. If Novell succeeds at bringing open source to its customers and building a business around services, it will send a powerful message to the entire industry. If it does not succeed, it will offer some equally powerful lessons on how the road into the mainstream should be traveled.

On a closing note, Microsoft has also joined the open source community. In addition to sponsoring open source conferences, it has actually created its first open source project Wix, which has gotten over 120,000 downloads to date. No company understands the business and strategies of software better than Microsoft. It will be interesting to see where they go from here.

The open source community should give them a big applause of welcome.

Open Source and Software Business Valuations

Do Wall Street financial analysts understand open source?

The article Novell Gaffe Costly says:

"because license revenue is a key indicator of new business, while maintenance revenue reflects ongoing payment from current clients, the shift is disturbing."

It also specifically quotes an analyst as saying:

"the leading indicator of Novell's business -- software license revenue -- is caving in faster than previously thought, suggesting more severe market-share losses with NetWare and other products."

But how will licensing revenues continue to be the leading indicator of a software company's business under open source? More specifically, how will licensing revenues continue to be the leading indicator of Novell's business as it switches from proprietary to open source products?

Broadly speaking, software companies make R&D investments to develop products and then sell licenses to users, then follow through with services, support, and maintenance on those products. Licensing is thus a mechanism for a software company to recover its large investments in R&D. Software companies have huge operating leverage because the R&D investments are sunk costs bear no relationship to the number of licenses sold. In this way, developing software is rather like producing a movie. (Imagine that when you look at your programmer friends next time!)

Why do financial analysts focus on licensing revenues? Because, first of all, licensing sales have no marginal costs and thus huge gross margins. Second, and more importantly, licensing is a harbinger of the adoption base for the company's technology. Robust licensing sales indicate that the company's technology is gaining adoption. This adoption base determines whether the software company can derive future revenues from services or new products, and, critically, whether the company and its technology continue to remain relevant.

Of course, I'm sure there are some software companies where the only source of revenue is from licensing. I don't know much about this sector, but video games come to mind right now. For companies such as Novell, though, their products have significant future service revenue streams. Thus, for these companies, licensing is more important as a potential gauge of the adoption base for their technology.

Most open source companies, however, do not have licensing revenues. (Except for the few companies in the "dual licensing" business. My opinion on that subject does not belong here.) So right there, we need a different metric to measure the adoption base of their technology.

What about the high margins of licensing revenues? Does the absence of licensing necessarily imply that open source companies are in low margin businesses? Not necessarily either. First, because they can draw off a larger, open source code base, open source companies' investment requirements in R&D are also smaller. So, in a sense, they do not have to have licensing revenues to recover those investments.

Second, if their investments in open source community R&D help them build a stronger brand name and charge a premium price for services, support, and consulting, then I would argue they are earning very high returns on those R&D investments. If the adoption base of the underlying technology is large enough, they could potentially earn a far higher return on those R&D investments than most commercial software vendors ever could.

I hope this will convince some of my former Wall Street colleagues to sharpen their pencils.