counter on godaddy
post

Zoho Rounds Out Small Business Suite with Accounting App–Zoho Books

This morning Zoho, known for SMB focused SaaS offerings in the areas of productivity, collaboration, business processes launched an Accounting app: Zoho Books. I typically don’t do detailed product reviews, when I see the first good ones, will link to them – just a few points here and then let’s discuss how it rounds out Zoho’s overall strategy.

The following video introduction is a bit “cutesy”:

-and that’s quite intentional.  In fact simplicity is one of the key points in Zoho Books:

  • Clear, streamlined UI, tabs, easy terminology –i.e. Money In, Money Out. This service is clearly targeted at non-accountants, which is most of us in a small business – hey, even I can understand most of it.Smile
  • That said, Books offers the opportunity to share data and collaborate with accountants (Ouch, did I really needed that reminder for tax time?;-) )
  • Multi-currency support – this is typically a later add-on in many systems, but Zoho has a wide international presence with most of their other services
  • Integration with Zoho CRM, Invoice, Mail – somewhat basic now, will be improved as we’ve seen with the rest of Zoho’s offerings
  • Support for electronic payment systems like Paypal, Google Checkout, Authorize.net. This is a “hidden treasure” inherited from twin service Zoho Invoice, which is a subset of Book’s functionality and can be easily upgraded. Why hidden? Because relatively few know that Paypal offers 50 cent (yes, that’s $0.50 per transaction) Business Payments NOT available through the Web, only via their API, i.e. apps like Zoho Invoice and Boooks.

Having said that, is Zoho Books a Quickbooks killer?

post

FUD in the House of SaaS – More on Suites

saas myths

Recently I wrote about the evergreen Best-of-breed vs. Integrated All-in-One Suite debate again, arguing:

Call me “old school”, but I also believe in the value of having one tightly integrated system for most business needs, and I believe it’s true not only for large corporations but much smaller businesses.  I don’t have CIO’s to back it up, but that’s exactly the point: I am talking about small businesses that don’t have CIO’s at all – in fact they  likely don’t even have full time IT stuff ( a good reason for SaaS in the first place), so they clearly lack the bandwidth to deal with integration issues and multiple system providers.

It wasn’t just hypothetical speculation, what really prompted my post ( and hence the reference to CIOs) was a study conducted by Brian Sommer who contacted several large corporate CIOs about SaaS implementations, and found that despite improvements in technology, and easy integration by firms like Boomi, Pervasive ..etc, CIOs still prefer to buy an integrated suite of applications and deal with one vendor for most of their needs.   It’s not what we think, it’s what they do – and they are the customers.  Says Brian:

But, customers will do what customers want to do.

Amen. But my post attracted a detailed comment from a PR professional (a fact that took a little digging to discover):

… the Suite approach requires the business to make compromises in areas of the business, and only works if you can run your whole business on that one suite – as soon as you need some other specialist system, or acquire another operation that you need to integrate, you’re in trouble because Suites, by definition, are not designed to make integration easy…

…Force.com essentially brings cloud apps together as a Suite by offering exactly the combination of tight integration, common interface and flexibility. Many businesses can already find everything they need on the platform, even the last critical element required for a serious business system: enterprise-class finance ;-) Many companies, especially smaller ones, don’t need a full ERP suite. They need a handful of critical applications that can grow with them.

Wow… where do I even start?   Perhaps by the only statement I can agree with:

Many companies, especially smaller ones, don’t need a full ERP suite. They need a handful of critical applications that can grow with them.

Yes, of course I agree.  In fact I am a small business myself, and guess what, not only I don’t need ERP, I don’t even need or use a CRM system, or one for business accounting.  The only lightweight business system I use is invoicing (happens to be Zoho Invoice), but frankly, I could get away without it.  Yes, some small businesses will want Accounting, and Accounting only, others will need CRM and nothing else – there are many good choices for them. And yes, FinancialForce.com (which the commenter represents) is great, and we’ve given it ample coverage @ CloudAve.

But that’s where reality ends, and plain old FUD begins. There’s nothing inherent in the “Suite approach” that would prevent customization, integration with additional systems, extension by third party apps.  In fact the key difference between an integrated Suite or discrete  point applications is just how much of the core business they cover natively before  add-ons are required.

