Enterprises saving $26 million per project with open source? Not Exactly.

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.”

 

Amazon out to eat open source vendor lunches

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.”

 

Whitehouse.gov as a springboard for Open Source for America

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.”

 

With open core, the question is when to give up control

Matt Aslett writes an interesting follow up to his suggestion that open core vendors give up control over the “core” of their product offering. Matt writes:

“…open core vendors should consider releasing the source code for their core open source project under a more permissive license, or better still via an existing community/foundation.”

…

If the open source core has value it will attract a true community that will expand its development, with the ongoing contribution of the original vendor of course, while if the proprietary extensions are valuable enough the original vendor ought to be able to compete with proprietary rivals even if they are using the same code to build rival products.”

I agree with Matt’s conclusion, but I don’t think that established open core vendors can make this move. A vendor could choose the open community route from day one and reap its benefits. However, utilizing the open community strategy after the vendor has built an open core business is not likely to have the same results.

Let’s start with an example of a leading open core vendor ABC in the middleware market. ABC controls the development of their GPL’d community edition product. Some of ABC’s paying and non-paying customers have contributed fixes and maybe even a new feature to the community edition. Utilizing the open core business model, ABC is now a recognized brand, has upwards of $10M in revenue and is growing in the high double digits. Let’s say ABC decides to release their community edition product under a permissive license such as the Apache Software License 2.0 (ASL) and further attempts to take it to an existing open source foundation such as the Apache Foundation.

The key driver behind ABC’s move is to benefit from a larger community developing the community edition portion of ABC’s commercial product. But where would this community come from?

First, it’s unlikely that another commercial software vendor, XYZ, will join this new “open community” project. XYZ would not have the established user base or associated brand that ABC does; two key elements needed to sell the proprietary extensions. Also, since ABC has a head start on the proprietary extensions, and has likely chosen to develop higher value extensions first, XYZ has little opportunity to differentiate by delivering valuable proprietary extensions. It’s hard to envision the business case for XYZ to enter the community around ABC’s community edition project.

Second, you could argue that individual contributors will contribute to the project more than they were able to in the past when ABC solely controlled the project. This is completely valid. But I doubt that the contributions will be significant compared to those of a third-party vendor whose business relied on the project.

Now consider if the ABC had started developing its open core product in an open community fashion from day one. Other vendors with business interests would have been encouraged to join the community from early on. These vendors would each have had an opportunity to gain a user base and brand affiliated with the project. Each vendor would have had the benefit of starting with an equal footing, or thereabouts.  This situation is exemplified with Apache Tomcat, where at least 3 different commercial open source software vendors claim to be “the leaders of Tocmat development”.  Each vendor uses Apache Tomcat as the open core portion of a larger commercial product.

To me, the timing of choosing an open community model is critical. For established vendors, I feel it’s too late to consider an open community. But maybe I need to rethink this position?

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.”

 

IBM asks Oracle customers why pay more for less value

The open core business model has its roots in the traditional software business model. Open source vendors have learned what works in the traditional software business model and applied it to the open core business model. This learning has not been a one way street. This is the first in a series of posts discussing how open source and traditional software vendors are, or should be, learning from each other.

A few weeks ago the IBM WebSphere marketing team wanted to launch a competitive marketing campaign to coincide with Oracle OpenWorld. After some discussion we settled on “more for less” or said differently, a focus on value and price as the key message for the campaign.

Simply offering a lower price than Oracle WebLogic Server (WLS) doesn’t tell the customer enough to select WebSphere Application Server (WAS). That’s why the “value” message is important. In this case, the value of additional programming models and standards such as service component architecture (SCA), session initiation protocol (SIP) and communications enabled applications (CEA). Or the value of an integrated web cache and not having to pay for backup servers or unused CPUs on a virtualized server.

I’ve seen too many open source vendors simply beating the “lower cost” drum. At times they also highlight “not proprietary” as if this is a highly valuable feature; compelling enough to choose product X over a proprietary product Y. I don’t see value in “non proprietary” for at least two reasons. First, with open standards, the risk of lock-in is reduced not with the availability of source code, but the availability of multiple implementations of the open standard. Second, since the large majority of open source vendors are adopting an open core model, the product for sale can be just as closed source and proprietary as traditional software.

