Liferay, Facebook, Salesforce.com, and what’s in a name?

A few blog posts, columns, articles caught my eye during my traditional pre-breakfast coffee browsing of the news that, eh, deserve my commentary. In no particular order:

Liferay explains why it is switching from the MIT license to LGPL
Bryan Cheung starts his blog very strongly, causing me to expect a bold conclusion at the end of his opening paragraph: “You know, we need the money.” He does reach this conclusion but you need to read to the bottom to find it and he’s not as direct about as his opening statement would imply.

So, in contrast let me say right away that needing the money is a fine reason to switch licenses. Open source is not and, exceptions to the side, should not be a charity. Whatever your business is and whatever your chosen business model, a key success measure is whether you are keeping existing customers and collecting new ones.

I find his blog entry well-written and perhaps one of the best corporate messages I have seen of a company to its developer community explaining why it needs to take such an action. In most cases, companies focus their message far too much on how this is Good for the community appearing to gloss over the first person interests as Bryan highlights in his opening. Now, his entry would have been perfect if he followed through on the expectation he set at the beginning.

When Bryan writes that the license change is one “without any legitimate detriment” to the Liferay community I smiled. I very much understand that sentiment and agree with it: during my tenure with the Java community and the JCP I dealt with more than my fair share of objections, complaints that really did fall in the illegitimate category.

Liferay’s move highlights other interesting aspects of life in the world of open source software:

• starting with an MIT- or BSD-like license makes it easier (possible?) to preserve the company’s freedom to make this business decision
• if you’re using another license you better have a contributor’s agreement that gives you that ability

Bryan describes ubiquity and compatibility as existing values of the Liferay environment – in other words resulting from the 10 years under the MIT license. A moment later he argues that a fracturing market due to derived works that have not contributed back led to the decision to switch over to LGPL. While this appears in conflict with each other, it centers on one of the ongoing, perhaps never ending, debates in the realm of free and open source software: whether MIT/BSD/Apache-style licenses promote compatibility or whether the GPL-style licenses do that.

Salesforce.com CEO says enterprise software should be more like Facebook
This column is a followup to Marc Benioff’s first mention of Facebook.

It made me think of a rather animated discussion I had at a conference many years ago when I was working for Apple. It was about the reasons why many people complained about, hated working with computers during their daytime office job only then to come home, switch on the home computer and play and interact with it for hours. While this is not exactly Marc’s issue in his blog I do still wonder why enterprise software like expense claiming for example are often so dreadful to use and indeed things like Facebook are so delightful.

But on to Marc who advocates the great value that social networks like Facebook and Twitter have to enterprises. I fully agree. They enable hitherto faceless large companies to have a human face and encourage customers, vendors, consumers, developers to interact with it out of their free will and initiative. It provides a meeting place where likes and dislikes about a company and its products are aired, and one that as a company you can be part of and manage. For small outfits they increase the word-of-mouth marketing these often rely on thus magnifying the outreach a small company could otherwise achieve through traditional means.

Does it matter what you call it?
Phil Odence of Black Duck Software reports in his Network World column on a lunchroom conversation whether the right phrase is “hybrid development”, “multi-source development” or (his suggestion) just “software development” to describe the now common situation that software projects pull in parts from many different places: in-house developed, purchased, open source projects, etc; and asks our opinion. I am not sure it really matters. All are fine as each capture slight differences between the circumstances of one project vs another, in other words whatever your development team is happy with.