July 2010


Lockheed Martin’s newly open sourced social networking platform, Eureka Streams, has faced FUD when it should be received with open arms.  IT decision makers can learn important lessons from Lockheed Martin when evaluating whether to open source an internal project.

The enterprise open source contribution dilemma:
While usage of open source and open source-based software products continues to grow, enterprise willingness to participate in open source projects is heading in the opposite direction. This fact was highlighted most recently in the 2010 Eclipse User Survey. The Eclipse Foundation’s Ian Skerrett wrote:

In the survey, we asked a question about the corporate policies towards open source participation. In 2009 48% claimed they could contribute back to OSS but in 2010 only 35.4% claim they could contribute back. Conversely, 41% in 2010 claimed they use open source software but do not contribute back but in 2009 it was 27.1%.

Open sourcing as a last resort:
Considering this background, one would expect any enterprise that creates an open source project would be welcomed – not always so, and sometimes for valid reasons.

Earlier this month Vodafone announced the Wayfinder open source project. The project deposited a location based services platform into the open source commons under a BSD license. However, as Wayfinder Systems, a wholly owned subsidiary of Vodafone, explains:

The operations of Wayfinder Systems has been discontinued since March 11th…and after that Vodafone decided to contribute the software to the open source community.

In short, the project was open sourced as a last resort. While Vodafone didn’t see any further business value in the code, at least they decided to offer up the technology for others to benefit from. It’s understandable however, that other enterprises may not want to adopt or contribute to a project that the project’s originators aren’t going to continue developing for their own business needs.

Enterprise founded open source done right:
Lockheed Martin’s Eureka Streams project is very different than other enterprise-founded open source projects.

Eureka Streams is not being thrown over the corporate walls in an effort to see if some other entity can benefit from the code that is no longer of value to the founding vendor. Eureka Streams is and will continue to be used by Lockheed Martin to address Lockheed’s internal social networking business requirements.

The code is available under an enterprise friendly Apache 2.0 license, meaning that other companies, including Lockheed’s competitors and open source support providers, could adopt and build a business around the social networking platform.

One could question why Lockheed would open source technology that could very well help it differentiate versus competitors – in today’s knowledge worker enterprise, social networking can help employees be more productive and improve employee satisfaction. Far from questioning Lockheed’s motives, I believe we should welcome Lockheed’s efforts in the open. I suspect that Lockheed’s executives realize that technology is of little use without employee buy-in. While Lockheed and a competitor may in fact have access to the same productivity and employee satisfaction improving technology, the processes and culture around the technology could very well help Lockheed differentiate versus their competition.

Eureka Streams is further different than other open source projects, even commercial vendor developed projects, in that the development and decision making appears to be happening in the public. Lockheed engineers on the Eureka Streams project discuss build strategies and optimal search approaches on the Eureka Streams Google Groups forum.  This helps prospective adopters understand and get involved in the project.

Five lessons learned from Eureka Streams:
First, open source an internal project that is valuable to your business and could be appealing to other enterprises. Open sourcing a project that your business no longer needs is a red flag to other enterprises that would rightly worry about the future of the project.

Second, use a liberal license for the open source project. This will address a key concern that enterprises have, especially if the project isn’t from a commercial open source vendor. A liberal license will also make it easier for a third party to provide support or value added extensions to the project. This in turn will make it easier for other enterprises to adopt the project’s technology.

Third, develop in public. The use of GitHub and Google Groups for ongoing development and project decisions is helpful in attracting other enterprises to your project. Allowing outside contributions to your project is the next step of course. Even if the majority of your users don’t take advantage of this option, it helps increase the credibility of the project.

Fourth, allocate a sufficient marketing budget to the project. Code is great, but so too is a site that suggests that the project is credible and has a future. The visually appealing website, demos and documentation, while still incomplete, quikcly suggest that Lockheed has a vested interested in the success of the project. This reduces the risk surrounding the project, making it easier for others to adopt the project.

Fifth, link the project to developer recruiting. Most young developers want to utilize and participate in open source development projects during their day jobs, and yet, not everyone can work for Google, Facebook, IBM, Oracle or the like. If nothing else, Eureka Streams is a great example of why a developer should at least consider working for Lockheed Martin.

