Open source and software licensing

It seems that SCO is making another attempt to hurt the open source movement by claiming that the GPL is unconstitutional and violates federal patent and copyright laws.  While many are not concerned and call this a publicity stunt by SCO, the discussion of open source software licenses does remind me of a panel that I recently saw at the Goldman Sachs Software Retreat 2 weeks ago.

On the panel you had representatives of RedHat, MySQl, and JBoss combined with the perspective of a large IT buyer, the CTO of Goldman Sachs.  While I will not fill you in on all of the gory details, one thread did stand out in my mind.  It goes like this:

It seems that many of the bigger open source players are building out their own stacks ala Microsoft and others in the pursuit of growth and profits like traditional closed-sourced software companies.  Isn’t this the antithesis of what open source stands for?  Rick Sherlund, Goldman’s software analyst, says that it makes sense from a financial perspective since it allows vendors to cross-sell and lock-in the customer – customer retention is a good thing after all, isn’t it?  While all of the open source players did their best to dodge this question and claim that they are really open, MySQl was the only company that really seemed credible here as its goal was to be part of everyone’s stack, including the Microsoft .NET one.  JBoss and RHAT clearly seemed to be building their own middleware and open source stacks while at the same time claiming an open architecture. 

The interesting point was served up by Michael Dubno, CTO of Goldman Sachs.  He specifically told the vendors that the danger of the open source stacks is that it does create lock-in and that open-interoperability is what is most important to him.  He will go somewhere else if the open source guys end up limiting his options-he needs great service not extra features.  Moving on, he points out that the biggest gaiting factor for him in terms of adopting open source is making sure the legal issues will not come back to haunt him.  Goldman reviews every license agreement and makes a determination of which licenses make sense and which do not.  What Michael wants is integration from a legal perspective, not a feature perspective.  He claims the biggest cost to Goldman is not 2 products, but the cost in service and supporting 2 different contracts-he wants more standardization of contracts.

I found this to be an interesting point. I have seen a number of open source related software plays and it seems that many are trying to create their own unique twists on licensing.  While Goldman’s CTO is one data point, I would encourage companies looking to open source some of their software to try not to be too cute and design their own unique open source license but rather look to leverage existing ones like GPL.  One of the biggest barriers to a large enterprise using your software will be the software license itself.  The other point is to not forget why lots of companies are using your product in the first place – be open!

The train is leaving the station

Early stage companies have to be nimble and disciplined when creating and releasing product.  One of the important decisions a startup can make is how it chooses to manage its product releases.  In a software company a product release affects everyone.  A mistimed release can severely impact sales, cash flow, and the company.  We had a thorough discussion in a board meeting this week on this very topic.  I have to admit I was quite pleased with our new VP Engineering as she put forth her methodology and process, shared below.

There are a couple of different ways to manage engineering releases.  One engineering release is date driven, the other is content driven. In a date driven release, the team knows when the next release is out but does not know exactly what will be in it.  The release runs like a train schedule, whoever makes it to the station on time is part of the release.  The other release is content driven; the team knows what is in the next release, but does not know the exact ship date. The release runs more like an airplane shuttle, it takes off only when full.

While I may be oversimplifying the issue, the one that I like my companies to subscribe to is the date driven one.  Of course, just because it is date driven does not mean that there isn’t a highly focused theme.  It just forces the team to clarify the absolute minimum requirements necessary to deliver the right product for the market.  It also discourages feature creep and encourages highly disciplined prioritization.  Most importantly, having a date driven release can get everyone at the company aligned.  Everyone knows the ship date and sets their schedule accordingly to ensure that all pistons are running as GA hits.  This means marketing has to have its collateral ready, upgrade program in place, and product launch schedule set.  Sales knows when it can start telling prospects about the new product and time it appropriately so it can get customers lined up for the next quarter without delaying sales in the existing one. Engineering, of course, needs to deliver product and not get distracted.  While all of this discussion on product releases sounds great, none of it really matters if you do not have the experienced team that can manage them and instill the discipline.  So as you think about your next product release, think long and hard about whether you want the trains to run on schedule or the airplane shuttle to be full.  You know where I stand on the issue.

Bad customers can kill your business

It has been awhile since my last post as I have been busy with a number of board meetings.  It is so hard to find time.  Anyway, one thought I wanted to share with you is a discussion we had in one of the meetings about the balance between closing large deals and adding new features.

