Open Source in the Enterprise and in the Cloud

In a couple of weeks, I'll participate in a panel discussion on The Future of Open Source in Business. In preparation for that discussion, I figured I'd write down my current thoughts and solicit some feedback. I'll talk about two important trends relevant for the future of Open Source, but there are certainly more.

First, Open Source adoption in the enterprise is trending at an incredible rate -- Drupal adoption has grown a lot in 2009 but we saw by far the biggest relative growth in the enterprise. Fueling this movement is the notion that Open Source options present an innovative, economically friendly and more secure alternative to their costly proprietary counterparts. Second, Cloud Computing is a transformational movement in that it enables continual innovation and updating - not to mention a highly expandable infrastructure that will reduce the burden on your IT team.

Two years ago, when starting Acquia, we predicted this would happen so it is no surprise that Acquia's strategy is closely aligned with those two trends: Drupal Gardens, Acquia Hosting and Acquia Search are all built on Open Source tools and delivered as Software as a Service in the cloud. Combining Open Source tools and Cloud Computing makes for the perfect storm for success. It provides real value to end-users and it enables companies to monetize Open Source. It creates a win-win situation.

At the same time, I think we have an opportunity to go beyond that, and to redefine the Software as a Service model based on Open Source values, almost exactly like we started doing 10+ years ago with off-the-shelf software. Almost all Software as a Service providers employ a proprietary model -- they might allow you to export your data, but they usually don't allow you to export their underlying code. While a lot of these services might be built on Open Source components, they have a lot more in common with proprietary software vendors than Open Source projects or companies.

There is room for Open Source companies to disrupt this model, and it is probably not something that can be done without the help of Open Source companies. Drupal Gardens provides a good example of this model.

For example, users of Drupal Gardens can help improve Drupal Gardens, simply by contributing to Drupal. By staying close to the Open Source project, everyone can help shape the service. Along the same lines, we want people to be able to export their Drupal Gardens site -- the code, the theme and data -- and move of the platform to any Drupal hosting environment. By doing so, we provide people an easy on-ramp but we allow them to grow beyond the capabilities of Drupal Gardens without locking them in.

It is "Open SaaS" or Software as a Service done right -- it will offer enterprises a much more secure and low-cost alternative to proprietary counterparts and provides many Open Source projects the opportunity to have a much bigger reach. It creates a triple win scenario -- for the customer, for the Open Source project and the Open Source company -- in a way that wasn't really apparent five years ago. At least not to me.

Have you taken the 2010 Future of Open Source Survey yet? If not, please take a few moments to share your thoughts on where you think Open Source is headed.

Comments

mac (not verified):

I agree to a great extent. I would articulate more about the economical dimension, though. What should the business model be, for those companies wishing to challenge the "status quo" of proprietary code within SaaS?

What I mean is that while being "open" on software that is instrumental to run the business brings no harm to your competitive advantage, being "open" about the software which distinguishes you from the competitors has less obvious economical implications.

For example: Facebook uses PHP to develop their service and they contribute back to the PHP community with various tools and optimisations they developed. Yet, if they would release the Facebook code as "open" nothing would refrain a competitor to set up a "facebook2.com" site running the same software and offering the same functionality.

Unless your company earns money solely out of the paid support offered to deploy / administer the software you develop (see Canonical, for example), I do not see how a company could be profitable by giving away what their business is all about.

...or did I miss something?

March 2, 2010
Anonymous (not verified):

Not all software would be exported -- just the front-end, the part that the users actually use. In other words, Drupal Gardens provides the service of letting you set up a website easily using Drupal, but it lets you export that website once it has delivered the service so you can put it anywhere you want. Similarly, Cafepress might let you set up a store and then export it so you can install software on your website that will let you run that store natively (as opposed to running it in an iframe). Cafepress would provide the set-up service, and customers would receive the results of that service.

March 3, 2010
mac (not verified):

@Anonymous, if this is the case, then "disrupting the model" seems to me a bit of overstatement.

I appreciate and support the fact that DG allows you to export the entire codebase of the site, but this is nothing different than MS word allowing you to save all the formatting data of a document within the document itself.

What I mean, is that exporting the code of a site running on DG and then being in the situation of having to maintain it without the graphical interface offered by DG, is like saving a MS Word file and then having to edit it without MS word.

Let me clarify that I do not blame in any way DG for doing this: I like the DG project and I would contrarily be astonished if DG would do any different for the reasons I explained in my original reply. Yet, I feel that DG is not "disrupting the model" any more than Adobe did by making .pdf an open standard.

Again: don't get me wrong... I am not complaining or criticising in any way DG business model. I am just trying to call a spade a spade, nothing more. The real added value of DG is precisely the "building tool": stripping that functionality away from the exported code is understandable, appropriate, legitimate, ethical and much more... but is not exactly "disruptive of the model".

March 3, 2010
Dries:

Comparing a Microsoft Word document to an application feels like comparing apples to oranges to me. In my mind, the equivalent of the Word document in Drupal would be a database dump of your site. Neither the Word document or the database dump are an application -- it is just data.

With Drupal Gardens, we're exporting both the application and the database dump. We're currently only stripping Drupal Gardens' ThemeBuilder for reasons explained earlier, but we do export a fully functional Drupal 7 theme. At some point, we might be exporting the ThemeBuilder too. :)

March 3, 2010
mac (not verified):

Disclaimer: the reason for which I am persisting in trying to explain why I do not see the DG business model as "disruptive" is that I know you and your team care about bringing innovation in the sector you operate in, and thus I believe understanding what (some of) your users think might be beneficial.

I see where your "apples and oranges" comment comes from. I will therefore try to articulate more why I chose to draw a parallel between MS office (MSO) and Drupal Gardens (DG), as I still see it! :)