Done properly, enterprise created open source projects have the potential of benefiting the enterprise and the open source commons. Is your company in a position to give it a try?

Follow me on Twitter at SavioRodrigues. I should state: “The postings on this site are my own and don’t necessarily represent IBM’s positions, strategies, or opinions.”

RackSpace Hosting and NASA made headlines by announcing an open source cloud software project earlier this week. Some observed that OpenStack could be the beginning of the end for open core business models for cloud infrastructure providers. IT decision makers are cautioned to ignore the predicted decline of open core, and instead, focus on selecting cloud technology that addresses business requirements.

Fully open source cloud software:
Launched by RackSpace Hosting and NASA, with the support of vendors such as Citrix, NTT Data and RightScale, the goal of OpenStack is to:

“…allow any organization to create and offer cloud computing capabilities using open source software running on standard hardware.”

Open source cloud software foundations are not new – Eucalyptus and Cloud.com are two vendors that offer open source products in the cloud arena. However, unlike Eucalyptus or Cloud.com which utilize an open core product strategy, OpenStack is billed as a completely open source project, without any advanced, enterprise or service provider relevant features only available in a paid commercial offering.

Rejecting open core:
In fact, when asked by RedMonk’s Michael Cote whether RackSpace would utilize an open core model for OpenStack, RackSpace’s Jonathan Bryce responded:

“No, we want a system that is truly open. And one of the reasons is cloud is all about scale and a lot of the open core software…they follow this open core model where you can run a basic version of the system and then when you want to do something that’s really heavy duty then you pay for the extra features that let you do that…So an open core model for a cloud system doesn’t make a whole lot of sense to me to have a product that is trimmed down and works on a small set of servers or on a small number of clients, whatever it may be and then you pay to get to the full scale, it just doesn’t seem to apply to cloud. So that’s not the model that we’re going after.”

A rejection of the open core model was also highlighted as a key driver for NASA contributing to OpenStack. NASA currently uses Eucalyptus to power its internal Cloud. However, according to an article by Cade Metz, Eucalyptus’ open core model was getting in the way of NASA’s usage pattern. Metz writes:

“NASA chief technology officer Chris Kemp tells The Reg that as his engineers attempted to contribute additional Eucalyptus code to improve its ability to scale, they were unable to do so because some of the platform’s code is open and some isn’t. Their attempted contributions conflicted with code that was only available in a partially closed version of platform maintained by Eucalyptus Systems Inc., the commercial outfit run by the project’s founders.”

Open core isn’t going away:
On the surface, it would seem that the open core business model could lose its popularity amongst open source cloud infrastructure providers. Bryce’s comment about the features of cloud infrastructure “at scale” being too much of a table stake to only be available in a commercial extension to an open core product does appear relevant.

Cloud.com quickly followed up the OpenStack announcement with a pledge to support OpenStack. As noted above, Cloud.com utilizes an open core business model, and is unlikely to reject the open core model as a result of OpenStack. Rather, it’s more likely that Cloud.com will utilize OpenStack components within Cloud.com’s commercial product offering.

Next, considering Eucalyptus, cloud pundit and ex-cloud computing strategist at Canonical, Simon Wardley, writes:

“This is also surprisingly good news for Eucalyptus if they move towards an entirely open approach. In such circumstance, the probability is we’re going to end up with a straight forward “clash of the titans” between Eucalyptus and OpenStack to become the Apache of Cloud Computing. Don’t be surprised if Eucalyptus even go so far as to adopt some of OpenStack’s work. Marten Mickos is an astute businessman and there are many ways they can turn this to their advantage.”

It would appear that OpenStack simply alters the landscape of features that are publicly available in an open source package versus features that are only available to paying customers. It should be noted that product support and maintenance is a feature, one that can be bundled with a for-fee product.

Select products based on business needs, not license alone:
It’s also interesting to note that very few enterprises are in NASA’s position with regards to size of IT investment and skills in-house. While NASA engineers were ready and willing to contribute new features into the Eucalyptus open source community, few companies have the skills or governance to consider allowing their developers to contribute to open source projects.  Summary trend number 7 from the 2010 Eclipse survey results highlighted this issue.

To suggest that NASA’s buying or IT decision making patterns represents much more than the top 1 percent of IT buyers would be a stretch.