To reach CIOs hearts and wallets, open source vendors should rethink their messaging to move beyond just cost to talk about the “more” that they are providing for “less”. Note that “more” can actually be less, as in less complex. For instance, MySQL clearly provides a “lower cost for higher value”, in terms of less complex and fewer administrators required, than Oracle DB for certain use cases. This is why Oracle continues to value MySQL as part of the pending Sun acquisition.

There’s also a longer term reason to focus on higher value for lower cost than lower cost alone. The latter paints the vendor into the low cost corner. Going forward it’ll be difficult to increase prices as the vendor increases value delivered to the customer.

“More for less” certainly resonates in today’s market. This is true for IBM as much as any open source vendor.

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.”

 

Software features are customer driven

Since I’m a product manager by day, I was intrigued by Forrester’s Mike Gualtieri’s tweet:

“Software has become very bloated #btf09 because vendors love to add features and users hate to lose features”

Without doubt, this is conventional wisdom about the software industry. The first part of this statement is often considered the culprit much more than the latter. And to be honest, the latter doesn’t happen unless there is a better replacement for the feature that customers are using.

If we focus on the first part of the statement, it’s all too easy to point the accusing finger at vendors alone. However, features aren’t added to software products because a developer thinks it’ll be “cool” or because it’s a “challenging technical problem to solve”. Nor are features added because the vendor needs something new for the next product release; vendors typically have a backlog of features at every release.

Features are added in response to a widely held business issue that a customer is trying to remedy. Widely held means there’s an emphasis on adding features that 80% of customers will find helpful. That isn’t to say that niche features aren’t added for important customers; they are, but these features are not a top priority for releases.

All of the above is equally true for commercial open source, open core and traditional software. Gone are the days of open source vendor employed developers working on features that “scratch an itch”. Open source vendors have quickly added professional product management roles to ensure that the product contains features that customers will find valuable enough to purchase the product and ongoing upgrades.

Regardless of how open source and open core vendors position their subscription offerings, they’re selling products and related support and maintenance. This is no different from traditional software vendors do. As such, the customer driven requirement for new features which solve existing and new customer issues remains critical.

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.”

 

RIM needs to use open source more effectively

I’ve blogged about building native mobile device applications using a Web technology-based framework such as PhoneGap from Nitobi in the past. When I first wrote about the open source PhoneGap project in March 2009 I concluded: “If I worked at RIM, I’d take a trip out to Vancouver to talk to the Nitobi dudes. This framework is exactly what RIM needs to counter the trend of developers targeting the iPhone/iPod as the premier environment for mobile device applications”.

Fast forward seven months and RIM announces a beta of the BlackBerry Widget SDK that:

“allows web developers to package up their web assets into BlackBerry Widgets (small, discrete, standalone web applications that use HTML, CSS and JavaScript). A BlackBerry Widget looks, behaves and has the same security mechanisms as a native BlackBerry application. BlackBerry Widgets can be installed on a BlackBerry smartphone like any native application and can be extended to use device-specific information and data using the BlackBerry Widget APIs.”

Wow, sounds like an enhanced PhoneGap tuned for BlackBerry applications. With fingers crossed I pinged Andre & Dave to ask if RIM was using PhoneGap for this SDK. I’d scoured the BlackBerry Widget SDK website and knew the answer before Dave and Andre replied “nope”.

This was absolutely a missed opportunity for RIM to compete versus Apple, Palm and others using open source. No, I’m not going to suggest that RIM open source the BlackBerry Enterprise Server; that would be silly. Rather, I believe RIM could have saved R&D costs, increased the value of its BlackBerry platform and influenced developers building for the iPhone if RIM had built the Widget SDK on top of the open source project like PhoneGap.

RIM should be utilizing R&D investments more effectively by leveraging exiting open source projects. RIM could have built this SDK for a lower investment by staring with PhoneGap, or another equivalent open source framework. Of course there might have been a feature gap between what PhoneGap offers and what RIM wanted to deliver in version 1.0. However, assigning RIM developers to the PhoneGap project to add these features whilst leveraging all the other APIs in PhoneGap would have saved RIM the work of reinventing the wheel for those other APIs.