And here’s the ultimate irony: I was reading these “ex-cathedra” statements (that’s nicer words for BS) while sitting at NetSuite’s SuiteCloud conference, that was all about working with development partners, releasing a new version of SuiteCloud, the app development and integration platform along with SuiteFlow, a graphical modeling and customization tool, and a bunch of other  announcements all geared to making and maintaining a thriving partner ecosystem, that builds on the core NetSuite functionality and delivers additional value to customers.

In fact the evening before the conference, CEO Zach Nelson spent an hour busting industry myths.  Now look at the slide above: he did not talk about NetSuite specifically, he was advocating Cloud Computing / SaaS in general.  That’s the somewhat usual formula:  myth spread by defenders of the “old model” busted by the innovators – who would have expected the old-time FUD served up by a PR flak for another SaaS provider… :-(

At the conference itself I saw several customers presentations, like that of Campus Villages which replaced 38 instances of MYOB + Intuit MRI with NetSuite OneWorld, including extensions like Nolan Fixed Assets and Electronic Payments, Celigo Smartclient, and are currently evaluating Adaptive Planning.   Those are functions not provided by NetSuite, so guess what – they add third party apps, just like they would to Coda or any other system.

The key criteria for any software company trying to penetrate the SMB market will be vertical industry epxerience, and NetSuite has clearly stated their industry experience is Software and Services – everything else is open to the ecosystem.  Case in point is manufacturing:

NetSuite RootStock MRP

Suites are not customizable?  Just look at  Rootstock, a third-party developer house that created an entire MRP system on the  SuiteCloud platform.  If that’s not living proof of the system’s expandability, then I don’t know what is…

A key difference between the Force.com / Appexchange and NetSuite / SuiteCloud approach is that the former facilitates the creation of any product / utility that you can pick up from a marketplace, while programs developed on SuiteCloude all tie into the NetSuite system very closely – not only on the data but also on the UI level – i.e. the additional business functionality becomes available within the NetSuite UI. In other words they run so smoothly, the fact that parts of the system were written by a 3rd party is hardly transparent to the end user – which is just the way it should be.

So in the end, there is no hard rule that says Suites are inflexible, non-expandable: there only well-written and poorly written Suites, just like well-written and poorly-written point applications.  There will be businesses who only need a few point apps, and should not think of a Suite, and others who will benefit from the All-in-One approach.  It’s their choice.  What they need is honest information, not FUD.

post

Are Suites Really Sour? The Best of Breed vs. Integrated Suite Debate.

The evergreen Best-of-breed vs. Integrated All-in-One Suite debate is back again. This will be a somewhat long post, so let’s sit back and start with some entertainment first.

Episode 2, “Suites Are Sour”  is from the mini-series SuiteMates, which I admit I find hilariously entertaining, albeit rather pointless.  Why?  It’s run by supply chain solution provider Kinaxis, but I don’t see much direct benefit to them. I’m reminded the Bill Gates – Seinfeld commercials: what’s the point?  But hey, we’re being entertained:-)

Now, back to those Suites.. are all Suites really Sour?  Fellow Enterprise Irregular Brian Summer clearly does not think so, his money is on the Suites, here’s why:

One of the biggest value drivers behind a customer’s move to SaaS is the reduced internal IT support cost a company has when using SaaS products. In the SaaS world, the vendor maintains the application not the customer. But, in a best of breed SaaS world, the customer is back to maintaining interfaces and integration aspects across a number of (SaaS) applications.

If the argument sounds familiar, it is – it was the same in the good old on-premise world, but much of it holds true in the Cloud, too.  Besides, this isn’t simply Brian’s own opinion, he has conducted a poll of large corporate CIO’s and most expressed strong preference for integrated business solutions, a.k.a.  “one throat to choke” (well, not exactly with those words…).

Call me “old school”, but I also believe in the value of having one tightly integrated system for most business needs, and I believe it’s true not only for large corporations but much smaller businesses.  I don’t have CIO’s to back it up, but that’s exactly the point: I am talking about small businesses that don’t have CIO’s at all – in fact they  likely don’t even have full time IT stuff ( a good reason for SaaS in the first place), so they clearly lack the bandwidth to deal with integration issues and multiple system providers.

This is not a popular view, after all the Millenial World View is all about open standards and APIs where best-of-breed cloud services that can seamlessly integrate and work together well.  I’m all for innovation, and hope we will get there one day – but for now the existing examples are all one-off, individual integrations between specific systems, or at best, ecosystem “satellites” centered around force.com, the Google Apps Marketplace and the like.  These are great solutions, but not enough to run a complete business on them.  In the meantime businesses are looking for available (Cloud-based) solutions NOW.  So yes,  I admit, my view is less visionary, more constrained by market realities today.

