Can Open Source & SaaS Get Along?

Sep 26, 2007 by Sinclair Schuller

Many things in life tend to be mutually exclusive: you can’t drive a car and fly an airplane at the same time (not yet), you can’t be underwater and breathe (at least not without an apparatus) and you most certainly can’t talk and listen at the same time (believe me, I’ve been trying to perfect this for the longest time). Many will have you believe that Open Source and SaaS as a pair of business/distribution models also fall into this category. A simple Google search unearths a bevy of “Open Source vs. SaaS” information. Within the blog space, different ideas have sprung up: Ben Kepes blogged about the merger of the two and Bob Warfield followed up. Anshu Sharma even touched on the topic in this post. One thing is certain from my perspective: SaaS and Open Source are most certainly not mutually exclusive.

When looking at software business/distribution models I see a few important questions that need to be answered in order to understand the “source to market” relationship as well as the potential for exploiting different ways to generate revenue:

1. Who Built the Software?
2. Who Added Value to the Software?
3. How is the Software Distributed?
4. Who Wants the Software?

Understanding the choices for each of those questions can highlight what possible paths can be taken. Visually, these questions and potential answers can be captured as follows:

Based on this “source to market” stack, I find it very easy to treat the Open Source Community as one of the many implementation mechanisms for software, irrespective of how the software is distributed or who wants it. (UPDATE: As Jim Donovan pointed out in the comments, a worthwhile addition would be “Internal IT” to the who added value part of the stack.) I’m satisfied by the notion that how software is implemented has little bearing on how it can (and should) be distributed, hence allowing SaaS (a distribution model) and Open Source (an implementation/licensing model) to co-exist (If there is some insurmountable contention I’m missing, please do leave a comment!). An example (although not the best example) is SugarCRM: a community develops the open source core, SugarCRM adds value through more feature-rich versions, and the software gets distributed both on-premise and on-demand. If we lay a map over the previous diagram for a concept similar to SugarCRM, we arrive at this:

When building a business/distribution model, understanding the abstraction between interacting layers (or acknowledging that they exist) can be powerful. I think there is a lot of work to be done in creating a powerful “Open Source/SaaS Merged Model” (I don’t think Sugar has the best approach yet), but we should by no means use “versus” to describe their relationship. One thing we can all agree on is that many of these concepts are better than this:

Any thoughts or comments? Is a merger between the two not possible, or is it inevitable?

 

read more

Are you a SaaS expert AND a software engineer? Meet Apprenda.

Sep 20, 2007 by Matt Ammerman

If you read this blog and/or subscribe to our SaaSBlogs RSS feed, than we already know that you have an interest in SaaS.  Now, if you’re a software engineer on top of that, then we urge you to head on over to www.apprenda.com/careers and check out the currently available positions:

• Software Engineer – SaaSGrid (disclosure: as mentioned previously, SaaSGrid is the platform that my company, Apprenda, will be releasing to beta soon.)
• User Interface Engineer

In the exciting world of software as a service, Apprenda’s development teams are hard at work inventing and perfecting techniques for cutting edge service delivery and the distributed hosting of web services.  If you, or your brilliant coworker/sibling/friend/ex (why not?), are interested in such endeavors and are comfortable working in a fast-paced and agile development environment, we’d love to hear from you.

 

read more

Level 3 Platforms & Creativity

Sep 18, 2007 by Sinclair Schuller

Marc Andreessen posted an excellent article breaking down Internet platforms into three “levels”. If you only have time for one article you would be better off to read his than mine but to summarize, the levels are described as:

• Level 1: API driven, app lives outside of the “platform” (Think Flickr)
• Level 2: Plugging an extension via an API into an existing app (Think Facebook)
• Level 3: A runtime where code lives entirely on the platform and the platforms purpose is to host applications (Think SaaSGrid – disclosure: SaaSGrid is the platform my company Apprenda will be opening to beta soon.)

The most important takeaway from Andreessen’s post is his statement that:

“I [Andreessen] believe that in the long run, all credible large-scale Internet companies will provide Level 3 platforms. Those that don’t won’t be competitive with those that do, because those that do will give their users the ability to so easily customize and program as to unleash supernovas of creativity.”