More often than not, you will hear a sales person complain about their product and tell corporate that if they had these 5 features, they could sell more.  Since sales people look for the path of least resistance, they typically go back to marketing and development to ask for the fixes and changes to close a new customer.  Many times, management, in pursuit of meeting their numbers, will oblige and make the requisite changes to land a new customer.  If you fast forward into the future and continue this behavior, you will end up with a company that has a number of customers but also a support nightmare-too many different versions of a product which makes it difficult to maintain and support from a development and customer service perspective.  In addition, you end up constantly delaying the next release of your product as precious resources get sucked away.   You also have lots of features that the market does not want.  Finally, the profitability for each customer goes down significantly as you add new features just to close deals.

In the long run, having too many of the wrong customers can kill your business.  The more experienced and disciplined team will not build a new feature for every customer but rather have a seasoned and proactive product management process for gathering data from the field and prioritizing feature requests based on market and customer need. In some cases, it may make sense to give a feature request higher priority as a number of prospects and customers have asked for it.  In other cases, you will have to make a decision of whether or not to build a one-off feature to close a deal or lose it to a competitor.  While every situation is unique, in general, you have to be extremely careful of going down the slippery slope of customized versions of your product for every customer as the one-off requests will suck up your resources.  It is easier said than done, but the simple rule is don’t add features if the market does not need it.

In the end, I never like my portfolio companies to end up in feature/function wars.  That is a losing proposition.  Rather it is important to take a step back sometimes to see if you can change the playing field on your competition by positioning yourself differently.  This includes understanding the customer and market, pitching a longer term vision and product roadmap that maps to the customer and market needs beyond today’s purchase, and then making them feel that tactically you have enough of what it takes to solve their problem in the short term.  If done right, you can help the customer understand why one missing feature today may not be so critical since your company is the only one that can meet their needs in the longer term.

Delivering software as a service

Adam Bosworth has an interesting post on the evolution of software and why software delivered as a service will be the business model of the future. As you know, I have always been interested in this trend since my first post in October 2003 and since I invested in a number of companies in 1998 and 1999 like LivePerson and Expertcity (GoToMyPC) that subscribed to the ASP business model. What I have learned and what Adam points out is that it comes down to the customer experience, making a product easier to use for a customer and evolving it as quickly as possible to meet the customer’s needs. Software delivered as a service enables that and packaged software does not. In the time it takes Microsoft to deliver an application (went from 1 year to 5 years), a company delivering software as a service can deliver 60 iterations of its product. As Adam points out, “things that breed rapidly more quickly adopt through natural selection to a changing environment.” I have never thought about software in evolutionary terms, but it certainly makes sense.

From an evolutionary perspective, the ASP business model is quite interesting to examine. While every piece of software should not and will not be delivered as a service, it is also quite clear that customers are tired of buying expensive software products with large upfront licenses, expensive hardware to purchase, manange, and maintain, followed by expensive professional services to get the product up and running. From this backdrop, it is easy to see why reducing complexity and simplifying technology for customers is a big driver to more rapid adoption of products. It is also easy to see why reducing complexity for the customer also helps reduce complexity for the vendor, lowering the friction to sell and deliver its product. This means a more capital efficient business model, one which would hopefully scale much quicker and cost less to build product, sell, and support customers. For the vendor, it makes it:

1. Easier to sell
-shorter sales cycle-do not have to test extensively in a customer’s environment
-lends itself to telesales, can demo over phone and web, do not need a huge sales infrastructure to close deals (just need quota bearing reps without a huge staff of sales engineers and professional services guys to get the job done)
-not a capital expense, usually sold as monthly or annual subscription which can many times be taken out of business budget as opposed to IT budget

2. Easier to install
-no messy installation process, long testing process, or even waiting for hardware to be delivered to customer
-can leave a customer and simply point them to a URL, train them over the phone, and get them up and running
-all of this means that the business can scale rapidly

3. Cheaper to support
-browser-based delivery and richer client interfaces like DHTML make it easy to use for the customer=less training=less customer support costs

4. Easier to integrate
-standard APIs make it easier for software delivered as a service to integrate disparate systems
-once again, reduces costs to deliver product to customers and also removes obstacles to getting customers

5. Cheaper to build
-versus a few years ago, you now have much cheaper bandwidth, storage, servers, and software
-think Linux, Intel boxes, cheap bandwidth, commodity software stacks, and smarter entrepreneurs changing the economics of building and delivering software as a service.
-the economics speak for themselves

Given this, it seems to me that the ASP business model will only get more attractive with time. The ASP model makes it easier for vendors to sell and get customers up and running, lending itself to a more scalable and profitable business model. While I am not suggesting that every product will evolve this way, it is clear that simplicity rules. The ASP model is certainly one way of accomplishing simplicity. Appliances are another way. Packaged software with huge installation costs is not.