Brian cites WorkDay as a potential SaaS Suite provider: they have the right DNA, coming from the Founder who built once-successful PeopleSoft, and they are building truly Millenial Software from the grounds up as Phil Wainwright eloquently points out – but for now they still have a Human Resources / Finance focus only.  Far from a complete solution, just like the other successful SaaS players in the Enterprise arena, like SuccessFactors, RightNow, ServiceNow, and the like.

Yes, I hear you… I missed a big name: Salesforce.com, the GrandDaddy of SaaS or the Cloud or whatever the next fashionable name will be.  An amazingly successful company, and true innovators – having started as CRM company, moving on to as Platform provider, and who knows, tomorrow it may be a Media company? :-)  As long as the keep on moving to hot new areas, always picking the low-hanging fruit, the company and it’s stock price will remain hot.  Again, a great company from an Investor’s point of view.  Just not a Complete Business Solution.

One and a half SaaS Suite players

I can count the number of SaaS Business Suites that actually reached significant traction on one hand.  In fact the exact number is 1.5.  Yes, one and a half – and for now they mostly cater for the SMB segment, with undeniable ambitions to “grow up”.

netsuite The “One” in  that 1.5 is NetSuite.  Having started as NetLedger, the company has developed an integrated All-in-One solution, encompassing ERP, CRM, e-Commerce .. you name it.  Those acronyms are becoming quite useless – in that respect I agree with Dennis Howlett who says we should “dump the  disciplines formerly known as CRM/SCRM/SCM/ERP/3PL/HR/HCM/E2.0….etc” – hence I stick to the term All-in-One. Or Business Suite:-)  It’s been a long (and winding?) road for NetSuite: developing a full suite of apps you can run a business on is by far more complex than throwing out point applications.

The company also learned the hard way that with business complexity (please note, I am not talking about Software, but Business complexity) comes a more difficult, stretched out sales process.  The fact is, as much as I am a fan of the click-to-try-click-to-buy pull model, the more business areas (and stakeholders) are involved, the less feasible the fully pull model becomes.  A Business Suite is not something you simply pick up from an App Store:-)
So NetSuite experimented with more direct sales model first, gradually building towards a more channel-based model, to the recently announced SP100 program in which partner VARs get the entire first year subscription revenue.  Along the way they grew functional richness as well as market penetration, to the point that they often compete with Enterprise giant SAP directly.  Now, let’s quickly qualify that: NetSuite is not comparable to the SAP Business Suite, but it is often an ideal satellite solution for smaller divisions of large companies, many of which just got acquired and are facing the choice of a long SAP implementation vs. a SaaS solution from NetSuite (see Ray Wang’s post on two-tier ERP strategy)

I should probably mention that way back, before their IPO and the fame that came with it (from the times of NetWho?) I was an early NetSuite customer, picking it over the market leading CRM (and I mean that as a stock symbol), simply because it had a better process flow, even for Sales, which I was heading at the time. (Yes, we got p***ed learning we’d have to create Sales Orders outside the other system, even though we had quotes in the system, only to come back and re-enter the data manually).  NetSuite was simply a better CRM system, even before considering other business areas.

Parallel to our NetSuite implementation we introduced a Wiki, JotSpot, which just launched in those days (since acquired by Google) and soon we realized a lot of the support information for Sales could either reside in NetSuite or in the Wiki.  This has been bugging me ever since:

Why do structured, process-oriented systems and unstructured  collaboration tools live in different worlds?

Like I’ve said, I’m all for Suites, but the true Suite in my definition includes integrated collaboration and communication tools – I’m still waiting for that … perhaps not for long :-)

Now, if NetSuite was the “one”, who is the “half”?   It’s SAP’s very capable, but dormant Business ByDesign – which may just come to life later this year.  But I’ve been torturing you long enough, so let’s leave that to another discussion.

post

JotSpot Born Again as Google Sites, the Wiki-less Wiki.

Three weeks ago I speculated that JotSpot, the user-friendly wiki swallowed by Google a year and a half ago would soon come out of hibernation, and Voila! here it is, rebranded as Google Sites. It is the first service only available as part of Google Apps (including the free version), although I had some difficulty accessing it. Under “Manage this Domain” I could add “Sites” as a new service, but it did not show up on my account as an accessible application. When I typed sites.google.com it wanted me to sign up for Google Apps even though I was already logged in to my account. Of course trying to do so resulted in the error message:

