• Steven J. Vaughan-Nichols gave his review on the Cinnamon throwback to GNOME 2.x with his ZDNet blog, “Mint’s Cinnamon: The Future of the Linux Desktop? (Review).”
• Mr. Vaughan-Nichols also blogged about Red Hat’s decision to extend the lifecycle of RHEL’s 5 and 6: “Red Hat extends Red Hat Enterprise Linux lifecycle to ten years.”
• Greg Kroah-Hartman joining the Linux Foundation was covered by Joab Jackson in his ComputerWorldUK article, “Linux Foundation hires kernel developer Greg Kroah-Hartman.”
• On SDTimes, Victoria Reitano wrote, “Mentors fuel growth for open-source communities,” about FOSS foundations that are creating programs to help foster developer community growth.
• Brian Proffitt reported on the impending official foundation status of The Document Foundation in his ITWorld article, “LibreOffice’s foundation just weeks away.”
• On Campus Technology, Dave Raths wrote, “Industry-Funded Software Research Goes Open Source,” about how companies, like Intel, are funding software research at universities.
• The H reported on the UK government’s new website, built mostly with open source: “The open source behind gov.uk revealed.”
• Julian Horsey’s article on Geeky Gadgets discussed details around the new open source tablet, Spark: “$265 Spark Linux Tablet Detailed And Launch Dates Revealed.”

For those of you who enjoy clever rap song remixes, do I have a treat for you?! If you <3 Drupal (and Kanye West), you’ll love “‘Drupal, Drupal, everybody Drupal’.” And if you’re as anxious excited about Sunday’s Super Bowl as I am, I have a couple of fun tunes to pump you up before the big game – We’re gonna turn Indy into “Pat City”, cause “We’re the Patriots and You Know It!” Go Pats! (Sorry Giants fans)

• Is that the same as outsourcing?
• We openly compete all our acquisitions and procurements
• Sorry we are a ____ shop (insert favorite business application/enterprise platform provider)
• Never heard of it

Once in a blue moon, you may get a positive response that embraces the technology and practice. The reality at the enterprise level is often that, despite the qualities and advantages of open source, it’s rarely deployed.  Here’s why….

Reason #1 Open Source is not an Enterprise Priority – Business Objectives

Most business priorities are focused on business objectives such as sustaining growth, new ventures, increasing customer loyalty and budget optimization (i.e. cost cutting).  These are the priorities which seek to satisfy shareholders, owners of equity or, in the case of non-profits, fulfilling the mission. IT rarely makes the list, and when it does, is seldom amongst the top three.  Furthermore, IT objectives are commonly linked to budget optimization which translates to doing more with less.  Most IT enterprise shops have taken the easier shortcuts by embracing server and storage consolidation, virtualization and outsourcing, but you will notice that neither the objective/priority or the means to achieve it necessarily demands open source – as in the short-term success can be achieved with proprietary as well as open source solutions.

Reason #2 Open Source is not an Enterprise Priority – Groundswell through IT

Very few organizations or systems change themselves from the bottom up, unless you are talking national liberation and revolution.  The push for open source artifacts and practices comes today from within the ranks of IT, sometimes from architects, planners and a few insightful executives, but mostly from the operations and development resources that have encountered, used and appreciated the products of open collaboration.  Some changes to open source can be assimilated into the yearly projects and programs, but the cost of major change, such as adoption of open methodologies, especially collaboration and knowledge sharing, prevents any of those tasks from becoming comprehensive or culture-changing.  Strategic changes still come from the top and rarely does an enterprise board canvas its lower levels for advice and input.

Reason #3 Open Source is not an Enterprise Priority – Lack of CIO Leadership

Of course there are open source leaders, and many of the brightest and most communicative are alive, kicking and spreading the word.  But there are few at the Enterprise level outside of IT; few of the ones that succeed like Jeff Bezos at Amazon, or Meg Whitman at eBAY are entrepreneurs who have forged their organizations into the vision they perceived through their understanding of open source and open methodology.  Other CEO’s have taken notice and are following their example.  This success is attracting the attention of mainstream industries, who are constantly being challenged to respond to accelerating market pressures, constant innovation and repeated efficiency initiatives.  And though the mainstream is trying to play catch-up with Netflix and LinkedIn, its ability to countenance open source is hindered by legacy attachments to proprietary vendors and solutions.

