Slashdot Mirror
Blackberry Blackout Threat to Software as Service?
TheIndifferentiate writes "In light of how CEOs are reacting to a possible court injunction which could shutdown their RIM BlackBerry service, what impact do you think this will have on the 'Software as a Service' business model? The conventional wisdom in some commercial software corners has it that the threat of patent litigation should stop Open Source Software development in its tracks. If my business depends on an OSS application, and it gets shut down, I can potentially go on about my business as I have the executables and wouldn't have to stop using them until someone came knocking at my door. If an SaaS application gets shut down and my business depends on it, I'm dead in the water. Seems like one of the prime arguments against OSS also takes out SaaS too. Rhetorically speaking, how could a commercial ISV in good faith talk any business out of an OSS application and into an SaaS application?"
Service of any kind can fail; companies should always have contingency plans in place in case of such failure. BlackBerry is a great tool, but there are other tools now that can do the same task and companies have known for some time the risk that existed to the service. Those who haven't a migration plan have simply failed to plan, but the loss won't be too grave as e-mail itself will continue internally and there are plenty of PDAs/Phones that can take over the workload.
On the other hand, when a service is key to the operations of the company it is far more important to have solid contingency plans. We provide such a system and the big concern our large clients have is "how do we continue if your company fails". Even though we have escrowed code, it wouldn't do the clients much good as they would have to bring up servers, restore the data and understand the operations side. For that reason some clients are paying for "continuity insurance" which funds us for three to six months at a maintenance level to operate the system until the escrowed code running and ownership is transferred.
We are handling this continuity by placing the funds in a reserve controlled by a third party that is releasable via the "triggering conditions" of a contract ending or our normal operations being threatened. Obviously, if our product was open source, there would still be the transfer concerns, so I don't think open source provides some magic bullet in the case of "software as service" since typically such arrangements include the hosting. It would provide the availability to continue development after the failure of the service, but again our code escrow and transfer effectively is the same thing (although the various clients would do so independently instead of under the banner of some foundation. I see the possibilities of a foundation that could better steer such development as perhaps the only real benefit to OSS, and frankly it isn't out of the question to BSD license the code upon failure (we don't but we could).
Sig under construction since 1998.
This has been an issue in outsourcing deals since forever. If you put your eggs in someone else's basket, you have a stake in how they build that basket. If you are big enough, contracts can be structured to strike an acceptable risk sharing balance. If you're just Joe Customer, you might get screwed, but you might not have a choice.
Si vis pacem, para bellum
The only thing more annoying than a Libertarian is an (un|mis)informed Libertarian
I'd have to say there's nothing I'd like better than a Crackberry network shutdown, at least for a week. It might actually wake up the execs to the mess the modern patent system has made.
Also, probably some 80% of the people I know who have the damn things only have them to make themselves feel important, not because a life-and-death email could come in at any moment. It's very disruptive trying to talk to some ass who thinks every time his CB goes off he should pick it up rather than continuing the discussion with the real, live person in front of him/her, yet that's what most of them do... Plus, most of this 80% have increased their stress level unbelievably by destroying the greatest feature of email - the ability to get back to it when it doesn't disrupt things, unlike, say, phone calls.
That said, redundancy is a good thing for those people where it really is an end-of-everything scenario to be out of touch with their email. There should be a backup plan, and this will be a healthy reminder. When I'm on call for production support, I have a cell phone and a pager at all times, and if I'm home, email and my land line work as well. Inevitably, at least one of these often fails to reach me, that's why there are backups.
The rest of the people, the 80% above, well, they just need to pop a valium or two and realize that it doesn't matter that much...
Nathan
It seems to me that alarms are sounding a little bit too loudly here. For IP cases where licensing is the issue and a settlement is imminent; Prudently the company would pay the fine in lieu of a forced service shutdown. Case closed. Is it reasonable for the BlackBerry to be shutdown? No. Will it happen? No. Think like a reasonable judge would: punish the company not the users who use the service.
The case where a service is shutdown is most often due to bankruptcy. If your business relies heavily on a shaky or near bankrupcy service, I'd sugest seeking a backup plan or a escrow deal for the code from such service.
IANAL blah blah blah, but have some common sense!
As much as I support OSS and I think the argument that commercial software is just as vulnerable to the risk of patent infringing, I disagree that they are comparable in likely outcomes. A business that sells the software under their own liscence has the option of settling with the patent holder, paying liscence fees, mounting a legal challenge that invalidates the patent, etc. That none of these things happened in the Blackberry case is more the result of factors unique to this particular conflict and the players themselves.
But take an OSS software that is distributed for free. Most if not all of these options are off the table, meaning they are much more likely to get shut down as a result of an infringement case. Hence more risk. Though in a shutdown situation I agree that OSS would be preferable as it would at least allow individual users to continue in-house development until they were able to move on to something else instead of potentially facing an overnight shutdown situation.
The threat the article described is one of another company owning patents to the software used coming in and shutting down the company.
The problem I see even if you have a code escrow agreement, if the company you have an escrow arrangement with is being shut down is doing so because of patents they may not be legally able to give you the escrowed code and it may be withheld from you! I would imagine the first thing a patent holder would demand from a company in violation is that no source could be released unless you paid them first, and furthermore that you cease using the software at once (if it's an application, not a service)
Code escrow only addresses the financal, not IP risks of using proprietary software - service or deployed application. The great thing about OSS is no-one really tracks who has what - so even if a project is found in violation you can simply keep running it while you execute a migration strategy.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Look at it as local control vs. remote. If I have the application and the data on my local machine, what do I care if another company gets an injunction against the manufacturer of something? I can still do what I need to do.
But if things are remote -- Blackberry, remote storage, remote applications such as SaaS are examples -- then I'm far more vulnerable.
Not just to injunctions shutting down the service, "upgrades" that go wonky, but to idiots with backhoes!
It comes down to that risk - benefit analysis. Am I willing to risk having key parts of my infrastructure in the hands of someone else, or do I want it local, where I can see it (and screw it up myself, but that's another part of the equation).
Do I want to put myself in the position where someone can say, "Sorry, you don't have permission to open that document any more."
Nope, I want things where I can see them. Remote backup is another story, but I want the primaries under my control.
And saying this is another death-blow to OSS is just more FUD.
Namaste--
Meanwhile, if an open source product is determined to violate patents, in theory using the software is no more legal than in either of the above cases. Sure, you might be able to operate below radar longer, but I would hate to have *that* as my contingency plan.
I do agreee that the "deeper sand to hide your head in" plan is not exactly the best idea... perhaps a better aspect to consider is that potential finanical liability would be lower if you were not paying for the software itself and only for services. It would be harder I think to realistically extort much from you if the previous market value for software had been zero.
"There is more worth loving than we have strength to love." - Brian Jay Stanley