RIM would have also benefited from new features added by the PhoneGap community. A PhoneGap community member who loves his BlackBerry and wants to “scratch an itch” could contribute a PhoneGap feature that other BlackBerry developers would find extremely useful.

Finally, RIM would be contributing to a framework that developers are already using to develop iPhone applications. RIM needs to figure out a way to entice developers to build BlackBerry applications before iPhone applications. However, RIM should also be working to get developers to port their iPhone apps to the BlackBerry platform. As a PhoneGap contributor, RIM could offer a simple and painless porting option for existing and new PhoneGap-based iPhone applications.

I could come up with additional benefits for RIM, but these three are big enough for RIM to reconsider its strategy for delivering the Widget SDK. RIM could yet contribute all or part of their Widget SDK to an established mobile framework open source community and build its Widget SDK product from the resulting open source community code.

I suggest this strategy because I’ve witnessed IBM using it with great success. In the WebSphere division, we contribute to countless open source projects, including the Apache HTTPD, Dojo Toolkit and Eclipse Equinox projects. We then utilize code from these projects with IBM enhancements inside of WebSphere Application Server. This strategy allows us to, with less, do more.

I hope friends at RIM can learn a lesson from IBM’s use of open source for competitive differentiation. With Dion & Ben at Palm, you can bet that Palm is thinking about using open source more effectively within its strategy.

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.”

 

Open source code quality may not be improving

Data from the Coverity Scan Open Source Report found a 16 percent improvement in the quality of open source projects actively participating in the scan.  This is exactly the type of data that open source vendors and proponents want in their back pockets.  But is it accurate? Hold your tomatoes and let me explain.

Coverity used lines of code (LOC) before a defect was found to evaluate code quality and code quality improvements in a normalized fashion.  There are however two approaches for doing this calculation.

The first approach is to calculate the total LOC scanned across all projects and divide by the total number of defects found across all projects.  The result is the average number of LOC before a defect is identified.  This one step approach is best for talking about the code quality of the overall code base, across projects.  It does not however let us determine which projects are producing higher quality code versus other projects, or track results on a project by project basis over time.

The second approach is a two step process.  First, calculate the LOC per defect on a project by project basis.  Then, average those results to arrive at the LOC per defect across all the projects scanned.  The first step of this approach is good for understanding which projects are producing higher quality code and measuring a project’s progress in the quality arena over time.  However, averaging the LOC per defect across projects in step two disregards the size of a project’s code base.

Before we move on, keep in mind that a higher LOC per defect number is preferable regardless of which approach we use.  For example, a 999 LOC per defect result is better than a 100 LOC per defect.

As I’m sure you’d expect, or I wouldn’t be blogging about this, the two approaches provide different results due to how the code base size of a given project is weighted.  In approach one, projects with larger code bases are weighted higher than projects with smaller code bases.  The reverse is true for approach two.

Here’s an example:

Project A: 2,000,000 LOC & 2,400 defects
Project B: 20,000 LOC & 20 defects
Project C: 21,000 LOC & 15 defects

Using the first approach, the LOC per defect would be: 838

[2,000,000 + 20,000 + 21,000] / [2,400 + 20 + 15]
= [2,025,000] / [2,435]
= 838

Using the second approach, the LOC per defect would be: 1,078

([2,000,000 / 2,400] + [20,000 / 20] + [21,000 / 15]) / 3
= ([833.33] + [1,000.00] + [1,400.00]) / 3
= 1,078

Notice the impact of the much smaller projects B and C on the overall results.

The Coverity report used approach two.  When I first saw the data I instinctively used approach one.  Both approaches are statistically valid.  Which approach you use comes down to what you’re testing for.  Coverity is interested in determining code quality at the individual project level. The projects whose leads have submitted code into Coverity care much more about the individual project’s results. I was more interested to determine code quality improvements across the set of projects scanned.

Coverity reported that open source code quality of the projects scanned had improved from LOC per defect of 3,333 in 2006 to approximately 4,000 in 2009.  This led Coverity to claim a 16 percent overall improvement in the quality of open source projects actively participating in the scan.

Using approach one, I found that LOC per defect has worsened from 1,982 in 2008 to 1,560 in 2009.  This represents a 21 percent decline in the quality of the open source code base included in the scan.