There are opportunities in utilizing the cloud where open source is economically attractive, but these solutions tend to be discrete rather than systemic, meaning they satisfy a small set of business objectives, not all.  Furthermore the more separate and discrete the number of cloud solutions, the harder it becomes for IT and architects to integrate enterprise processes, data and governance. The companies that have gone down the open source trail are those that have managed to maintain platform integrity from the outset.  For established industries to follow suit, they need to do two things: understand the value of platform integrity and why open source is the optimal base, and how to build a strategy to get there and migrate from their non-open legacy systems.  This is the role of the CIO, where they can shine as innovative and proactive members (or prospective members) of the board.  This is the area of need in American industry: CEOs with vision and CIO’s with knowledge of how to achieve it with open solutions and methodologies.

Related articles

• Open Cloud Visionaries: John Engates, CTO of Rackspace (forbes.com)
• An Open Source Dust Up: Fighting a Corporation (arnoldit.com)

A couple weeks ago the DoD hosted an event to solicit public comment on its acquisition regulations. Specifically, the department was asking, “Hey, is there anything that we are doing that makes it hard for contractors to use open source?” with the idea that if there was, they would consider changing it.  The event drew 40 or 50 people, most of them lawyers and contractors. The discussion was directed to two people from the Office of Defense Acquisition Regulations and three lawyers respectively from the DoD, the Army and the Air Force.

Defense’s support for the use of open source software has been evolving for several years, but the big breakthrough was an October 2009 memo from David M. Wenngren, the then CIO, which takes a strong position in favor of open source. It begins:

To effectively achieve its missions, the Department of Defense must develop and update its software-based capabilities faster than ever, to anticipate new threats and respond to continuously changing requirements. The use of Open Source Software (OSS) can provide advantages in this regard.

The memo itself is only a few paragraphs, but includes a two-page attachment with more detailed guidance. Further, the memo references a massive set of FAQs, which not only outline DoD’s position, but are a useful treatise on open source in general.

An interesting aspect of the guidance is its position that open source “meets the definition of ‘commercial computer software.’” (Actually it qualifies “…in almost all cases,” but I understand from an insider that this was just a cover-your-ass addition by the lawyers.) The position is important because the acquisition regulations are well set up for commercial computer software; if OSS were somehow a different animal, that would imply a need for change, something which the government doesn’t seem to do very quickly.

So, the DoD’s a priori view is essentially that the regulations, as they exist today, don’t impede contractors from using open source in their deliverables, and it is that position that they were testing with the meeting. I lead off the presentations and essentially supported the government’s position (easy for me to say!). The rest of the speakers were mostly contractors (including Raytheon, Northrop Grumman, Red Hat and some smaller ones). There was mild grumbling about the difficulty in warranting software that comes with no warranty, but the collective wisdom generally acknowledged that the source availability gave contractors the ability to address issues. And, there was discussion about a couple of “corner cases” where certain licenses had clauses, which could conflict with federal law. However, by and large the supplier community feels encouraged to use open source and not legally impeded.

As a citizen and open source advocate, I am encouraged by the DoD’s position and was even more so when I got a call from a congressional staffer the next day interested in getting help broadening the DoD’s progressiveness into the rest of the federal government.

Organizations must consider the policy and process decisions and ongoing governance and ALM process implications that come with the use of OSS, including:

• Technical, quality and operational challenges
• Regulatory/compliance issues
• Security and brand concerns

Technical, quality and operational challenges

How do organizations solve technical, quality and operational challenges that rear their ugly little heads when open source components are brought into the mix?  You’ll want to ask yourself what code acquisition processes you have, how automated they are (i.e. will developers embrace the process or feel controlled?) and then how you plan to maintain components once you’ve approved them for use.  Do you encourage developers to contribute to the open source community?  Have you engaged an outside firm to help maintain your software assets, whether closed source, open source or internally developed?  Answer these questions and you’re well on your way to overcoming operational challenges.

Regulatory/compliance issues

There are really three issues here: the first concerns your use of open source, how it interacts with critical business data, and whether its use meets the obligations of regulations including Sarbanes-Oxley, Basel II and III, PCI and export regulations.  Second is whether its use complies with your internal policies.  Third, especially concerning software that you’re distributing, is whether license obligations are being met.

Security and brand concerns

You’ll want to be sure that you regularly check for security vulnerabilities on all of your open source software and components within your application suite.   And, aside from the obvious brand concerns that a lawsuit might generate, the greater damage just might be your organization’s relationship with the open source community.  Think about this one… if an organization becomes truly efficient, then better than 80% if the software will be open source, enabling development teams to use their precious time to innovate.  You’ll need to consider how you’re contributing back to the open source community to enhance your brand and further empower your developers.

