Entries in the '' Category

Cloud Computing and the Future of Open Source

I “met” Phil Simon earlier in the month and have been following his blog, twitter posts, and  cartoons ever since.  Phil’s been in enterprise software a lot longer than I have, and now he’s writing about a variety of interesting topics about technology.  We started talking about cloud computing and open source — and I just had to put in my two cents.  So I did my first guest blog post about cloud computing and open source on Phil’s blog.  I hope you’ll take a moment to read it and browse the rest of Phil’s site.

Online Music and Open Source Business Models

In this part of our series on An Open Source Business, let’s take a look at our friends in the online music space and see what we can learn from them.

The Deal recently had an article about online music startups which should strike a chord with anybody who’s thinking about or trying to make a business out of open source.  Look at what they had to say:

“huge numbers, lots of hype, a surfeit of hope and a major chance of failure… some of the business models are inherently economically unfeasible… It’s completely unsettled and more and more fragmented…The rules of the industry and the economics of the industry have completely changed…Technological advances offer more and more delivery mechanisms, user options and wizardly new features…However, just who can make money off all this is almost as uncertain now as it was five years back…Everyone is gambling there will be a way to monetize distribution of recorded music, But no one has come up with the solution…Last year’s great hopes are this year’s busts.”

Sound familiar?  It should.  In a nutshell, open source business models share the same strategic problem that these online music startups have: how do you make any money when most of what you provide is available for free? Let’s look at the ways:

Free the Software, Sell the Services

Just about every commercialized open source project follows this business model.  The software is free, but the developers charge for services such as support, training, customization, and software development.  Sometimes the services are “productized” into manuals, seminars, installation CD’s, and packaged support, but the idea is the same.

This model works well…to an extent.  For example, we’re the main developers of opentaps Open Source ERP + CRM, and we’ve found that users are indeed willing to engage us for opentaps-related services because of our experience and knowledge with the system.  However, we’ve also found that users are willing to hire us mostly for customizations which are unique to their needs.  We’re still responsible for the architecture and user interface of opentaps ourselves, and that’s why since the release of opentaps 1.0 we’ve invested in everything from integrating Spring, Hibernate, and the Google Web Toolkit to building a Domain Driven Architecture.

Like the Free Version?  Please Pay Us for Even More!

Many open source software developers, and virtually all open source software companies funded by venture capitalists, engage in the “commercial/open source” model.  An open source edition is available free of charge to attract potential users, and a fancier commercial version is available for pay.

This is not an easy business model.  Let’s go back to music as an example.  I like Pink Floyd, but if you gave me The Dark Side of the Moon for free, would I pay you for Ummagumma, The Final Cut, and every other song by Pink Floyd?  No, I wouldn’t.  (Another example is travel: how many people actually pay for First Class?)

But perhaps the best evidence that this is a difficult business model comes from the commercial open source companies themselves.  Compared to a few years ago, their websites are de-emphasizing the open source version (sometimes you really have to look even to find the download page), and their “community edition” licenses are increasingly restrictive.

Nevertheless, I think this is a model which could be very successful if two conditions are met:

  1. You must have a very large open source user base.  Think MySQL.
  2. You must segment that user base carefully and identify the unique needs for your “enterprise edition” product.  The need must be fundamental — a little bit of eye candy and a few cool features alone won’t be enough.

Be careful, though: if you execute this model incorrectly, you could easily lose the goodwill of your open source users and unwittingly give away a viable commercial product for free.

The Alchemy of Open Source

There is a famous story of the Stone Soup, where many free ingredients came together to make an amazing finished product.  Lest you think it’s just a fable, Red Hat and Ubuntu do exactly that–they’ve combined major open source projects such as Linux, Gnome, Apache, Firefox, Thunderbird, OpenOffice, and MySQL and built major businesses from them.

This is the business model we’ve chosen for opentaps so far.  We’ve built opentaps from major open source projects such as Apache, Funambol, Google Web Toolkit, Jasper Reports, Pentaho, MySQL, PostgreSQL, and too many others to name here.  We’ve had to be patient at times, but over the years, we’ve grown as all those other projects have matured.  Amazingly enough, these open source projects have put us years ahead of many commercial ERP systems technically and enabled us to build opentaps sustainably, so that we now have a fully integrated ERP and CRM system with business intelligence, ecommerce, and mobility integration without any VC funding.

