Black Duck Blog

Jim Berets
Vice President of Product Management
jberets@blackducksoftware.com
While this post is not about how software improves the environment, at least not directly, it is about how open source software encourages ‘green’ behavior by developers.

The catchphrase of green is Reduce-Reuse-Recycle. What better way to describe the benefits of open source software?

Reduce. In the green world, this means “consume less”: don’t run two separate errands when you can combine them into one car trip. Many organizations we speak with these days talk about their desire for simplification and “code reduction.” Their motivations range from decreased operating and maintenance costs to increased performance. Code reduction activities include examining existing applications and removing and/or creating reusable components out of duplicate code, and also eliminating unused (or lightly used) applications or software components entirely. Code reduction also includes management processes around incoming code, particularly open source – making sure that new open source software components are not introduced when others that serve the same function are already in use and suitable. The result: more efficient development organizations and applications.

Reuse. In the context of green, reuse means using the same item repeatedly: bring a cloth bag to the store instead of using disposable “paper or plastic.” Why? Less waste. Why do people find open source helpful? It’s the ability to reuse code someone else has already written, and avoid wasting resources (developers, time) re-inventing the wheel. It is also about standardizing on reusable components and versions like, for example, Apache Tomcat, Hibernate, Spring, and so on. The result: lower operating and support costs, and more shared expertise in the development team.

Recycle. Recycling is making something you have already used available for someone else to use, sometimes (but not always) in a different form. Let someone use your baby’s old crib rather than throwing it in the trash. Take a product and recast it into another form for a different use, incorporating the old material: plastic bottles are recycled into plastic decking. How is code recycled? Developers contribute code to open source projects, enabling it to be incorporated into other products or applications. OpenSSL, Expat, and zlib are contributed, and are subsequently ‘recycled’ by Android in cell phones. The result:higher function capabilities for Android with a faster time-to-market and lower development cost than starting with raw materials.

Here at Black Duck we seek to be ‘green.’ We build our applications using a common platform (reduce), use open source when it meets the business’s needs (reuse), and make improvements to projects like Apache Lucene and PostgreSQL (recycle).

Be a Green Coder. Reduce. Reuse. Recycle.

Jim Berets
Vice President of Product Management
jberets@blackducksoftware.com
Black Duck recently held its annual Customer Advisory Council (CAC) meeting. These annual meetings are essential for us to stay in tune with the needs and priorities surrounding our customers’ use of, and contributions to, open source software (OSS), to foster information sharing (and there’s no better way to do that than spending a day together talking face to face), and to inform and shape our strategy.

We were fortunate to have 16 high level representatives who are responsible for managing the use of open source software at their respective companies. The meeting’s presentations included a “State of the Union” address by our fearless leader (and CEO), Tim Yeaton, briefings on our product roadmaps, and a first look at some of our ideas for the future; lots of interactive discussion and feedback throughout!

Some key observations from the meeting:

• The largest corporations in the world increasingly view OSS as an integral part of their software development strategy. The majority of the participants are Fortune-500-class companies (> $10 billion annual revenue), and the others, while not quite as large, are extremely well-respected brands in their own right. Of the attendees, approximately 3/4 were senior software engineering managers or senior architects.

• OSS management is increasingly being built into the day-to-day processes used by development organizations. Participants cited the need to understand OSS content throughout the software development lifecycle in order to avoid last minute “stop-ship” situations. Integrating OSS management with tools such as IDEs, version control systems, and, build systems is seen as essential to this goal.

• Vetting open source for use is, for most companies, a decision that carries significant economic value. Tactically, it requires a developer / architect to invest considerable time and effort assessing alternatives, and it subsequently requires business, legal, and security review to balance the benefits of the candidate alternative with risks. At a strategic level, the capabilities and community around the OSS selected have a significant business and economic impact on the application or product in which the OSS is being used.

It was a terrific meeting and we thank all of the participants for their comments, suggestions, and insights, and the significant investment in the time that they made with us.

Jim Berets
Vice President of Product Management
jberets@blackducksoftware.com
Definitively knowing what encryption is in use lowers security risk

On February 16, Version 2.0 of the CWE/SANS Top 25 Most Dangerous Programming Errors was released. The Top 25, developed collaboratively by more than 30 cyber security organizations, are the most widespread and critical errors that lead to serious software security vulnerabilities and attacks.

“Use of a Broken or Risky Cryptographic Algorithm” (CWE-327) made the list, coming in at #24. Many companies unwittingly and unnecessarily expose themselves to this risk, which could result in the disclosure of sensitive information.