Google Apps for zoliblog.com has already been registered by your domain administrator. Please contact your admin directly to get access to Google Apps services.

Catch 22. But there’s a solution: just type the direct URL (sites.google.com/a/yourdomain.com as default, or customize it to your liking) and you can get into Sites. I’m sure Google will soon add it to the Apps menu. (Sidenote: my old JotSpot account is still alive at name.jot.com).

Google no longer calls this a wiki, which I think is a good move. I previously wrote:

Wikis have arrived when …you don’t even have to know what they are to use one. You don’t have to know you’re using a wiki, just happily type away, creating shareable content on the Web.

I was discussing Wetpaint, the user friendly, wiki-less wiki there, and I think it’s smart of Google to follow that pattern… more later, but first, under the hood it is still a wiki, so let’s examine some of the wiki basics.

The interface is familiar from good old JotSpot (as a sidenote, the old JotSpot accounts are still alive at name.jot.com). There’s a basic wysiwyg editor, the Edit button is large and visible, and so is the New Page button. Good old JotSpot had several more ways of creating new pages, which are gone – perhaps for the best:

  • WikiWords or CamelCase: in old JotSpot anything you typed with embedded capitalization became a link to a page. As a relatively early wiki-user I liked it, as the easiest way to LinkAsYouThink. But in the Web 2.0 age we keep on bastardizing grammar writing EveryThingLikeThis, so more and more WikiWords had to be “unlinked”… too much confusion, especially for the new generation of mainstream users.
  • Linking to a shell-page before it’s created. This was a useful feature, even if we eliminate camelcase, I could use the “Link” icon, and mark up text as a link to a new sub-page, to be filled with content later. Again, this supports flow-thinking, or LinkAsYouThink, which I regret is gone.
  • The “New Page” button. This is the only remaining option in Google Sites, and I think the fact that it offers to pick a parent page (enforced hierarchy) is an improvement. No more orphan pages, yet relatively flexible hierarchy.

For those not too familiar with wiki terms, I discuss some of these concepts in more detail here: technically an article on SocialText 2.0, but I often make comparisons to JotSpot and Atlassian’s Confluence.

I’m glad to see Sites retained breadcrumbs for easier navigation, and they added sitemaps, a tree-style view of all your pages. This could be improved to allow for drag-and-drop style moving of the pages (changing the hierarchy), like Zoho Wiki does.

I’m surprised Sites still does not have inbound links: this is a critical feature for all wikis, whatever we call them. A wiki is all about associating pieces of information with each other, and the inbound link, also referred to as backlink shows you where the information on the current page is used elsewhere. The JotSpot tea half-recognized the importance of backlinks, as they were available as as a downloadable plugin on the Jot Development wiki, but never made it to the standard feature-set, and are apparently lost in the Google reincarnation, at least for now.

Attachment handling is as good as it was in the original JotSpot: it maintains previous versions, allows users to revert to earlier ones…etc. However, Google missed a huge chance here to by not offering to convert the attached documents to its own Google Docs style. This point takes us to the next level: stepping outside the boundaries of a standalone wiki and using it as a facility to pull together data created by other applications.

Last year I said after burying JotSpot for a year, Google can’t just release it as a wiki, instead:

…I hope that means they rethought everything and integrated JotSpot well into a number of offerings.

  • It could provide for much better document management than the current Docs &­ Spreadsheets UI.
  • It overlaps with Page Creator, also with the simplified version found in Google Groups – in fact Groups which is no longer just email lists but a rudimentary collaboration platform and JotSpot could very well be merged / integrated.
  • Finally JotSpot tried to provide primitive applications (spreadsheet, calendar..etc) all of which have a better Google counterpart, so one would hope they will be replaced, too.

Well, what’s the score on that prediction? Google Sites is a better replacement for Page Creator, Google ditched the JotSpot “apps”, replacing them with their own ones – so far 2 scores out of 3. As for document management.. well, I’d say half a score, or less. (Hey, that’s 2.5 out of 3smile_tongue)

You can somewhat integrate Google Docs (which includes documents, spreadsheets and presentations) by embedding them into any Google Sites page. You have to enter the specific URL though – why not just select from a list? Furthermore, your Google docs or spreadsheets have to be first made public and you have to use the public URL to embed them into Sites. Here’s my test site, showing first an error message, then the actual embedded spreadsheet, after I made it public.

The embedded docs appear properly in the saved page, but I can’t click on it, not even in Edit mode to get to the source. In fact in Edit mode all I see is a graphical placeholder for the embedded doc.