Smart developers already ask, “Why should I write it, if I can download it?” It’s in every development organization’s best interest to have an answer to that question: download it, but ensure what you download and use is the best code for your requirement.  And make automating the management, governance and secure use of open source with the right processes and technologies a priority.

• On InformationWeek, Eric Zeman reported on the big announcement from Hewlett-Packard about the details of its plans for WebOS: “HP WebOS Open Source Timeline Revealed.”
• Another big story from early in the week was the first open source release of the Google/MIT App Inventor Android toolset, covered here by Lawrence Latif in The Inquirer article, “Google and MIT Open Source App Inventor for Android.”
• On ComputerWorld, John Ribeiro’s article covered the alpha release of Tizen’s source code: “Upstart Mobile OS Tizen Previews Code.”
• Andrew Myers reported on Stanford University’s open source application, SU2, in his article, “Aero-Engineers Debut Open-Source Fluid Dynamics Design Application,” on PhysOrg.com.
• On NetworkWorld, Joe Brockmeier wrote an article on “How Open Source Licenses Affect Your Business and Your Developers.”
• The Black Duck Open Source Rookies were featured in Darryl K. Tafts’s eWeek slideshow, “Application Development: Top 13 New Open-Source Projects of 2011.”
• Apache’s Ross Gardler published, “Be Lazy, Be Fast,” on ComputerWorldUK about why Apache’s ‘lazy consensus’ approach to open source projects works.
• The H posted, “Linux Foundation: How to Contribute to Open Source Projects,” about the recently published document and announcements from the Linux Foundation.

Need to get a Cloo? Check out the video clip for this very interesting app on Planetizen, “Friday Funny: Open-Source Bathrooms?”

You can’t see an announcement of something, then measure its immediate success in the market, and draw final conclusions about an open source effort. It’s not like the iPhone and its seemingly instant market penetration.

Few understand this better than Josh McKenty.

McKenty, CEO of Piston Cloud, is more than a talented programmer, founding architect of NASA’s Nebula cloud computing program, driving force behind OpenStack itself, and the creator of his own juggling trick, the McKenty Madness. He’s also a first-rate analyst, a long-time observer of technology trends, and something of a tech historian.

“The cloud is the third great transition,” of computing, he told me. “We had mainframe to PCs, then the Internet. Now the cloud. I think it’s that big a deal. In five years everything will look like cloud.”

To understand how cloud will develop, you have to understand how the Internet developed. It’s not what you thought.

“What made the Internet happen is we had private and public networks, joined together, running the same protocols, speaking the same language. The security challenges got dealt with in private networks first, and they matured earlier. The public network was mostly a bunch of dial-up modems.”

In other words, the hard work of building the Internet went on under the surface, for decades, before most people knew what it was. Hard things had to be done that today are invisible, like BGP, the border gateway protocol, which controls modern Internet routing.

These kinds of big jobs can only be done in an atmosphere of collaboration, many people working together, focused on the mission rather than the money or the credit.

“Look at the Linux timeline. Go from the first release to the first commercial distro to the first OEM deal to the 10% of the data center to passing Microsoft in the data center.” It’s a process that took decades, not months, not just in programming, but in education. “If you wanted to put a web server on the Internet in 2000 you should never have considered Windows, but it still had the market share.”

Cloud will be the same. Hard work needs to be done first, under the surface, before it can really explode onto the marketplace. Even after 95% of the technical work is done, education will be required before it’s accepted. Just as with Linux.

“We’re not going to get hybrid cloud nirvanas until the private cloud has the security and integration enterprises need. At that point we’ll burst out. No one wants to burst without policy management. No one wants geographic location without policy guarantees. No one wants to burst out until they have identity settled. Those features will be built on the private cloud first.”

So rather than moving to San Antonio with OpenStack, McKenty moved to San Francisco to launch Piston Cloud. Its commercial focus is security and regulatory compliance, what McKenty calls cloud audit. Piston Cloud has taken the basics of this and contributed it back to the OpenStack project, while doing proprietary builds for government, health IT and financial services, where security is paramount and buyers prefer a proprietary solution.

To McKenty, the open source part of the cloud structure needs to be as wide as possible, the proprietary parts narrow and customer-focused, in order for these hard tasks to be done.

“While OpenStack is a great framework, it’s not really a product. It’s not a stand-alone binary you can just run. To make it a product you have to make a lot of decisions – which hypervisor will I run, what will be my network model, my authentication model, my best practices for logging – they all get put into your product and make it fit for a particular environment, with trade-offs.”

