Software as a Service
Much has been written lately about the emergence of the Software as a Service (SaaS) business model, and how new markets are developing around it. I argue that the ASPs of old have grown up, and now that they’re delivering real value, both their name and perception has changed.
The ASP model of 1998, 1999 and 2000 looked promising, My first company was among those offering an ASP model, in our case providing hosted source control. Well, that company is no longer around (I raised a little less than a $1M in seed, but failed to close on our $4M A round), but the service I started back then is still around.
Freepository is going strong and is now the centerpiece of my new company, appropriately named Freepository Corp. We’re taking the model into the enterprise, and have seen quite a bit of uptake on the new offerings. There’s lots of interest in what we’re doing, from the large software companies, to the small teams that have used the service since the early days, to capital sources. This is an exciting time to be in the SaaS space, even if we never actually left it.
When I started freepository back in May 1999, I envisioned it becoming big, used globally by software engineers who may not have had any other means to bring their teams together into a secure, common and easily accessible source control system. We were the first and are today used in over 40 countries. Certainly there have been others, as we all know. This has validated the model, and today provides clear differentiation between us (“rock-solid source control”) and the others.
But what makes a service that is attractive to ad-hoc software development teams in Poland, Brazil, Germany and Australia an attractive solution to the enterprise? What makes it a business model? The very same reasons: ease of access & use, security, cross-platform utility, and ubiquity. Add in the low-cost (zero actually) of setting up any given project in Freepository, and the solution becomes incredibly compelling.
Enterprises are off-shoring development with regularity. Entire functions, such as QA, are performed completely off-shore. This necessitates source control and other project artifact sharing between the teams that are half a world apart. Commercial systems available today simply don’t work well with these network distances – they weren’t designed with latency issues in mind. There are two commercial systems that I’ve seen over the years attempt this & fail miserably. This remains one of the reasons I continue to advocate CVS. CVS maintains a minimal network footprint, and even when latency occurs (it will), CVS responds by interrupting the transmission with an error message to the user. This is in contrast to other commercial SCM systems simply hanging, providing little or no productive feedback to the user, and occasionally corrupting the revision control database.
By placing Freepository solutions into data centers across the globe, we’ll always be as close to the team members as possible. We’ll use our sophisticated mirroring to ensure that the team members in San Francisco are seeing exactly the same repository as the team in Bangalore, even though there are multple physical servers colocated halfway around the globe from each other.
What does this have to do with SaaS? Everything. Latency is a real issue, and when you solve it you have real competitive advantage. If you are pitching a source control system as SaaS, it had better be rock-solid, cross-platform, technology-agnostic and easy to implement, use and support. And it had better add value – because if it isn’t adding value, well… you can guess what the inverse is. Rest assured your competitor will figure out how to position against your failings.
Popularity: 25% [?]