To avoid such a risk, the CWE/SANS report authors recommend the following:
• “Use a well-vetted algorithm that is currently considered to be strong by experts in the field, and select well-tested implementations.”
• “Periodically ensure that you aren’t using obsolete cryptography.”
• “Automated methods may be useful for recognizing commonly-used [cryptography] libraries or features that have become obsolete.”

For those of you familiar with us, one of the key capabilities in Black Duck Export is scanning for and detecting cryptography in code. While one use of Export is ensuring compliance with government export controls surrounding encryption, a key part of this is to detect which crypto is in use. Using our technology, Black Duck conducted a study of its own revealing encryption algorithms widely embedded in open source software.

The CWE/SANS recommendations do work. On multiple occasions we have heard from Black Duck customers who have discovered, to their surprise, that the encryption algorithms they were actually using was much weaker than they intended.

According to the Ponemon Institute’s most recent U.S. Cost of a Data Breach Study, the cost of data breach incidents to U.S. companies is on the rise. The average total per-incident costs in 2009 were $6.75 million, compared to an average per-incident cost of $6.65 million in 2008.

Another good reason to make sure you know your code so that your software development teams and your organization can have the peace of mind to focus on your top business objectives.

Jim Berets
Vice President of Product Management
jberets@blackducksoftware.com
Can JavaScript optimization put you out of compliance with an open source license?

Google recently announced its Closure Tools to help developers build high-performance JavaScript applications (like Google’s own). Closure Tools include Closure Library, which Google describes as their “’standard JavaScript library’ for creating large, complex web applications.” The contribution of Closure Tools, under the Apache License v2.0, is yet another example of Google’s helping to enable high-performance webapps. And the community owes them a “thank you” for doing this.

Google’s contribution got me thinking, however, about a peculiarity of open sourcing JavaScript. JavaScript moves from a server to a browser in source code form – as readable text. When modifications are made (“Derivative Works” created), the Apache License requires the preservation of the original copyright notice when code is redistributed in source code form. To be specific, the Apache License, version 2.0, says, (Section 4.3 Redistribution) “You must retain, in the Source form of any Derivative Works that You distribute, all copyright, patent, trademark, and attribution notices from the Source form of the Work, excluding those notices that do not pertain to any part of the Derivative Works.”

Now that would not normally be a hard thing to do were it not for a certain class of programs: JavaScript optimizers. Examples are Google’s Closure Compiler, Yahoo’s YUI Compressor, Jscompress, Dojo compressor, etc. – that a developer can use to prepare their JavaScript for the highest-performance user experience.

Optimizers are programs designed to be run over JavaScript source code and improve its subsequent run-time performance. One of the many optimizations typically performed by the optimizer is to compact the JavaScript as much as possible. This involves removing whitespace (blank lines, spaces), removing dead (non-executing) code, and removing comments. Think about that last one though: removing comments will remove the copyright notice and license text.

See, for example, this fragment from the Closure Library. The optimizer will remove the copyright notice completely, and the only JavaScript delivered to the browser will be the code itself.

I’d be interested in thoughts on this from blog readers. Is this an issue?

Jim Berets
Vice President of Product Management
jberets@blackducksoftware.com

Deciding which open source components to use in a development project requires consideration of a variety of factors including suitability for the problem at hand, licensing terms, quality, security, and supportability.

Coverity recently released a report showing that OSS continues to improve in quality. The report, which analyzed more than 280 open source projects found “the overall integrity, quality, and security of open source software is improving.”

The most highly vetted projects – Samba, tor, OpenPAM and Ruby – graduated to what Coverity calls “Rung 3″; an additional 32 projects graduated to “Rung 2″ because they “eliminated multiple classes of potential security vulnerabilities and quality defects from their code.” (Higher rungs indicate the resolution of issues identified at lower rungs, and a higher degree of analysis by Coverity’s tools.)

Reviewing the 36 “Rung 2″ projects using data contained in the Black Duck KnowledgeBase yields some additional insights:

- The quality of the Rung 2/3 projects stems at least in part from longevity and breadth of use. They are, on average, more than 8 years old.

- Vitality matters in selecting OSS. The communities behind these projects have collectively delivered more than 1,300 releases, at an average of about 5 releases per year, per project.

Mounting evidence supports the view of open source as a cornerstone of application development and IT infrastructure. The Black Duck KnowledgeBase of over 200,000 open source projects provides our customers with important project vitality information, as well as license and other metadata, to support making good choices when selecting components.