
Alistair Croll has an interesting post where he argues that, for all intents and purposes, source code is irrelevant - the new valuable commodity is app tone.
... In the software-as-a-service world ... source code becomes irrelevant. If someone offered us the schematics to a telephone, we wouldn’t care. We don’t want to know how to make a phone. We want a dial tone. When it comes to IT, we want app tone.
As another way of saying people want apps to work, this could make sense. But irrelevant? That's just silly.
... If 37 Signals gave me the Basecamp source code for free, I’d still use their service. If Freshbooks burned me a copy of their app, I’d still subscribe to them. Even if Salesforce.com handed me their software, I’d use their hosted portal.
Ok that makes sense to most folks using SaaS offerings ... after all, who wants to go through all the trouble to install and run something when a perfectly acceptable alternative is already available?
Of course, if a competing service came out (made much easier to do with that "irrelevant source code"!), perhaps with some improvements in quality of service, or more generous free capabilities or some other such advantage, wouldn't folks simply switch? Of course they would.
Anyhow, Croll continues on this theme
In the license world, it’s all about the ability to make copies of the software. By contrast, in the world of app tone, it’s about the ability to run instances of the code. It’s about operating an application reliably ... and the ecosystem the SaaS provider can build around it through APIs, partners and extensions
Sure that's all true, but how do you think all that reliability gets there to begin with? Is it purely a consequence of skilled operations? Of course not ... the application source code itself can do a lot to improve it's reliability.
On a Roll ...
So in the interest of making an interesting point Alistair gets carried away, leading him to miss the mark entirely here:
Even the open-source movement is feeling the change: Recent modifications to the third revision of the GNU Public License recognize that it’s the service, not the source code, that has value — and that any user of the service has the rights to its source code.
Not exactly. What these changes recognize is that most SaaS offerings are not posting their key source code much at all ... even when they incorporate open source libraries that would trigger that posting for software that is delivered conventionally. They don't have to by the terms of most open-source licenses, so why should they?
Of course, methinks that this might be because there's significant value in said source code!
The Service DOES Have Value
Of course, the service itself has beaucoup value ... for all of the reasons that Croll cites in his post. It's just that the question of which has value, the service or the source, in not a simplistic case of either / or, but more of a both-and. That is, both the service and the source code itself have significant value, and will continue to do so for some time.
After all, SaaS is not an alternative to meaningful source ... it's another way to deliver that meaningful source.








Okay, maybe that was a bit harsh ;-)
Good points all. I've had a few people voice their concerns that not providing source means you can't inspect a service provider and be sure you're complying with things -- which seems legit, but makes me wonder if we need a way to prove that in fact what they showed you is what they're running.
I do think that we're going to see a switch from the Open Source torch to two new ones, however: Data portability and Open Services.
In the former case, it's going to be a question of whether I can move my data, metadata, and even business logic from one provider to another (say, Salesforce to SugarCRM.)
In the latter, it's going to be a question of whether there's a level playing field for services. Put another way, StarOffice/OpenOffice keeps Microsoft (relatively) honest; there's a price point at which people would simply switch to something cheaper and nearly as good. But there's no equivalent for services such as mapping, currency conversion, and so on. So I suspect we'll see a movement of open services to try and keep the playing field relatively level.
Thanks for the feedback!
Post new comment