The overwhelming majority of enterprises would rather pay a vendor to deliver, maintain, support and enhance their private cloud software infrastructure than place that burden on internal IT staff. Whether the enterprise is paying for a closed source commercial product, a commercial product based on an open core product, or a subscription to an open source product, the product selection decision will be made based on business requirements much broader than “is the product open source or not?”

Vendors are increasingly aware that customers select products that are both easy to adopt and easy to migrate away from. The opportunity to migrate away from a software platform relies on open standards and open data formats, and multiple implementations of these standards and formats, to a much higher degree than open source code alone. Supporting open standards and open data formats has little to do with the business model that a vendor selects to generate revenue from its efforts. Keep this in mind when deliberating between open source, open core and commercial private cloud software infrastructures.

Follow me on Twitter at SavioRodrigues. I should state: “The postings on this site are my own and don’t necessarily represent IBM’s positions, strategies, or opinions.”

SugarCRM’s recent launch of Sugar 6 CRM raised the thorny “but is it open source” question yet again. The question puts too much weight on the accessibility of the product’s source code or whether the product has a large enough user community. Current and prospective SugarCRM customers would do well to heed the lessons from the current predicament OpenSolaris users find themselves in and make the product selection based on your business needs, and not aspects such as access to the source code and size of the user community.

Open source, open core or proprietary?
SugarCRM offers a free AGPLv3 licensed Sugar Community Edition and commercially licensed Sugar Professional and Sugar Enterprise editions. All three editions provide the user with the product’s source code. Paying customers with access to the Professional or Enterprise edition source code, are able to modify the code, but are not allowed to redistribute the source code as per term 3 of the commercial license.

SugarCRM officials noted that, like many other open source product, SugarCRM customers, while having access to the source code, virtually never make code modifications.

Not surprisingly, functional differences between the Community, Professional and Enterprise editions of Sugar 6 CRM exist. These differences, specifically the new user interface, which is only available to paying customers, has drawn attention from pundits and commenters.

SugarCRM’s Martin Schneider described SugarCRM’s open source positioning as follows:

“Open source doesn’t mean free and was never really meant to mean free. Open source runs through everything we do, it enables us to be transparent and gives customers more power.”<!–

But a key element of the open source definition is the right to distribute the licensed code, which is clearly restricted under the SugarCRM commercial license. Some open core products make the commercially licensed product’s source code available to paying customers. Had Schneider said something to the effect: “SugarCRM is an open source company; Sugar Community Edition is an open source product while Professional and Enterprise are open core products”, the debate as to SugarCRM’s open source credibility would not be such a hot topic.

User community or paying customers?
The other key issue is whether the new user interface, a fairly critical aspect of the product, can benefit from community input if it’s not available to free user community. Dana Blankenhorn writes:

Who will enhance this new interface? Who is going to test it, and nurture it, and grow it? Sugar’s answer is Sugar and its paying customers… What commercial customers pay for is, in part, the community they become honored members of. When a key part of a product is no longer accessible to the community, its value is reduced to paying customers.

I frankly believe Dana is putting too much value into the user community. This is not to say that the user community doesn’t matter. It does, especially for early stage open source projects. However, with SugarCRM’s large paying customer base, with upwards of 5,000 organizations, collecting user input regarding the new user interface, or any other feature, will be simple enough without the need to expose the function to the much larger free user community.

In many respects, SugarCRM’s “Go Pro” marketing campaign, an effort to convince users to become paying customers, is the best form of security for paying users. Namely, knowing that SugarCRM’s revenues continue to grow at a level that allows SugarCRM to invest in future product enhancements and remain a strong and viable vendor. No amount of free users can provide this form of security for a paying customer.

Learning from OpenSolaris:
Let’s switch gears to the OpenSolaris community for a minute. I covered their state of limbo, awaiting Oracle’s direction, in mid April 2010. Little has changed in the subsequent three months – prompting the OpenSolaris Governing Board (OGB) to propose disbanding the OGB if Oracle does not engage with the community by August 23. Some community members are already talking about whether they would be able to fork the OpenSolaris code base and found a new community outside of Oracle’s control. However, they are coming to the same conclusion that others came to in April, that, while OpenSolaris has a user community, it does not have the depth of developer skills to sheppard an operating system project forward. At least not enough to compete with the likes of Linux or Oracle’s Solaris developers.