Until the hard questions of cloud are settled, in other words, a cloud is not a cloud is not a cloud. Every cloud will be unique.

When companies like Microsoft or VMWare say they have a single cloud operating system, they’re claiming more for private clouds than they can deliver. Because right now, by necessity, every private cloud is going to be a one-off, McKenty believes.

Until these hard questions are answered. Which takes time.

It’s sort of a Moore’s Second Law process, McKenty admits. The effort required expands exponentially as the job grows more complex. “Every time I make an estimate I double it, and then it’s double that again when I say it. It feels like there’s two years of work, it’s probably going to take four years to engineer it, and eight years to adopt it.”

But this doesn’t fit with how media narratives are written. Reporters want a good guy, a bad guy, and an immediate resolution. Maybe Microsoft is the bad guy, maybe Rackspace is the good guy, or Red Hat. None of that is true.

What is true is that the more all these companies work together, and McKenty believes OpenStack is the best basis on which to do that work, and the broader that open source work is, the more visible the code is, the more people can get at the central questions and the sooner they’ll be answered.

“The only way to get it right is with a broad community, building implementations, trying them at scale and keeping at it.”

Not the clear answers you may have been looking for. But real life and a reporter’s narrative are of necessity two different things.

For organizations looking to start an industry collaboration, there are four key challenges they must address:

1) How to share the technology

2) The process they will use to develop the technology

3) How control and decision making are established

4) How the community will grow and prosper

It turns out established open source communities, like the Eclipse Foundation and Linux Foundation, can easily address these challenges.   It is interesting to examine why open source communities are better suited for these types of collaborations than other models: mainly, that the fundamental building blocks for industry collaborations, things like technology licensing, development processes, governance and community building, have already been established by these existing open source communities.  More specifically…

1.  Technology Sharing/Licensing.   Any industry collaboration needs to address how participants will share the results of their collaborations.   Established open source communities have defined agreements regarding how participants agree to share their inputs and a defined license for how the output will be shared.   If the industry collaboration is being setup to freely share the technology without royalties, then open source licensing is a proven model.

2. Development Process.  Open source communities have been very successful at enabling large-scale distributed development.   The principles of openness, transparency and meritocracy are pillars of any successful open source communities.   There are many examples of industry collaborations that have been plagued with the ‘design my committee’ mentality that inhibits the development process; however, the development processes and principles of open source communities have proven to deliver successful technology.

3. Governance and Control.   Control and decision making are important details for any successful industry collaboration, especially if the participants are competitors in the same industry.   Open source foundations offer a vendor-neutral environment to establish collaborations.   Most open source foundations have recognized bylaws and decision making processes that suit industry collaborations.

4. Creating a community.  The initial founders of an industry collaboration often want to encourage new participants and a wider community of users and adopters around the technology.   The barriers to entry for open source communities are generally very low for participation.   Tim O’Reilly coined the term ‘architecture of participation’ to describe how open source communities are built to encourage community engagement.   Industry collaboration’s that aspire to create a broader community can use the open principles of open source to create their own community.

As Andrew has suggested, communities like the Eclipse Foundation and Linux Foundation ‘bring a culture and a practice of openness balanced with commercial needs’ that are ideally suited for industry collaborations.  As vertical industries look for new ways to collaborate, I expect we will see more of them choose open source as the model and implementation for their collaboration.

In just one simple search, I found 42 different monikers identifying the same license – a few examples:

• The Apache Software License, Version 2.0
• Apache 2.0 License
• Apache 2
• Apache License, ASL Version 2.0
• Apache-2.0

And it wasn’t just Apache; I found the same result for the GPL, CDDL, BSD, and others.

While that may not immediately raise a red flag, for those of us concerned about license information, this lack of standardization is enough to keep us up at night.

Don’t get me wrong: it’s very helpful that Maven’s pom file structure has text fields for users to declare license name and url.  The mere presence of these fields encourages developers to make their licensing intentions clear. Some repositories don’t provide a license field at all.  But the mapping effort (read: human review) needed to evaluate this information makes ensuring license compliance more time consuming than it needs to be.

There are microsteps that Maven’s existing infrastructure can use to make this process easier, to help developers check and validate license information and treat missing license fields as a warning; that would be a great start.  Eventually I’d like to see all repositories and forges adopt the license identifiers of the Software Package Data Exchange (SPDX) as an easy way to standardize the representation of licenses. My hope is that Maven will continue to be a trendsetter by implementing SPDX solutions, because although Shakespeare posits “A rose by any other name would smell as sweet,” sorting through unstandardized license information stinks.