Reading that quote summarizes our mission with SaaSGrid and my personal perspective on the SaaS platform concept in general. If as a software engineer or development studio one can focus on what’s important and let Level 3 platforms do the grunt work, the ability to work “outside the box” becomes very real, and the quality and value of applications skyrocket. Once a Level 3 platform becomes established, it can very quickly continue to introduce value to the applications deployed on it.

 

read more

Enterprise SaaS != Web 2.0: A Quick Hosting Perspective

Sep 10, 2007 by Matt Ammerman

I like a good mystery just as much as the next guy, and this story’s got it all.  If you haven’t got the time or interest to read the whole forum thread, here’s the synopsis:  Jatol.com (no hyperlink provided because of said mystery), a notable web hosting company seemingly popular with development crowds has simply vanished.  Literally.  Websites down. Domain missing. Phones disconnected. Believe it or not, even the owner is missing! 

At this point, there’s not even a support number to call and Jatol.com users aren’t even able to retrieve their stored data or web site files. As I read further down the discussion chain, I started thinking about how awful it would be if I were running a web-based business in a situation like this – the mere thought of surmounting catastrophic shutdown such as this is mind boggling.

While it may seem obvious to some, this story specifically highlights a very important part of what enterprise SaaS ISVs should look for in managed services: providers that can assert serious service level agreements and back them with real ramifications.  For instance: transparent multi-tiered redundancy, consistent and thorough backups and archives, potentially even software and hardware escrow services (see ‘catastrophic shutdown’ above). The bottom line is that hobbyist devs hosting websites or even working applications with reliable hosting companies count downtime in minutes, while enterprise count downtime in thousands of dollars.

The tricky thing about SaaS is that it fundamentally requires the ISV to at least purport to be the ‘provider’ of software.  While hosting may be outsourced and ISVs become at least the ‘P’ in ‘MSP’, it is vitally important that the backing ‘MS’ be up to par.  If you’ve dealt with an MSP (without naming names) and had service level ‘experiences’, what are your thoughts on MSP preparedness for SaaS?  Are MSPs ready to host enterprise SaaS applications that generate the aggregate load of potentially millions of ISVs’ users?

[poll=6]

 

read more

Are There REALLY Multiple Strategies for ISVs?

Sep 4, 2007 by Sinclair Schuller

About a week ago I wrote an article on SaaS strategies for existing ISVs, and I see that a a parallel conversation emerged starting with a post by Anshu Sharma that claimed that in the real world, ISVs “…adopt a range of delivery model options to fit the customers need and economics of their particular business.” Phil Wainewright followed up with this post, where he vented about Sharma’s position.

I wanted to post a couple of notes on this little blog battle. First, I think the problem with Sharma’s approach is that it’s strictly customer centric. I’m the first to agree that there are (and rightfully so) a multitude of strategies (as I mentioned in my prior post), but that the decision of which to choose should be a combination of what your customer base wants/needs and what aligns with your company’s future goals and anticipated market shifts. That said, your customer might say “I want on-premise”, but you see that the market is quickly changing, with early adopters going for some new delivery model (SaaS) and its probably only a matter of time before the mainstream market (your current customers) buy into it. If you were to listen only to the customer base, you’d find yourself in trouble in the near future.

If you dig through Wainewright’s post, you’ll notice that he does agree with multiple strategies when it comes to transitioning to SaaS. This is the position I take. None of the strategies I mentioned in my above referenced post are to be permanant. Rather, their purpose is to help an existing ISV make a strategic shift toward adopting SaaS. If Sharma’s intent was that adopting a wide range of delivery models should be/can be permanant, I disagree. That’s asking for trouble when it comes to scaling the business, building new efficiencies, and having a cohesive mission.

Bob Warfield jumped into the battle with this post, where he ends on a note of a “protected game preserve” which is basically a market defined by specific attributes (size of company, etc.) where you are free to play as a SaaS provider, insulating you from the dangers of a head first mentality. This is a smart approach, and is virtually identical to my concept of pursuing a “lite” version of your product that targets a degraded demographic, giving you an opportunity to “sandbox” SaaS while you figure things out.

What do you think? Is it healthy for ISVs to pursue permanent mixed delivery models, or does this create a “dysfunctional family”? 

 

read more