This is an important reminder for SugarCRM users, customers and potential customers. As large and vibrant as the SugarCRM user community is, even with access to the product’s source code, expecting that another vendor will form out of the community to provide a better customer-to-vendor experience than SugarCRM does itself, is a big assumption – one which should not be part of a product selection decision. Keep in mind that vtiger has already forked the SugarCRM code, and yet, has not been able to provide a sufficiently strong value proposition to a large enough percentage of existing or potential SugarCRM customers.

I’ve said it before, but it’s worth repeating:

The best advice, however, may be to simply ignore — or at least put much less weight in — the availability of source code when making a product selection. More often that not, you will have too much at stake elsewhere to take on maintaining a forked source code should difficulties arise.

Follow me on Twitter at SavioRodrigues. I should state: “The postings on this site are my own and don’t necessarily represent IBM’s positions, strategies, or opinions.”

Reports of Dell’s decision to deliver Ubuntu-powered cloud infrastructure should motivate readers to evaluate Ubuntu as an alternative to Red Hat in the cloud.

Red Hat still stuck in cloud positioning mode:
Just two months ago I wrote about challenges with Red Hat’s Cloud strategy as being focused on retaining existing customers, not attracting new customers. Red Hat has since attempted to paint itself as the leader for cloud software, singling out VMware as its primary competitor going forward. However, it’s important to note that the new positioning doesn’t address the barrier to entry that I noted in my previous post.

InfoWorld blogger David Linthicum highlights an issue that Red Hat and other software vendors are facing as they consider cloud computing offerings and price points. David writes:

For instance, if you’re selling cloud storage at 15 cents per gigabyte per month, but your customers end up spending $1 per gigabyte per month for your storage box offering, how do you suspect your customers to react?

David’s example is focused on storage, but equally applies to the per hour cost of running an operating system, such as Red Hat Enterprise Linux (RHEL), on a public cloud versus in your data center.

Cloud pricing encourages customers to “price check” the yearly cost of a traditional software license or subscription versus the pay-per-usage cloud price for the equivalent software.

Ubuntu’s cloud growth:
Stemming from Canonical’s relatively modest customer base, especially outside of cloud deployments, the vendor behind Ubuntu doesn’t have to worry about existing customers doing a similar price comparison across pay-per-usage and traditional support subscriptions. This is definitely an advantage for Canonical over Red Hat.

Ubuntu’s usage on Amazon EC2 and Canonical’s claim of 12,000 downloads of the Ubuntu Enterprise Cloud are further evidence of Ubuntu as a viable alternative to Red Hat in the cloud Linux and virtualization arena.

Additionally, Canonical looks to have scored a coup with Dell selecting Ubuntu as the operating system and virtualization infrastructure for Dell’s forthcoming cloud servers. As The Register’s Gavin Clarke reports, these servers come out of Dell’s Data Center Solutions Group, whose servers power online properties such as Bing and Salesforce.com

Why Dell chose to work with Canonical, and not Microsoft or Red Hat on these servers is a moot point. Dell may in fact have similar plans with Microsoft, and maybe even Red Hat. What’s important is the vote of confidence in Ubuntu and Canonical.

Readers will point out that Dell’s history of supporting Linux is less than stellar. However, it’s important to note that the PC and server markets are very different. Linux share on PCs versus servers means that Dell can’t ignore the 30 percent of the server market seeking Linux solutions.

Heterogeneous data center & cloud environments:
Selecting Ubuntu for cloud deployments in conjunction with Red Hat Enterprise Linux or Novell SUSE Linux Enterprise for traditional data center workloads does introduce yet another environment to support. For some, the added complexity of yet another Linux environment to support means Red Hat, and Novell, have an opportunity to close the gap to Ubuntu in cloud deployments. For others, using Ubuntu in cloud deployments, regardless of their data center Linux selection, is a competitive differentiator, and a negotiation tactic against Red Hat or Novell in the data center. Where does your company land on this spectrum?

Follow me on Twitter at SavioRodrigues. I should state: “The postings on this site are my own and don’t necessarily represent IBM’s positions, strategies, or opinions.”

