Black Duck Blog

Eran Strod
Director of Product Marketing
estrod@blackducksoftware.com
In a recent Back Duck survey, we found that companies doing software development are using significant amounts of open source software; about 22% of code was identified as originating from an OSS project.

The cost savings from strategic use of open source can free up precious software development resources and compress project schedules. To calculate how much, see the Black Duck ROI calculator.

Many developers and managers have anonymously used this calculator to help with the decision of whether to reuse existing software or write a software component from scratch. The calculator allows one to enter assumptions for different factors that affect this decision. For example, the average value input for the cost of a software developer was $79,000. This value varies by company and region. When companies compute the cost of a developer, they start with salary but add in other costs as well: benefits, overhead such as utilities and administration, and expenses such as dev tools and hardware. These costs typically add a significant uplift on top of salary. When the Linux Foundation published an estimation of the cost of developing Linux, they called this uplift the “wrap rate” and fixed it at 2.4 times salary. This figure originated from a well-known study by David Wheeler. With that in mind, the figure of $79,000 either represents salary only or reflects a lower cost region of the world not the major business centers in Europe and North America.

Additionally, people input 16,000 as the average number of finished lines of code produced by a developer in a year. This number happens to be much different than we would have expected. When you include architecture, design, debugging, QA, compliance and administration, the number of fully, tested, vetted code tends to be much less. The Software Engineering Institute at Carnegie Mellon, estimated this value at about 20 lines of code per day (~4440 per year). Developers may not have been considering these other costs when using the calculator so the 16,000 figure probably reflects just the creation of new code.

With these caveats in mind we can start to look at the compelling economics of using open source. The average size application input was 363K lines of code. At the average level of salary and developer productivity noted above, it requires 22 developer years or $1.8M USD to create a 363 thousand line application from scratch.

Phil Odence
Vice President of Business Development
podence@blackducksoftware.com
I was recently talking to prospect who was digging very deeply into how hard it would be for his developers to “game” Protex, i.e. get some open source code and modify it to the point that it would not be found in a scan. In the end, he was convinced that the analysis performed by Protex is sufficiently sophisticated that gaming the system isn’t worth it. Fooling the tool requires as much work as writing the code from scratch. However to me, the bigger issue is a fundamental belief that given the chance people will generally try to do the right thing.

Of course that can all fall apart under stress. About the time I was having the above conversation, NPR started reporting on the rampant break-ins and looting in Port au Prince. They got a backlash of reactions from their listenership who essentially took the position, “What the heck do you expect?” Yes, it’s understandable when people under stress break the rules and take what isn’t theirs.

Software developers today are all under great pressure to do more, quicker with less. Utilizing open source components is a great way out of this rock/hardplace position, so it’s no surprise that most developers today are making heavy use of open source. It is incumbent upon companies to provide their developers guidance (in the form of open source policies) and streamlined processes for managing their use of open source. Without guidance, the risk is that developers will not look beyond technical capabilities when selecting components. Or, in the other extreme, faced with a cumbersome approval process and under great schedule pressure, even God-fearing developers will look for ways around it.

There’s a great competitive advantage for companies that embrace the use of open source components. Those that provide policies to guide their developers and automate the processes for selecting, tracking and approving components will find their developers pleased to be more productive and doing the right thing.

Timothy Kenny
Director of Marketing
Tkenny@blackducksoftware.com
Everybody knows open source software is free, and many know it has other significant benefits for developers in productivity and enabling innovation, but there is no free lunch, as open source components are not free of obligations. Obligations around making enhancements available, attribution, use, the list goes on and your free lunch starts giving you indigestion.

A recent survey by the 451 Group found that 58% of companies surveyed do not have formal polices or guidelines for using open source. Recently, Artifex, which uses a “dual licensing” model (providing the software under both the General Public License (”GPL”) and a commercial license) for its MuPDF rendering engine, filed suit against Palm for alleged copyright infringement. This is the first lawsuit by a commercial open source vendor, which is said to be signaling a trend towards more litigation this year. With hundreds of thousands of open source projects available to date, coming to grips with the challenges associated with using open source can be difficult for the uninitiated.

The reason for this high percentage can be attributed to the fact that many companies never fully cover the basics of using open source software with their employees. On this topic Karen Copenhaver partner at Choate Hall & Stewart and Counsel for the Linux Foundation recently teamed up with Mark Radcliffe, partner at DLA Piper and General Counsel for the Open Source Initiative, to present a webinar on the basics of open source software, which covered open source definitions and the different types of licenses.

Eran Strod
Director of Product Marketing
estrod@blackducksoftware.com
There are many consulting firms that earn a living on the fear, uncertainty and doubt associated with the failure of IT projects. It’s not hard to find statistics warning of the many risks inherent in new software product or application development. Here are three of many examples:

• A market survey cited by CIO.com reports that 62 percent of IT projects fail to meet their schedules.
• IAG writes that “68% of companies are more likely to have a marginal project or outright failure than a success.”
• Standish Group’s well known Chaos Report describes over 80% of IT projects as being “challenged” or “cancelled.”

According to these oft-cited studies, it may be more of a surprise when a development project actually goes right.

I was pleased to see a recent 451 Group survey showing that 87.2% of 1,711 IT professionals, rated open source software as “meeting or exceeding financial-benefit” expectations. This comes as little surprise to those of us that work with and around open source. The increase in OSS adoption has been slowly and steadily on the rise – supported by the tough economy which has significantly pressured IT and engineering budgets. 451 Group further writes that 46.5% of those surveyed are more likely to adopt open source as a result of the current economic climate. This market transformation has driven robust demand for solutions like the Black Duck Suite which just finished another record year.  If properly managed from a risk and compliance perspective, the productivity and cost benefits of open source can be significant. My take on the 451 Group report is that strategic use of open source is being widely used to lower costs. In an environment where a majority of IT projects are delivered late and over budget, it’s nice to have a high probability success in the mix.

Karen Copenhaver
Exploring Jim Berets’s post entitled “Can JavaScript optimization put you out of compliance with an open source license?,” he makes a great point and will end up with lots of other examples of unintentional compliance failures – and I think they will become more likely over time.

In Heather Meeker’s book she talks about the false sense of security that many lawyers have over decisions based on differentiating between static and dynamic linking. Many years ago, when making decisions about memory use were important, deciding what was statically linked was significant. Now, when memory space is much less valuable, a program that studies programs to optimize their operations will decide if something would work more efficiently if it were statically linked and will convert a link from dynamic to static in order to achieve that efficiency. My plain English explanation may make a technical person’s skin crawl – but it is another example of how decisions that are made in isolation in a lawyer’s office – without any process or follow-through to support their technical implementation – can do more harm than good by giving everyone a false sense of security.

An interesting question is whether community consensus over time regarding compliance will have to move to reflect changes in technology. If it becomes more difficult and “costly” in terms of impact on performance or functionality to comply with the license terms, will an alternative emerge? For example, if there were a compelling reason to optimize code for very tiny devices sold without documentation, will a consensus form around use of a pointer to a website that includes all of the licensing information and corresponding source for the licensed code?

If you were to find that code sample in a code review, you would point it out as a compliance failure. If you were in due diligence, every one of those is a problem even if it feels trivial. It erodes confidence in the effectiveness of the company’s internal control programs. The better course is to reinsert the license text. It will take time for a consensus to emerge that might support another answer.