In one of those funny, serendipitous coincidences, I had two conversations with two people that couldn’t be further apart in every way and both of them brought up a topic that I’ve been noodling off and on completely unaided. We were talking about what they see as the advantages of the whole SaaS phenomenon to each individual’s customers. You see, they both sell SaaS solutions. The funny thing was we got to talking about their internal architectures, infrastructures, and the ways in which their customers were stressing their systems. It was all good stuff, but somehow the conversation suddenly lurched over to the question of why the people building SaaS systems get so little benefit from it themselves!

I had been thinking about this from the context of what some people (like the 451 group) are calling “The All SaaS Enterprise”. It’s your basic “eat your own dogfood approach to life.” In other words, if your company is selling SaaS, why aren’t you using all SaaS internally? Being from an Engineering background, I naturally had asked myself the question for developers as I read about “The All SaaS Enterprise” concept in places like the Xeequa blog. Xeequa’s CEO, Axel Schultze, has a good write up on the blog about his company’s experience trying out The All SaaS Enterprise. Basically seems to have worked well for him.

Yet there is this pesky question about the developers. My two pals used strikingly similar language as they were describing the painful issues of making deals with vendors to buy hardware, software to run on the hardware, installing and maintaining all of that infrastructure and so on. Now it isn’t as if they didn’t recognize that they needed to add some value as software companies, they were simply lamenting the need to deal with all this even for their developers to work on writing new software, particularly when they were in the startup stage. Another went on to lament how unhappy they were with their bug tracking system and source control. They wanted all of this delivered in SaaS fashion without their needing to spend any time dealing with that kind of infrastructure for their day to day development work. They wanted to be able to customize those system to work the way they needed them to work, and to integrate with other systems in productive ways instead of standing alone as islands. Who can blame them?

In Enterprise Software, I’m used to dealing with the consultants and services people needed to install relatively heavy weight applications. They have related laments. Many of them spend almost as much time travelling to visit clients as they do completing their work at the clients. They want virtual access to everything so they can be productive any time their laptop is in range of a WiFi hot spot. They don’t want to run a bunch of heavy weight tools on the laptop or have to connect from inside some firewall. They’ve told me how much more productive they’d be if they could recoup some of that travel time doing actual hands on work. Instead, they’ve rented tons of DVD’s, read up as much as they can, and generally wasted a lot of time to no good end.

It’s funny how the solutions are almost there, but then fall short. For example, one of these two companies uses FogBugz for their bug tracking system. It’s thin client, it does pretty much everything they want, but there is a catch. It isn’t SaaS. You have to run it on a server and deal with setting it up and the care and feeding. You can go look on the site and they’ll recommend folks who will host it for you, but you have to buy you FogBugz license and then contract with the service to host it. Where is the “Credit Card Walk Up Service”? That’s where all I need is a credit card and an email address and suddenly I can run the software. That’s what good SaaS is all about.

SourceForge is in many ways a SaaS offering that would serve many developer functions, but it is again, not quite right. If your software isn’t open source, they don’t want your business and won’t host you. Again, where is the “Credit Card Walk Up Service” version of SourceForge that couldn’t care less that I want to keep my source my secret?

I’m sure there are SaaS version of everything I need available though. I’ll keep sniffing around. I did check out the Tanooma registry with no luck there either despite the recommendations from the good folks of Xeequa.

All is not lost, however. I have identified my first All SaaS Enterprise entrant. I’m using PBWiki as a resource to collaborate with some others on SmoothSpan. PBWiki is great. I can get a Wiki for whatever I want to use it for, make it private with a password so only my trusted circle can use it, and I’m off an running. It’s credit card walk up service. We had used Wikis in my dev groups at Callidus to good effect as a collaborative tool. Things started out on Sharepoint, but when the Wikis hit, everyone started switching. Somehow it was just easier. But we had to install our Wikis and maintian the servers. If we’d known about PBWiki (which I learned about through my friends at Mohr Davidow Ventures), we would never have wasted our time messing with our own servers.

Here is the other funny thing that gradually sinks in from PBWiki usage. I had been a dyed in the wool Microsoft Office user. Many I could make those apps sing! I’m a spreadsheet guy from way back having created Quattro Pro and competed with Microsoft in the office space. I was a General in the Office wars back in the late 80’s and early 90’s. Guess what? I don’t miss MS Word at all! The PB Wiki editor is fine. MS Word now seems like an over burdened desktop publishing program. I’ll use it to format my Lulu book (more on that some other blog day), but I don’t need it for this kind of work. PB Wiki is fine for that stuff.

So I thought I would try to track down what The All SaaS Enterprise would look like for SmoothSpan. If I can solve a problem using a SaaS solution instead of dealing with the pain of a packaged solution, I will, and I’ll keep you posted on the choices I make and how they’re working out for me. PBWiki is the first installment in what I expect will be a long list of great new tools I’ll be using.