How about sharing / collaboration? As expected, your Sites can be:

  • private
  • public
  • shared with individual email id’s
  • shared with everyone within your domain

…and you can set view or edit options for all those levels. However, Google missed a big chance again. As a complete coincidence, it’s only yesterday that I raved about Zoho’s Group level sharing, half-announced in a fairly understated manner – hidden in a list of Zoho Writer enhancements. Well, Google already has a very good group facility: Google Groups, which started it’s life as a group discussion / forum system, but it gradually evolved into a decent collaboration platform. Once I have a “group” defined (i.e. the list of members), why doesn’t it become an entity I can share my wiki (sites) or docs with? When I invite users to share the wiki with, there’s an option to save the list as group, but I don’t know where it disappears, can not pull it up either within the wiki or gmail, or docs.

Finally there are gadgets, but if you read Dennis Howlett at ZDNet, gadgets might the feature you don’t want to touch with a ten-foot pole. smile_sad

Summary: Nice to have Jot back (even if we did not get GSpot.smile_embaressed ) Google now has a pretty good and easy web-page creator with some wiki features made user-friendly, and a half-hearted attempt at integrating the rest of the Apps empire using Sites. Perhaps they get it right in the next release.

Related posts: TechCrunch, eWeek, Ross Mayfield’s Weblog, Irregular Enterprise, Mashable!, InfoWorld, Between the Lines, Portals and KM, CNet, Webware, GigaOM, Web Worker Daily, Venture Chronicles, Insider Chatter, Learning and Technology, Solo Technology.

post

JotSpot…Gspot … Google Wiki

So they figured Gspot would be too risky a name for Google’s JotSpotTongue out, it’s now (almost) official: the new name will be Google Wiki.

JotSpot was (I assume still is) a good, user-friendly wiki, and if it comes back now, it took Google almost an entire year to release it after the acquisition. I hope that means they rethought everything and integrated JotSpot well into a number of offerings.

  • It could provide for much better document management than the current Docs &­ Spreadsheets UI.
  • It overlaps with Page Creator, also with the simplified version found in Google Groups – in fact Groups which is no longer just email lists but a rudimentary collaboration platform and JotSpot could very well be merged / integrated.
  • Finally JotSpot tried to provide primitive applications (spreadsheet, calendar..etc) all of which have a better Google counterpart, so one would hope they will be replaced, too.

In fact there are so many opportunities to waive the wiki into Google’s current offerings, I can’t even imagine what it would look like… or, perhaps, are we going to see a standalone wiki? Thinking

Related posts: Google Operating System, Google Blogoscoped, Read/WriteWeb, TechCrunch, Download Squad , Mashable!, Insider Chatter, Ben Barren, Squash, Parislemon.

post

Web 2.0 in the Enterprise – Round …n.. (I can’t keep track)

Stowe Boyd picks up where Ben Metcalfe left off in Web 2.0 doesn’t work in the mothership, but… essentially recommending that Web 2.0 is best introduced in the Enterprise “in a satellite operation at arms length from the rest of your operation

While this is often the easy solution, I think a case can be made for the seamless mashup of process- and workflow-centric enterprise applications and the more creative, unstructured, collaborative tools like wikis.  Case in point is JotSpot’s integration with Salesforce.com based on the Appexhange. Granted their target is not the largest of enterprises, but another example I heard of at SAP’s annual conference is the SAP Help Desk wiki by  Socialtext targeting the entire SAP ecosystem.  In any case, I agree that spontaneous, project-focused use is how wikis will become adopted in the Enterprise, but at the same time I believe they should be a logical extension of any Enterprise system – SAP, Salesforce.com are starting to recognize, and I think the day when we’ll have both top-down (enterprise sale as part of the large package) and bottom-up (departmental initiative) penetration is not that far.

But then Stowe goes one step further, and this is where the trouble starts:

…the larger question — whether the enterprise would be more agile, more adaptive, and more of a survivor is it could somehow break away from the need for slow-to-change applications that span the needs of many departments, beholden to many but satisfying none — has not really been addressed by Ben or the others I am interviewing on the on ramp to CTC 2006….
My gut says yes. Enterprises would be better off if their IT departments could move to small, low cost, web-based apps that satisfy local needs — a project group, one campus in Denver, the marketing department in Japan — without having to subordinate local needs to corporate controls. The benefits of enterprise standardization are measured in the IT budget, but the true costs are distributed thoughout the enterprise: less collaboration in the research team leads to slower innovation, a less-thatn-intuitive UI for the sale staff in France leads to lowered sale numbers, and a heavyweight finance solution that slows down invoicing costs serious bank in collection time
.”

