Thursday, April 26, 2007

Free Telematics and a enforcing open source SaaS

This morning I received an email from Rufo Guerreschi of the Telematics Freedom Foundation. I honestly never heard of this organization - until today - but it looks like a very interesting initiative. And it is based in Italy, which makes me proud ;-)

Rufo wrote a post on his blog about a model for the democratic control of telematic services. In a nutshell, he is trying to close the ASP loophole of GPL (v2 and v3...) with something quite more elaborate than a simple license.

He is envisioning a world of free services based on Software as a Service (SaaS), where Reviewers can be appointed as Auditors for the software behind the service. And Modifiers can modify the code of the service and obtain free or at cost hosting.

It is a very interesting approach. The issue behind the reasoning seems to be enforcement of the license. I heard about it before, many times. If your software runs behind a firewall, how can you (the user) know what really is the service running? What if they change the code and do not tell you? What about your freedom as a user to see the code?

Rufo's answer is: let's appoint Auditors. Mimicking the voting process, where Auditors are making sure nobody votes twice. These people might have conflicts of interests, but the entire system usually works (unless you live in Florida).

I have never been a fan of enforcement. Maybe because I trust people by nature. Or because I am just pragmatic. Enforcement is tough to achieve. For example, the Affero license has a provision that forces the hosting service to give a user a way to download the entire source code while accessing the service.
I always found it too restrictive. Forcing software implementations through a license seems odd and hardly applicable to the millions of different cases we are going to see in the future (think about a mobile phone accessing email on a Funambol server... How can I give you the entire source code to download on your device?) .

Is the old good GPL enforceable? In theory... If I take a GPL library in C, modify it and I compile it with my product, then ship the binary in a commercial product, who can tell I am violating the GPL? Probably nobody. Does it mean GPL is useless? No, it is based on trust. If you do not GPL your code, you are violating the license. We could catch you and enforce it.

The same for SaaS. If you run a service based on HPL, you must open source your code. If you don't, you are violating the license. We could catch you and enforce it.

To me, a piece of paper that says YOU HAVE TO, is enough. It is practical. It is based on trust. It simply works. Anything more complex would work as well, and maybe limit open source thieves, but adds so much complexity to also limit adoption. Which would turn people to use something else, less restrictive, even giving up copyleft (which would mean the death of open source). I am willing to give up on enforceability, to see open source
also thrive in the SaaS world. That's where the world is going.

Copyleft is based on trust. It would work in SaaS as well. Trust me ;-)

Monday, April 23, 2007

Virtual BlackBerry sounds like Real trouble

RIM is trying to recover from last week's disaster. They finally explained why it happened, although nobody really understood it (a software upgrade??). What I know is that our phone has been ringing uninterruptedly for days... At the end of the line, disgruntled IT Managers looking for an alternative to BlackBerry. Why do you want to lock you in with a single-point-of-failure when there is an open source alternative you can deploy in-house for zero dollars? No lock-in, open standard bases, huge community... You do the math.

Today, RIM is trying to get out of his unexpected misery with an announcement which signals more trouble. RIM is planning to roll out "Virtual BlackBerry" software for Windows Mobile 6.0 in fall. In a nutshell, it should be an icon on your WM; you click it and you enter a BlackBerry world, with all the common apps you are familiar with, if you are a BlackBerry user. I am guessing email and address book, with calendar.

Let's put aside that virtual apps usually do not work (try reproducing the push email experience on a device you do not control...) and that RIM has one of the worst developer team for client applications (good on networking, do not get me wrong, but really lacking on UI skills). Who is the target for this new fantastic app?

New customers? I do not think so. Who in the world wants to have another email client, another address book and another schedule, when you already have them in Windows Mobile? Why would I ever buy a Windows Mobile to run a virtual BlackBerry?? I would buy a BlackBerry instead...

Old customers? Are we talking about people that own a BlackBerry, that decide to throw it in the trash because the service sucks, and then move to Windows Mobile to get a virtual BlackBerry? Isn't it insane? If you realize BlackBerry sucks, you just want out of it...