I am looking at the issue not from a technological standpoint (data vs. code) but from a functional perspective (tools vs. products). For me there are three layers to consider:

The "fish" level represents the final point of the process. In MSO that might be the printout of a spreadsheet, in DG that might be the page as loaded by the browser.

The "fishing rod" level represent the "modifiable" format of the product. In MSO that would be the document file (which contains data and possibly code in the form of macros - but this is irrelevant to my point), and in DG that is the "dump" of the DB + code. Both the MSW document and the Drupal installation can be modified according to needs, but the functionality that generated them is not included (There is not the word processor in the MSW file, and there is not the DG theme builder in the DG dump).

The "fishing equipment factory" level is represented by MSO and DG respectively. They are the "metatools" that allow the user to modify the "fishing rods" natively [With natively I mean that the user can modify the spreadsheet or the site with the same tool they used to generate them in the first place].

The reason for which - while I certainly appreciate the higher degree of freedom that DG offers compared to other initiatives - I do not see the "disruption" in DG business model, is that (for the moment being) the user choosing to leave DG will lose the possibility to use the tools he/she has been using to create the site (The same way the user leaving MSO would). In other words: a considerable portion of the user's know-how is not transferable outside of the DG platform (or outside the MSO suite).

In all honesty, I do not attach any ethical consideration to the above consideration. To me it seems a perfectly fair business model that says "If you find our service valuable you are welcome to be our customer. If you don't, you are free to pack up and move out".

My point is that keeping some features uniquely for your company and making that your competitive advantage, is a mainstream pattern in business, rather than a disruptive one. Again: I do not think that "disruptive" per se is any better than "mainstream", so do not take my criticism of the term as an attempt to diminish the DG business model.

I hope this clarify a bit where I come from.

In any way, I think that the last part of your reply contains a much more "disruptive" element: releasing the theme builder in the open would really be a deal changer. As I already expressed in my original reply, I am certain a lot of people would be curious to hear more about what that decision would entail in terms of business model and competitiveness for the DG project. If you would be able to convince your audience of the profitability of this model, DG could really lead a new trend in the sector.

Regardless of what you might think of all above, congratulations for DG. I am one of your beta users and I am definitively impressed! :)

March 3, 2010
Robin Millette (not verified):

My last employer was Evan Prodromou of Identica/StatusNet fame. It's no coincidence I decided to work there, since I'm all about free and open source software too. I think Evan would agree with much of what you're saying. Just 5 days ago, StatusNet launched their enterprise service and it's all built on open source software. Let's just hope the tide keeps on turning and everyone benefits!

Better business for all :)

March 3, 2010
Neil Cameron (not verified):

Here in London we are pretty excited about how enterprises are adopting Drupal. I wonder though about the impact this will have on the developers. Somehow it feels less "worthy" when a big corporation can use your hard work for free, compared to say an NGO or hobby group.

The reality is of course that NGOs will benefit from the corporate investment in developers and mean they get an even better Drupal product. But it might not always feel that way to the weekend developer.

March 3, 2010
Rudy Van Hoe (not verified):

Hi Dries:

Interesting analysis. Regarding Cloud Computing: at some point the difference/discussion between proprietary and open source becomes irrelevant in the sense that having open Cloud APIs will become more important: In this manner cloud services can be extended according to a open source business model, while the underlying cloud infrastructure might be a combination of open source and proprietary software. See also http://www.infoworld.com/d/open-source/how-use-open-apis-business-growth... in that regard

greetz

Rudy

March 3, 2010
Dries:

Good point. I agree that we need standardization of Cloud APIs -- portability at the infrastructure layer is complementary to what I wrote though, and doesn't change the desire to have portability at the application layer too. We need to address this at all the layers of the stack.

March 3, 2010
Christoph Weber (not verified):

From a consumer and enterprise perspective I think it all boils down to whether I can gracefully "survive" when my vendor goes under or decides to discontinue the service. I don't particularly care what technical underpinnings allow me to move between service providers, but it does matter a great deal that I can, and in a quick and painless manner. Vendors who can prove to me that I am not captive win my trust and money, those who don't simply don't get a second look. The internet and computer industry have been around long enough that most people are tired of being yanked around and ending up on dead-end streets.

Being a disruptive service provider then is being part of the open service industry, being really good at it, and offering the service at a competitive price, while making a decent profit. How that is done in practice is the secret or not so secret sauce. Touting your openness is definitely part of the winning combo.

March 4, 2010
Evan Prodromou (not verified):

Dries,

Loved this blog post. I absolutely agree that SaaS offerings based on Open Source have much greater value for users and organizations.

Let's keep up the good work!

-Evan

March 4, 2010
Jayme (not verified):

Nice post,

I agree on most of your views, open source in the cloud really offers a lot of benefits in improving & extending a product.
But also opens room for more error. At some level it might be dangerous for a company to rely on a cloud product/ api that is constantly evolving if code releases are done in the cloud.

As for DG, this might be the ideal solution for smaller & medium sized sites/ companies that have a lot of growth potential. Then it is indeed a win win situation for all the parties involved, but I am missing some feeling of control to see this work on large setups.

For larger setups, it might be interesting to offer some kind of cloud ready code base/ package building tool where you can setup/ choose what you want for yourself and use things like puppet to make that "core packet". After that the customer is free if he wants to deploy this on DG or use that core packet on other platforms. + keeping total control on everything.

Regards
Jayme

March 6, 2010
Anonymous (not verified):

Especially interesting for businesses, aside from CMS, are open source ERP systems. An example of this is OpenERP. (http://openerp.com)

March 8, 2010

Add new comment

© 1999-2014 Dries Buytaert Creative Commons Attribution-NonCommercial-ShareAlike 3.0 License.
Drupal is a Registered Trademark of Dries Buytaert.