Fears about the future of an open source vendor or project are laid to rest with the knowledge that “the source is available”. Trust in an open source vendor, project or product is often linked to source code availability. However, this trust is at the very least overstated.

I wrote about a license change to Solaris 10 a few weeks ago and made the conscious decision not to talk about OpenSolaris. Seeing as Oracle was still working through its acquisition of Sun, I felt it prudent to give Oracle more time to lay out their vision for OpenSolaris. My feelings haven’t changed. I use OpenSolairs below as an example based on current information available. I do not want to imply anything about the future of OpenSolaris. Large companies can take time to make decisions.

OpenSolaris is an open source operating system and Sun Solaris is a proprietary distribution of OpenSolaris. While Sun helped form an OpenSolaris Governing Board (OGB), decisions surrounding OpenSolaris releases and technology roadmaps remained within Sun’s control.

We can fork, right?!??:
Earlier this week the OpenSolaris mailing list was abuzz about the lack of information about a forthcoming release and the overall development model for OpenSolaris. Not surprisingly, a one commenter suggested that the OGB take a stand and ask Oracle to clarify the future of OpenSolaris releases or threaten to sever ties with Oracle. Said differently, “the source is available, so be warned Oracle”. OpenSolaris community member, Ben Rockwood, wrote a measured response:

“Here is where I want to be careful. Asking for autonomy at this juncture would be very foolish I think. If they grant it, they will essentially expect us to fork and re-establish the community without Sun/Oracle resources. That means the website goes, communication is severed, employees are instructed not to putback to the autonomous codebase, etc. I think it would go very very badly and we’d essentially help kill the community.

The size of the community at present is pretty small and relatively inactive. Support for Nexenta, Belenix, etc, is orders of magnitude less so. These projects are productive and active, but the numbers are tiny compared to the official community. Add it all up and I think we have little reason to think that an autonomous community would really have any real support unless we get a sudden and massive influx of contributing developers. So it is, imho, a non-starter.”

Another community member, Martin Bochnig, also cautious about suggesting a fork, asked:

“How are you going to replace the bright brilliant skilled and experienced Sun kernel engineers?”

Finally, community member, Damian Wojslaw, wrote:

“We do have a community. It’s alive and well. It’s a community of users and administrators. We don’t have community of developers. And this is why we can’t just fork off and start anew.”

A vibrant community can exist even while that community wouldn’t be reasonably able to support a fork. This is true for many open source communities – lots of users, very few of whom would be qualified to continue developing the open source project should a fork occur, and even fewer who would be interested in doing so.

Insurance when forking isn’t viable:
Adopting open source products from multi-vendor communities is the best insurance for enterprises. There is by definition multiple stakeholders that could reasonably be expected to guide the open source project forward should a fork be required. However, open source products developed by a single vendor controlled community are far more common. In these cases, the likelihood of an organization to reasonably support a fork is higher if a strong partner or system integrator ecosystem exists around the open source project. Another suggestion is to use the paid version of the open source project. Paying the vendor for its work is a good way of ensuring that the vendor isn’t motivated to do awkward things that encourage revenue while hurting users.

The best advice may be to simply ignore, or at least put much less weight in, the availability of source code when making a product selection.

Follow me on twitter at: SavioRodrigues

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

Lately there’s been lots of blog and twitter chatter about recognizing an open source product.  While an interesting intellectual exercise, the debate could also have real world impact on IT purchasing decisions.

Open source purity:
I used to spend time debating the open source “purity” of a given open source vendor.  I moved on when Shaun Connolly, of JBoss at the time, wrote this post titled “Open Source Community and Barack Obama”.  In 2010, it’s incredibly difficult to define an “open source vendor”, because virtually every IT vendor utilizes open source in their products, or contributes to open source or provides services around open source.

The recent debate about open source “purity” extends beyond the vendor, and instead focuses on products.  The debate is being spurred by the increasingly popular open core licensing approach and the delivery of software products through cloud offerings.  The 451 Group’s Matt Aslett writes:

“It ought to be simple: either the software meets the Open Source Definition or it does not. But it is not always easy to tell what license is being used, and in the case of software being delivered as a service, does it matter anyway?

The ability to deliver software as a hosted service enables some companies that are claimed to be 100% open source to offer customers software for which the source code is not available.”

In the perfect world, customers would pay vendors for the value they receive from usage of free and open source products.  Since that hasn’t really panned out, open core licensing and cloud delivery of open source software are gaining attention as leading approaches to capture revenue around open source products.

Keep an eye on freedom of action:
Customers using or considering purchasing a product that falls into the open core licensing category should be aware that the enterprise commercial product they purchase is unlikely to offer the same freedoms as the open source community edition that their developers likely used and became advocates for.  Some enterprise open core commercial products don’t even offer source code access.  This obviously limits freedom of future action versus using the open source community edition.  Other open core commercial products do provide source code access, but only as long as your subscription license is current.  As such, it’s important to understand how easily your company can shift from using the enterprise commercial open core product to using the open source community edition. Its important to understand if the enterprise features are really product extensions or are they integral to your usage?  Gartner analyst Brian Prentice has argued that customers will eventually need to evaluate and price the enterprise commercial version of an open core product.  This is all the more true if there isn’t a clear distinction between which kinds of features fall into the open source community edition versus the enterprise open core commercial product.

Customers using or considering using an offering that falls into the cloud delivery of open source category need to consider two elements of freedom of action.  First, is it possible to run the product on another cloud infrastructure or within the customer’s own data center?  Second, and often more important, is the customer’s data locked into the vendor’s cloud offering?

While usage of open source licensed products is heading in only one direction, it’s important for decision makers to understand that “open source” is used in many shapes and forms.  With no malice intended, your interpretation may not match your vendor’s interpretation.

Follow me on twitter at: SavioRodrigues

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

Successful open source vendors utilize business models that build a large user base through free software and monetize the adoption through some other product or service offering. In dated business terminology the free offering is considered a loss leader whose business case is supported by other offerings in the portfolio.

I’ve previously written that RIM needs to more effectively utilize open source software in its business practices. Well, RIM just demonstrated that they’re learning from successful open source vendors.

RIM introduced the free BlackBerry Enterprise Server Express (BESX), which offers wireless synchronization of BlackBerry smartphones with Microsoft Exchange or Microsoft Windows Small Business Server. While BESX is targeted at SMB customers, RIM still offers BlackBerry Enterprise Server (BES) as a priced enterprise grade product with additional enterprise-friendly features.

It’s interesting to not that BESX isn’t necessarily being used to build a user base that RIM will later monetize with BES. Rather, BESX is an attempt to build a user base that can be monetized through the sale of BlackBerry devices and ongoing monthly fees. This becomes vividly clear when one considers RIM’s revenue sources.

The “Device” category, not surprisingly, represents revenue from selling new smartphones. The “Service” category represents the monthly fee that RIM receives from carriers for every active BlackBerry device on the carrier’s network. The “Software” category represents revenue from the sale of packaged software such as BES.

While the “Software” category represented over $250 million in fiscal 2009 revenue, a respectable sum by most measures, it represents 2 percent of RIM’s revenue. By making BESX free, RIM hopes to make it more cost effective for small businesses to promote the use of Blackberry devices by their employees. As this occurs, RIM will capture “Device” and ongoing “Service” revenue.

Build adoption with free software and monetize adoption elsewhere in the offering portfolio. Seems like a very smart decision by RIM.

Follow me on twitter at: SavioRodrigues

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

By now you’ll have heard that the EU has approved Oracle’s acquisition of Sun. This is good news for Sun employees and for the broader open source vendor community. JBoss founder Marc Fleury recently wrote the following about the Sun/MySQL/Oracle situation while the EU was still deliberating:

“..here is the part that really bothers me: this is making OSS acquisitions look very dangerous and dicey.”

Marc has a point, some vendors in a position to acquire open source vendors may think twice, if even slightly, about acquiring open source vendors. However, I suspect that trepidation will be short lived. The software industry relies on acquisitions for growth, and it’s not as if a large number of closed source startups are being formed these days. However, one has to wonder if the valuations for open source vendors will be somewhat tempered going forward. This has more to do with market trends than the results of an open source acquisition; RedHat/JBoss, Sun/MySQL, Oracle/Sun or otherwise.

Firstly, open source is no longer an unknown to be feared and possibly revered by established software vendors. These vendors have gotten more comfortable cooperating with and competing with open source vendors.

Secondly, while acquiring an established open source vendor is still viewed as a great way to enter a market or expand offerings within a market, the shift towards cloud computing appears to be a more pressing trend to address. Said differently, why purchase adoption in the data center when customers are increasingly going to deploy workloads in the cloud, where a different vendor may end up winning with an offering built with the cloud in mind versus being adopted for the cloud.

I’m not suggesting we won’t see any further open source acquisitions. That would be a silly statement. Rather, expect a larger number of cloud-related acquisitions than open source vendor acquisitions and expect higher multiples for cloud-related acquisitions. Of course vendors that fit into both the open source and cloud-related categories will be amongst the most attractive targets. And truth be told, a startup in 2010 is more than likely to use open source to drive developer adoption and monetize that adoption in the cloud. As a result, it’ll become increasingly difficult to distinguish an open source vendor from a cloud vendor. Either way, the exit potential for these vendors looks bright.

Follow me on twitter at: SavioRodrigues

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

Checking my twitter feed before heading to bed, I noticed that Dana posted a story titled: “Enterprises saving $26 million per project with open source“.  There had to be a mistake in the title, right? I read on diligently.  Dana writes:

“A Black Duck analysis shows the average enterprise software project is 22% open source, saving an average of $26 million on each project.”

Those figures would, as written, suggest that the average enterprise software project costs $119 million dollars.

So I went back to the original press release from Black Duck which states:

“Black Duck surveyed over 175 customers that used open source software in hundreds of development projects over the past 18 months. The results revealed that an average product or application contains almost 700 MB of code, 22 percent of which is open source software.”

“Using the COnstructive COst MOdel (COCOMO) technique, Black Duck estimates the cost of developing the 22 percent of open source software used by companies in the study sample at approximately $26 million per product or application.”

When you consider that Black Duck’s customer base is skewed towards software vendors, these results make complete sense.  The fact that commercial software vendors use open source within their commercial product is well established.

The study doesn’t report the type of functionality delivered by the 22 percent of open source code represented in the final product.  Was it functionality that would differentiate vendor A’s product from vendor B’s product?  Or was it functionality that was considered a commodity? I’ll wager it was the latter.  Why would a vendor spend valuable and scarce development resources on building undifferentiated capability when a perfectly suitable alternative is available in an open source project?  Rather, a savvy vendor would spend their development resources on building differentiating capability.

I’ve spoken about vendors, but enterprise companies should not be expected to act much differently.  Well, at least enterprises savvy enough to use open source within their development process and mange that use with the help of Black Duck.

Follow me on twitter at: SavioRodrigues

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

News that Amazon Relational Database Service (RDS) provides a MySQL 5.1 relational database in the cloud has been met with a lot of interest.  On the surface this is good news for open source users and proponents.

When I read about RDS, I wondered if this was in fact good news for open source vendors.  I asked if Sun/MySQL was being compensated for Amazon’s use of MySQL in RDS.  Sun sources confirmed:

“The MySQL database that is used in Amazon’s RDS is based on the free, community version of MySQL.  However, for those Amazon Web Services customers that need MySQL technical support, Sun does offer that through our MySQL Enterprise subscription.”