A debate has been raging over the popular open core business model that many open source vendors are utilizing today. Opponents caution buyers from using open core products because of a bait-and-switch that will lock-in buyers to a closed source product. Proponents of the open core model argue that it balances the rights of users with the revenue aspirations of vendors.

That there is no one true open source business model that open source vendors utilize would come as no surprise to InfoWorld readers – support subscriptions, professional services, dual licensing and open core are but a few of the business models utilized. It’s important to recognize that the business model an open source vendor utilizes has a direct impact on your rights and freedoms when utilizing a product from the vendor.

As little as five years ago, the support subscription business model was the de facto choice for new entrants into the open source vendor arena. In this model, there was only one version of the product, with equivalent features and functions, available to all users. Paying users were able to get professional support for the product in question. But customers realized quickly that they could run the product without support and address their support issues themselves or through community forums.

Vendors watched as 15 percent of paying support subscription customers decided not to renew their support subscriptions. This of course had an impact on paying and non-paying customers, since the revenue lost could have been used to fund further development of the product.

The open core business model grew in popularity as a means of addressing the lack of a sustained revenue trigger.

The open core model relies on a core product released under an open source license. However, that core product is expanded upon, often with enterprise features, additional testing and integration. The vendor sells this superset product under a commercial, not open source, license on a subscription basis. There are often license or contractual terms that prevent a company from continuing to use the commercially licensed product if they stop paying the subscription. In many cases, the source code for the commercial product is not made available.

ComputerWorld UK columnist Simon Phipps writes:

“But to use the package effectively in production, a business probably won’t find the functions of the core package sufficient, even in the (usual) case of the core package being highly capable. They will find the core package largely ineffective without certain “extras”, and these are only available in the “Enterprise Version” of the package – which is not open source.

To use those features, you are forced to be a customer only of the sponsoring company. There’s no alternative, no way to do it yourself if the value delivered doesn’t justify the expense involved or if you are time-rich and cash-poor. Worse, using the package locks you in to the supplier. If they prove a bad choice as a supplier, or if your business needs change, you have no real choice beyond “take it or leave it”.”

Simon makes a valid case in theory – one that IT buyers should be aware of.

However, IT buyers and others that rely on a given open core product, such a business partners that sell services around the product, have more bargaining power than Simon’s analysis suggest.

IT buyers can negotiate to put the source code of the commercial “enterprise version” in escrow should the vendor you choose get acquired or go out of business.

Additionally, since the core of the product is open source, and is fully functional in its own right, albeit for less than enterprise usage patters, little prevents a fork of the open source code. This fork could be driven by through a new vendor, a collection of business partners or a collection of customers that rely on the open source project in question. Contributors to the fork could deliver the enterprise capability that is lacking in the open source core product. While this too is theory, it’s theory that serves to keep the open source vendor from extracting too much value out of the community that forms around open source products.

Marten Mickos, former CEO of MySQL and current CEO of cloud start-up Eucalyptus, which follows an open core business model, writes:

“For instance, Compiere followed an open core model, and yet at one point a fork emerged based on the open core of Compiere. This indicates that open core companies operate within the major forces of free and open source software, and so it also indicates that the market is self-adjusting. If you go too far into the closed mode, you lose traction among open source users and you expose yourself to the threat of forks. Nothing prevents others from developing as FOSS some feature that the vendor has reserved for paying customers only. If you go too far into the open source mode, you may weaken your business model and fail to attract revenues to pay for your operations. Ultimately, customers are the arbiters of success. If they are ready to pay for access to the product or service, the company will have to be seriously mismanaged in order to fail. “

I tend to agree with Marten’s pragmatic view on open core products. Open core vendors must work to optimize revenue while not becoming too open or to closed. It’s imperative that IT buyers keep vendors form sliding to either end of that spectrum.  Using a product from a vendor that is “too closed” puts IT buyers at risk of using a product around which the ecosystem has dwindled.  Alternatively, if the vendor is “too open”, and isn’t able to generate sufficient revenue to invest in further product development, IT buyers are at risk of using a product that isn’t able to keep up with market requirements.

Follow me on Twitter at SavioRodrigues. I should state: “The postings on this site are my own and don’t necessarily represent IBM’s positions, strategies, or opinions.”