But this is not an easy business model to execute.  You must be willing to understand other open source projects and have the technical ability to work with them.  Most importantly, you need patience.  With this business model, you are growing with the community of open source projects.

In the End . . .  Just Make it Better

No matter what business model you choose, ultimately you’ll succeed if you make technology easier and better for your users. In the online music world, there actually has been a great success story — iTunes.  They’ve done it by making downloading music easy and fun.  So learn from them.  If you can make software easy and fun, you will be successful.  Next to a great product, the business model is just a footnote.

In the next part of An Open Source Business, we’ll take a look at marketing strategies for open source software.

Retail Industry and Open Source ERP

A group of graduate students from the Lancaster University in Lancaster, UK contacted me last year regarding a research project they were doing. They wanted to compare open source and commercial ERP systems for the retail industry and evaluated opentaps Open Source ERP + CRM, openbravo, and Microsoft Dynamics NAV (Navision).

They were kind enough to share their results with us, and you can read it at Opentaps In Retail. I hope you would find it interesting.

Quick Comparison of Magento vs Spree eCommerce Platforms

We’ve been working on an integration of the Magento e-commerce platform for opentaps Open Source ERP + CRM, and some of our long-time users have also talked about integrating opentaps with Spree. I took a quick look at both and make some notes about them. Since we’re not developers of or service providers for either one,  and we plan to support integration with both in opentaps, I hope you’ll consider this an unbiased if somewhat “bird’s eye” comparison of Spree vs. Magento.

Spree

Spree is lightweight and easy to use, and the user interface for both the online store and the backend administrative module were quite intuitive. There is a good amount of documentation on the Spree website, and the authors of Spree seem really interested in helping you understand their system and work with it.  Their BSD license is one of the least restrictive open source licenses.   There is an active community around Spree, as evidenced by the Spree extensions available.  Finally, Spree is written in Ruby on Rails, which is a very well-thought out web development frameworks.

Magento

Magento is a much bigger application than Spree.   Its  online store is also very intuitive and easy to use, but it’s altogether more polished and commercial-looking than Spree. The backend administrative applications are bit more complex, though. The free documentation available seems to be just  the Magento wiki, which has a lot of content available but is not as consistent. There are also several books on Magento, ranging from to Magento: Beginner’s Guide to The Definitive Guide to Magento and php/Architect’s Guide to E-Commerce Programming with Magento. (Note: I haven’t read these books yet and can’t give them any recommendations.) Finally, Magento is written in PHP and the code seemed well-organized on first inspection, which means that a good developer should not take too long to get familiar with it.

Magento has a  commercial/open-source licensing model, and the free version is licensed under the OSL 3.0 license. The OSL 3.0 is also a true open source license approved by the Open Source Initiative,  but it is more restrictive than the BSD and the GPL license. (See the GNU Project’s comments about the OSL, for example.)  Still, do not view this as purely negative. If the commercial/open source licensing model can support full-time professional developers to work on Magento’s open source version, then ultimately it would benefit most real end users of the open source Magento  e-commerce platform.

The biggest advantage for Magento, though, seems to be its large number of third party modules available. There are over 1300 add-on modules available for Magento.  (And the opentaps-Magento integration will soon be one of them!)  Although most of these are commercial (as in “for pay”), and many of the free ones are in “beta” status, there still seems to be a lot of stable, free modules available.

How to Choose?

My personal opinion is that this comes down to a decision between Ruby on Rails and PHP. You should ask yourself which one you would prefer to work with and feel more comfortable with. However, keep in mind that while Ruby on Rails has been a very successful web development framework, PHP is simply the most dominant one today.  (See for example O’Reilly’s State of the Computer Book Market and the TIOBE Software Index.)  Therefore, there are many more developers, service providers, and add-on modules for PHP than Ruby. For example, Facebook’s developer API is mainly for PHP.  Until Ruby on Rails comes up with a “killer app” that does something which PHP fundamentally is not well-suited for, I would not expect this to change.