It was an event like none the cyber world has ever seen, and one that has been supported by the open source community, seeking to protect the internet’s foundation of openness and the innovation it fosters. The awareness and objection raised by the online protests has already caused many in congress to withdraw their initial support and the Whitehouse to produce a statement saying they will not support the legislation as it stands today (but will seek to pass “narrower legislation” around foreign copyright infringement). Therefore, we’ll start this Weekly Wrap Up with a few stories on the SOPA/PIPA protests:

• “SOPA/PIPA: How to stop fear” on ITWorld, was Brian Proffitt’s take on how the open source community can help stop this legislation.
• Ruth Suehle live blogged on opensource.com during the Internet Blackout, posting images of the sites that joined the SOPA protest: “January 18 captured: A SOPA blackout gallery”
• On The Washington Post, Brad Plumer’s article gave “Five reasons the Internet’s still protesting SOPA and PIPA.”
• Simon Phipps explains “Why SOPA and PIPA are bad for open source” on ComputerWorldUk.

Now onto the open source-focused highlights from the week:

• A poll question on opensource.com by Colin Dodd asks the introspective question: “How has open source changed your life?”
• Forbes shared the news that Intel’s open source project, Tizen, will be merging with Samsung’s mobile OS, Bada, in Elizabeth Woyke’s article, “Samsung Merging Its Bada OS With Intel-Backed Tizen Project.”
• Michael Crider wrote about the new SE Android, the National Security Agency’s security-enhanced version of Android,  in his article, “NSA releases ultra-secure open source Android derivative,” on Android Community.
• “NASA looks to lower open source licensing barriers” was an article by Molly Bernhart Walker on Fierce Government IT discussing how the NASA open government team is exploring different licenses to encourage more participation.
• Adrian Bridgwater wrote about the Raven robotic surgical system in his ComputerWeekly blog, “Scalpel? Check. Swabs? Check. Open source robotic surgeon? Pardon?”

Before ending my Weekly Wrap Up,  I’d like to give a shout-out to all the 2011 Black Duck Software Open Source Rookies of the Year: Bootstrap, BrowserID, Canvas, Cloud Foundry, Moai, Mooege, OpenShift, Orion, rstat.us, Salt and honorable mentions: Apache Rave, OpenStack Horizon and Rudder! Congratulations! (And if you’re a Twitter addict like me, check out #OSRookies!)

Here at Black Duck, our business operates at this balance point, at least where free and open source software (FOSS) is concerned – and we think the FOSS community and ecosystem represent a compelling model for the US Congress to study regarding how to strike this balance.  Developers around the world today are able to enhance their innovation by expanding their use of FOSS, and FOSS licensing and communities help ensure that FOSS content creators’ IP rights are respected. The model is all about enabling the use of content (open source code or otherwise) while simultaneously respecting the content creators’ IP rights, and it works well.

Open source projects aggregate contributions of code from (online) collaborators, then make that code available for free to the broader global development community.  But while the code is free, FOSS comes with a license and associated obligations.  The authors of this IP make their content available subject these obligations, which vary depending on the wishes of the authors.  Some use GPL-style licenses which ensure that subsequent derivative works will remain free and build upon each works’ innovations; others use Apache- or BSD style licenses that allow for derivative works that only require proper attribution.  In fact there are over 2000 different FOSS license variants…some going as far as requiring users creating derivative works to buy the author a beer when in the same locale…

Regardless of the license chosen, all users of the code are required to comply with the obligations associated with the license and copyright.  This simple approach has fueled a wave of collaborative innovation over the past several years that is truly unprecedented.  And when users don’t comply, the FOSS community and legal ecosystem get engaged to prompt compliance.  The system is very efficient, and most users see that the model works and strive to be compliant.

It is from this perspective that I view the SOPA/PIPA debate, and from this perspective that I strongly support a reasoned compromise – consciously seeking to strike the type of balance we see in the FOSS world.  If legislation is the mechanism, it should protect IP rights with great care to avoid censoring of content, inhibiting free speech or open collaboration, or the sharing of ideas online.  And the burden of proof should be high.

No question; this is a very difficult balance to achieve. I believe the open source community has done it, but unfortunately SOPA and PIPA in their current form cast far too wide a net – though this could be addressed.  With an informed and open dialog continuing on the topic, I am hopeful that a balanced compromise can be reached.