SEO Werkt!

I think we can all safely agree that open source software development is here to stay. Open, collaborative development has fundamentally changed not only how we code, but also the code we produce. It’s easier than ever to build complex solutions by reusing existing components. A new report from Sonatype examines the current state of open source in the enterprise. Although heavily slanted toward open source Java consumption, the trends are interesting. It’s also worth pointing out that Sonatype provides a solution for open source software management, so they have a stake in the game here. Their data is worth a look, though.

Nearly 80% of the enterprises surveyed consume open source software. Most interesting to me: two thirds of them are actively contributing code back to the upstream projects they consume. Also interesting to note is that just shy of half of all surveyed companies have a formal open source policy in place. And of those with formal policies, half of the respondents cite those policies as detrimental to the success of development.

The top complaints about formalized open source policies are:

• it slows down development
• we find out about problems too late in the process
• it’s not clear what’s expected of us
• there is no enforcement

Some organizations further restrict open source software usage by license, going so far as to verify the license of all components and their dependencies. At first blush that might sound like a big waste of time, but in reality that’s a good thing: open source license compliance is important, and fundamentally important to the longevity of open source in general. Of course, if these enterprises aren’t distributing their applications to others then license compliance with copyleft licenses like the GNU Public License isn’t as big of a deal.

Sonatype’s primary product, Nexus Professional is a repository manager that aims to solve many of the licensing, dependency, and procurement problems identified in the Sonatype survey (again, with a specific focus on Java). The survey highlights that 73% of enterprises stay informed on new releases of the open source components they use by manual web searches, or by directly visiting the projects’ websites. That’s clearly inefficient. Even established code sharing services like GitHub, Google Code, and SourceForge aren’t being as heavily utilized as they could be by the companies surveyed.

The primary motivation for this report is to demonstrate the need for Sonatype’s products, obviously. That focus, though, reveals useful general information. For example, the financial industry is the most likely to completely lock down open source developers to using specific approved resources. Another interesting revelation: the aspects of open source software most important to the companies surveyed are maturity, security, and overall code quality. License type is only of interest to a comparatively smaller portion of survey respondents.

Regardless of any challenges introduced by open source software, it’s clear that open source is gainin more popularity within traditional enterprises. Anything that can be done to simplify the consumption and compliance issues identified by Sonatype — for Java and every other language — is a good thing.

I’ve been harping for a while here on TechCrunch about the benefits of open source software. I often quote Canonical’s Technical Architect Allison Randal, who said “Free software is a fundamentally superior model for developing software.” Free and open source software enabled much of the innovation we write about here at TechCrunch, but it’s been slow to move into established enterprises, let alone the U.S. Government. That’s starting to change today with an announcement from the U.S. Consumer Financial Protection Bureau that states, unequivocally, “We use open source software, and we do so because it helps us fulfill our mission.”

The announcement goes on to state that “when we build our own software or contract with a third party to build it for us, we will share the code with the public at no charge.” The CFPB is making it clear that they get it with respect to open source software: they have a GitHub account for hosting their works and are sharing their open source policy as a GitHub gist in addition to a static HTML document on their own website.

According to Chris Willey, CIO at the Consumer Financial Protection Bureau, “Using open source software isn’t innovative compared to the outside world, and having a policy that says so probably seems odd to many in the tech community. But many federal agencies avoid open source software because they don’t have internal policies and procedures that allow it.” He observes, however, that the policy to share by default is absolutely brand new within the federal government. “Some tech-inclined agencies like NASA, NOAA, NSA and FCC share code selectively,” said Willey. “We want to share everything we make.”

We are a citizen-facing agency, so keeping pace with the rest of the world is a high priority. We think our online presence should be on par with the web’s most popular tools and communities. Enabling outside developers to contribute to our products makes that goal more attainable.

I asked Willey what kind of advocacy — if any — the CFPB was doing (or planning to do) for open source software within the government. He shared that they’re using GitHub Enterprise internally, and have fielded a number of questions from other agencies about how they procured that and set it up. “It’s hard for us to have these conversations with other agencies without implicitly advocating an open source philosophy,” Willey told me. “So instead of trying to sell open source to other agencies on principle, we’re finding that it’s a lot easier to prove the value of open source software by showing our colleagues the great results it has gotten us.”

I was curious whether the CFPB’s policy is the natural result of more digital natives taking government jobs. According to Willey, it was “simply the byproduct of building a government organization from scratch in the information age: we are able to craft our technology philosophy with a modern perspective.”

“We wrote this policy to make sure that our team always has the freedom to use [open source] tools,” Willey continued. “It’s a freedom that many other federal agencies do not have, and that’s because they lack a policy–or, in some cases, because they have policies that strictly forbid open source software.”

Hopefully more government agencies — in the U.S. and around the world — will start to adopt similar policies for the benefit of citizens everywhere.