OK, maybe I got it: it is for IT Managers that need to manage a transition away from RIM. Buy Windows Mobile for everyone, get the CrackBerry addicts on them, give them the same environment they are used to, then finally move them to WM as everyone else and say good bye to RIM.

Who could be pushing RIM to do this? The mobile operators...

Doesn't it sound like trouble? You are investing R&D dollars on giving Microsoft a path to take customers away from you. You are building a solution to move people on a different platform, while your revenues are all on hardware. You are pushing all the revenues on software, where you lose your lock-in...

Please keep calling, RIM is not looking good.

Wednesday, April 18, 2007

The day RIM business model blew up

A major outage of the RIM service has hit the news big time today. I am wondering how journalists are filing their stories, since their BlackBerry are not working ;-)

In my opinion, this has highlighted a major flaw in RIM business model. Not because BlackBerry has been famous for being reliable and it is not anymore. But for a more profound reason. RIM customers are mobile operators. Today at&t is not even able to tell if THEIR customers have service or not... The reason?

RIM is a single point of failure, that a mobile operator cannot control.

Today operators are forced to realize that, on top of having dissolved their brand in favor of RIM's,
they do not have control or even good visibility into the levels of service that RIM is able to provide to their own customers. Hence, an at&t user that bought a BlackBerry device and service from at&t today is not getting its email, and at&t has no idea of the status of the service or what customers are affected. Think of the Service Level Agreements (SLAs) that carriers such as at&t have with their enterprise customers. The carriers are in no way, shape or form able to monitor or enforce their compliance...

Now... the entire business model for RIM is based on extending its reach to the consumer market. They built the Pearl for it. It is their #1 goal.

Unfortunately for RIM, mobile operators will not do this mistake again for the consumer market. Carriers will own, control and brand the infrastructure for consumer push email, which is THE big opportunity and what RIM is shooting for (not really making it, looking at the latest financial results).

This will kill
RIM growth. The days where they had full control of carriers are over. The pendulum is swinging back. The operators want control of their destiny (and the one of their customers), not lock-in with a single point of failure. They need a white-label solution managed by them. Add low-cost, standard-based and open source push email and you understand why I am having a good day ;-)

Saturday, April 14, 2007

You go on vacation for a week...

Mobile is a super fast paced market. I have been in Hawaii for seven days enjoying sunsets with Mai Tai on my Lanai, and a million things happened (although they definitely did not ruin my vacation ;-) Let me try to recall some of the more important news.