Oh, boy. When we’re talking about large multinational corporations, as Stowe does in his example, the primary benefit of standardization and integration is NOT measured in the IT budget. The key benefit is competitiveness, simply being able to conduct business.  Here’s a case study from my “previous life” when I was implementing SAP systems in exactly these types of companies: The Client, a major test and measurement equipment manufacturer had no real-time visibility of their available-to-promise inventory throughout their own plants accross the US and several countries in Asia and Europe.  It typically took them 3 weeks to be able to promise a delivery date to customers. Needless to stay they started to lose business. After the SAP implementation customers could receive the promised delivery date in real-time. For this company the implementation of the standard system was not an option, or driven by IT savings, it was the only way to stay in business.

As a matter of fact, prior to standardizing on SAP the individual plants operated exactly according to Stowe’s ideal model: each doing whatever they wanted, picking their own systems that simply did not talk to each other.

Web 2.0, collaboration is great, it has it’s place in the Enterprise, but so do those “ugly complex” transactional systems.  Don’t try to run your supply chain on a wiki

Update , more than three years later: Would You Manage CRM with a Wiki?

Tags: , , , , , , , , , , , , ,

post

SaaS vs. Open Source for SMB’s? A No-Brainer.

(Update)
I have to take issue with Paul Gillin’s approach as he discusses whether SMB’s are better off with SaaS or Open Source Applications. If we equate Open Source to downloadable, on-premise installed software, I have no doubt, and have stated it before that the only good answer is SaaS. But, hold on, a few minutes later we’ll see these two options may not be mutually exclusive for long.

Paul analyzes several criteria:

  • cost
  • speed of deployment
  • customization
  • reliability
  • data ownership
  • vendor viability

These are all issues well-discussed on the web, and although Paul does not explicitly say, my reading is that he also leans towards the SaaS conclusion. The problem is that this criteria-by-criteria approach works well with a typical (mid-size) company where some level of IT expertise is present. Small Business America is very different from the web-savy geeky software startups; the majority are more traditional businesses with no CIO, IT department, in fact often without any IT support whatsoever. While the two main obstacles SMB’s face with any on-premise implementation are cost and (lack of) IT expertise, you can’t just translate the latter into cost – i.e. the cost of hiring full-time IT support. The opportunity cost of Management venturing into IT hiring and project decisions instead of focusing on their primary business makes this an impractical approach, leaving us with only one choice: SaaS.

Another issue not discussed in the article is integration. Open Source or SaaS, getting several packages work together requires IT and business process expertise, which typically means hiring expensive consultants. Therefore, I would go one step further: not only SaaS is the best choice for most SMB’s but they should seek to minimize the number of providers, i.e. the best choice is to use integrated All-In-One solutions.

The current undisputed leader in this field is NetSuite, but as they follow Salesforce.com’s footsteps and move upstream chasing midsize businesses, they leave an opening for up-and-coming challenger 24SevenOffice, which focuses solely on SMB’s, and covers a wider range of business functionality than the incumbent.

This is the situation today. Now, let’s revisit the original question: SaaS or Open Source? A tiny startup named SQLFusion is working on making that question obsolete. The dilemma with Open Source: a lot of good applications are available, but they are written by geeks for geeks… you really have to be quite knowledgeable to download and implement them. Example: at one of the startups I am advising I use SugarCRM over the internet. Starting to use it was a no-brainer, but when I looked at the prerequisites and the process of installing it myself, my head started spinning. No way, this is not for me! Open Source Fusion, which I hear is within days of opening for a limited beta will bridge the gap between availability and usability of Open Source Programs, by offering such apps to be used over the Internet. In true On-Demand fashion, maintenance, upgrades all happen in the background, one can start using the programs without implementing them. So it will no longer be SaaS or Open Source, but SaaS and Open Source.

The first incarnation of Open Source Fusion will provide access to individual applications, still leaving the integration dilemma for SMB’s, but the technology under the hood enables the company to later offer an integration layer between the key applications it serves up.

So the future is Open Source Software as a Service. Hm, here’s an ugly acronym: OSSaaS (?)

Update (3/6). Releated posts:

Update (5/23): Stefan over at The Small Business Blog discusses the issue; his company, WinWeb is expected to offer Open Source apps as a service soon.