At this point, it’s helpful to stop treating RDS as a competitive action against Sun/MySQL.  The rest of this post could apply equally to another open source project, the related open-core or dual licensed product and the related open source vendor. I fully expect to see Amazon continue to offer open source middleware components; RDS is the first step. I only mention Sun/MySQL below to help explain my thinking, not to draw any conclusions to its current or future market position.

Amazon’s decision to use the free version of MySQL to build RDS is completely sensible.  First, Amazon has the technical skills to support their usage of MySQL without having to acquire the MySQL Enterprise subscription. Second, this decision helps Amazon lower the cost of RDS, which makes RDS more attractive to customers.  This is clearly not good news for Sun/MySQL who is missing out on capturing some portion of the revenue from MySQL users spending on RDS.

Customers can still pay Sun/MySQL and Amazon to deploy MySQL Enterprise to the Amazon elastic compute cloud (EC2).  But with the introduction of RDS, Amazon is asking, why bother?  RDS reduces the need to manage, administer and support a MySQL environment. These are the key reasons one would purchase MySQL Enterprise.  RDS makes these three purchase drives less valuable to customers.

Until now, open source vendors have attempted to secure revenue by offering management and administration capabilities only through a for-fee product offering built around an open source core product.  Amazon has just thrown a major wrench into that strategy.  Why pay for the vendor’s “enterprise” product to obtain management, administration and support, when Amazon’s Cloud service minimizes the need for management and administration and includes support?

So what can open source vendors do?  Well, first, open source vendors have time to respond since the majority of workloads are not (yet?) in the cloud.  Second, proprietary features will be required in the “enterprise” version that are not available in the “free community” version of the product.  These features must not fall into the administration and management category.

Proprietary may just be an open source vendor best strategy against Amazon and other cloud providers.

Thoughts?

Follow me on twitter at: SavioRodrigues

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

Like many of you, I awoke Monday to read that whitehouse.gov was now running on open source products including Durpal, Red Hat Linux, Apache web server, MySQL and Apache Solr.

It goes without saying that this news has generated lots of excitement. I am however more interested in what this news means to Open Source for America (OSFA), a group advocating open source adoption by the US Federal government. I recently spoke to OSFA spokesman and Red Hat executive, Tom Rabon and concluded:

“Overall, it seems there is plenty of work ahead for OSFA, especially in the area of getting decision maker buy-in. Lucky for OSFA that its membership, and its members’ willingness to help OSFA reach its goal, continue to grow as well.”

In discussing the use of open source at whitehouse.gov, Tim O’Reilly, an advisor with OSFA, wrote:

“While open source is already widespread throughout the government, its adoption by the White House will almost certainly give permission for much wider uptake.”

I completely agree with Tim, as does OSFA’s John Scott who had the following to say via email:

“This is great news not only for the use of open source software, but the validation of the open source development model. We look forward to collaborating with the Whitehouse as they interact and join with the wider open source community to potentially release source code back to society.”

I was previously unsure how OSFA would get its findings in front of government decision makers. I was expecting to hear that OSFA had plans to schedule briefings on open source best practices for government decision makers. I assumed that these briefings would (further?) open the door to open source vendors securing contracts with government agencies. The OSFA could and likely still wants to take this approach. However, it’s great to see open source vendors getting a stronger foothold in US government accounts by themselves. Or at least through federally approved systems integrators endorsing open source.

As with any industry or market segment, some buyers are innovators and early adopters while others await the comfort of their peers. While individual open source vendors can win with early government adopters, the OSFA’s efforts will make it easier for the early and late majority government buyers to seriously consider open source.

The OSFA has been handed a golden springboard to leap from as it reaches out to government decision makers. Individual open source vendors stand to benefit from the OSFA not just through new revenue potential, but also from the OSFA encouraging government agencies to contribute code to open source projects. This truly is a win-win relationship between the OSFA and individual open source vendors.

Follow me on twitter at: SavioRodrigues

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