After announcing it is opening some APIs, RIM came up short in the analyst call and the stock collapsed 8% in one day. The two news are not related but highlight the two main issues RIM is facing: first, RIM does not have a developer community (instead of opening some random APIs, why don't they go open source or, at least, help our community which is struggling to interact with the APIs they are filling with bugs to kill the competition?) and probably won't ever have it (while Microsoft and Linux do...). On the other side, they are trying desperately to move into the consumer space. Unfortunately, people are not buying enough BlackBerry Perl, which is their critical path to consumers. Therefore the forecast is bad and the stock value sinks. The Perl is not a consumer device. It is a cool replacement for older BlackBerries. Unfortunately, the iPhone is also a cool replacement for older BlackBerries, which makes their outlook even worst. Bottom line, RIM is not a consumer company and it is not likely to become one soon. They are likely to miss the train.

Quietly, SUN bought the IP of SavaJe, the maker of a 100%-Java mobile operating systems (the other one is RIM, if anybody noticed it). SavaJe died not-so quietly a few months ago, after burning a pile of cash ($120 millions...). SUN did not even announce how much it spent, because it was peanuts. What is really interesting is what SUN will do with it... After all, it is a hardware maker... If Apple was able to move from PC to iPod, SUN could move from servers to phones (the iSun ;-) Nah, looks too stretched. But it could mean a full mobile OS from Sun, licensed to device manufacturers. Or, at least, a lot more code in Java ME, including vertical apps, which would be great. Everything will be unveiled Apple-style at Java One in May. We'll be there with our Java ME open source push email client as well, so... another good reason not to miss the show...

In the meantime, Apple announced it will delay the shipment of OS X Leopard from June to October (that's four months...) because all the Apple QA people are testing the iPhone. I have the feeling they made the usual mistake of thinking "well, it is a small device, it won't require the same QA cycles of a server...". Oopss, it is actually the opposite. A small device, when it is a smartphone (a not a single purpose device as the iPod) requires way more QA cycles than a server. The sad reality of mobile. And they are using one single network (Cingular) and are not planning to allow developers to add applications, which cuts QA by 90%... Anyway, it also shows how much effort Apple is putting on this device. It simply cannot fail (but it might...).

Lastly, Palm announced they will have their own Mobile Linux OS. This is much better than saying "we sold the company because we have no idea what to do" (the current rumor) and answers a suggestion I made in this blog, summarized by Unstrung as:
Going with Mobile Linux, argues Capobianco in a recent blog post, would enable Palm to cut its ties to Good and to Microsoft, to solve its OS issues, and to go after the consumer market in a new and effective way. The alternative is continued stagnation and eventually acquisition.
So... one very good for Palm (it was about time... and it is probably too late as well), one good for Sun, one bad for Apple and one ugly for RIM.

A week is a long time in mobile...

Sunday, April 01, 2007

ASP loophole: what if the FSF got it right?

It is Sunday, the weather is nice and my rage against the last draft of GPLv3 is gone. Now I can analyze the FSF move on the ASP loophole from a different angle.

I exchanged a few emails with Brett Smith of the FSF, after my blog was posted. He also wrote a comment on the FSF site about the issue. The feeling I have is they were forced to drop the ball, but they have a clear strategy in mind to get it back. If that works, they will achieve what the movement needs, in a very subtle way.

In essence, the strategy of the FSF is simple (I am paraphrasing here, nobody said these exact words to me):
  1. FACT: we simply could not get GPLv3 out with the ASP provision or it would have been DOA. It is hard to disagree...
  2. TRICK: we are creating another specific license that includes the ASP provision (AGPLv2) and we added in GPLv3 that the two will be compatible. The end result is license proliferation, but not license incompatibility which is the key issue.

People will talk about GPLv3, but if they can get enough notoriety for AGPLv2 and projects will start moving to it (as they should, you DO NOT WANT someone to run your code as a service, make modification and not giving back to your project, it is plain stupid), they will have reached their goal.

So, what is my next move? Working on AGPL to make it the best possible license. I always said that HPL was a stop-gap. If AGPL has what I need and it is generic enough, we should all switch to it (including Alfresco, SugarCRM, Zimbra, Compiere, OpenBravo and so on) and make it THE license.

Things I do not like about AGPLv1, which forced me to create HPL:
  1. The provision to close the ASP loophole is insane. It requires you to create a service in your product to allow your users to suck down the source code. What if your users access your service from a terminal in the library? Licenses should not force implementations. In HPL, we just say "if you give this to the public, everything else applies". That is, you have to give the world access to the source code. How you do it, I do not care. Enforceability is not the key element. You should trust your community. Looking at Brett's post, I have the feeling the FSF is going in the right direction.
  2. I do not like the fact that AGPL is Affero branded. It is a vanity license. I do not know anything about Affero Inc. but that it is a corporation. Corporations tend to cater to their needs (rightly so). I would rather have a generic license managed by the FSF. Called AGPL where A stands for ASP. "The GPL for ASP". Just perfect. Unfortunately, the FSF wants to make AGPLv2 backward compatible with AGLPv1 (BTW, is anybody using it?), therefore they might be stuck with the Affero name. It would be a mistake, but manageable from a marketing standpoint.
  3. AGPLv1 is not OSI-approved. The OSI is an important element of the ecosystem. AGPLv2 (and GPLv3, for that matter) must be OSI approved. I am sure this could be done quickly.
Well, the fight it is starting to look good ;-)