2008: 55,000,000 LOC / 27,752 total defects found = 1,982 LOC per defect
2009: 60,000,000 LOC / 38,453 total defects found = 1,560 LOC per defect

Note that 2006 data was not included in the 2009 report, or else I would have calculated 2006 versus 2009.

Readers can decide which of these two figures, a 16 percent improvement or 21 percent decline, to use for their purposes.  Both are valid interpretations of the data.

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.”

 

Avoiding pitfalls when using open source code in enterprise software development

Having just completed the annual IBM Intellectual Property training, and while thinking more about the CodePlex Foundation, I saw the following Open World Forum conference track description:

“The growing use of Open Source and economics of outsourcing have made testing for intellectual property (IP) cleanliness and proper satisfaction of legal obligations an essential task for ensuring quality and market acceptability. Real or perceived IP issues can delay product cycles and derail entire projects or business transactions. “

Upon further digging, I realized that Protecode, a company I wrote about back in 2008, was playing a key role in this track.

It goes without say that enterprises using open source code within their software development process should have policies in place to protect the enterprise.  Clearly there’s a risk of contaminating a custom enterprise application by misusing open source code.  But in most cases, the enterprise can be safeguarded unless the derivative work needs to be distributed outside of the enterprise’s walls.  With applications delivered over the web, very few enterprises find the need to distribute their internally developed software.  However, whether the enterprise is distributing the derivative work or not, there’s also a risk of patent infringement.

That’s where Protecode comes in with its three pronged approach:

Enterprises can, and should, create policies for developers, on the enterprise’s payroll and contracted via consultants or off-shoring, to utilize open source code appropriately.  But that can’t be the only line of defense.  Enterprises must be able to retroactively and proactively ensure that code their developers are writing is free of intellectual property concerns.  Being able to analyze existing software assets with a product such as Protecode’s Enterprise IP Analyzer is step one.  But the real goal should be validating IP on the fly, with a product such as Protecode’s Developer IP Assistant.  There’s also the interim step of testing IP ownership during builds with a product such as Protecode’s Build IP Analyzer.

I wonder what portion of enterprises have analyzed their existing software assets to validate that they are in fact the rightful IP owners to the entirety of their internally developed software.  Or better yet, what portion of enterprises that analyzed their software assets were surprised with the results!

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.”

 

Run an open source GSM mobile phone network*

Slashdot reports that Harald Welte is operating an open source GSM network at the Hacking at Random (HAR) conference.  Welte writes:

“Here at the amazing HAR2009 hacker conference + camp, I have the pleasure of operating a camp-wide GSM network.

Under license of the Dutch regulatory authority, we operate two BTS with two TRX each, forming the network 204-42. The BTS are positioned on the top of a hill, with the antennas mounted back to back on a tree, each covering about half of the HAR2009 camp site. Every transceiver runs at 100mW transmit power, which is the maximum output as per our license.

From that tree, we run AC power and a single E1 line down to the GSM tent, where it runs into the Linux PC that runs our OpenBSC software. “

For those of us who aren’t mobile phone networking experts, BTS stands for Base Transceiver Stations, TRX stands for transceivers and BSC stands for Base Station Controller.

OpenBSC is a GPL implementation of major components of a GSM network. Welte is one of the key developers behind OpenBSC, which aims to:

• provide a basis for experimentation and security research with GSM from the network side
• document, publicized and point out any security related issues that we find as part of that
• learn more about GSM networks on a lower level, particularly the practical aspects with real-world equipment

Unfortunately, the project is not interested in:

• building a stable/reliable BSC/MSC for deployment in actual networks
• building something that follows the GSM spec to the last detail
• disrupting actual commercial GSM network

Since a government issued network bandwidth license is required to run a GSM network in most countries, few of us will ever run our own open source GSM networks.  Although it seems that countries like Russia allow the use of licensed frequencies for low-power indoor use.  So the title of this blog is squarely targeted at readers in Russia.  Kidding aside, I wonder while Welte and team aren’t interested in building a distribution that does fully implement the GSM specification.  The use of OpenBSC on Linux could be targeted at telecom operators in emerging markets.  Considering the growth in mobile phone usage in emerging markets, and network operator’s constant search for cost reduction, there could very well be a business here.

Any takers?

*Well, if you can get a government issued bandwidth license

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.”