Observations from where technology meets business

open source

Is Bluenog’s Use of Open Source Sustainable?

There have been some recent interesting posts discussing Bluenog, a company which sells the Bluenog ICE (integrated collaborative environment). This is a product consisting of a portal framework, content management system, a report generator, a wiki, and a calendar all working within a secured environment using a granular permission model and is capable of integrating with enterprise single sign-on systems. The system looks to be very Enterprise 2.0-ish and may provide a useful intranet environment that brings together the breadth of information needed by knowledge workers. I had a chance to look at the product at the recent Enterprise 2.0 conference and talk with the company in an extended briefing. The product should get the attention of many IT managers.

While the Bluenog ICE product itself looks interesting, it is the business model the company uses to develop it that is causing a controversy and, in my opinion, raises some flags. Bluenog advertises itself as an open source company (or, rather, that is what most people walk away thinking when they have seen or read about the company). To be precise, here is what Bluenog says about their use of open source:

Bluenog ICE leverages several open source CMS, open source collaboration, open source portal and open source BI projects. These projects provide the building blocks for Bluenog ICE and allow us to provide tightly integrated solutions at a fraction of the cost of traditional alternatives.

The web page linked above lists a total of 19 open source projects as being used within the Bluenog product so, clearly, Bluenog is a consumer open source software. However, although the distinction may be subtle, the way Bluenog uses open source is different than what most enterprise IT managers may be expecting.

First, let’s be clear, Bluenog sells a proprietary product. Bluenog does not make the resulting source code of their commercial product available via an open source license. Paying customers get a copy of the source code but this offers none of the benefits, such as transparency and choice, that enterprises can gain from leveraging open source. What can you do with a copy of the source code? Open source becomes powerful when it is out in a community, gaining new features, getting security flaws fixed, etc.

Second, the only company that has benefited from Bluenog’s approach to open source is Bluenog itself, not its customers. But the sustainability of that benefit is questionable. Let me explain.

A number of the open source products used, which provide core ICE features, require significant changes to work in the Bluenog framework and these changes are not contributed to any sort of open source community. In essence, major parts of Bluenog are built from forks of open source products that are folded into their proprietary framework. Any enhancements or security patches from the originating open source community would have to be manually integrated into Bluenog because they are now separate products. For example, Bluenog is built with a version of the Hippo CMS that is one major version behind the main project.

So the question enterprises should be asking is this: Is Bluenog’s development model sustainable? Arguably, other companies have used open source this way. For example, IBM’s Lotus Symphony is based off an old version of Open Office. However, Bluenog is different for two reasons. First, Bluenog isn’t IBM. They are a startup and have limited resources. Second, they are creating a whole new integrated product based off of the amalgamation of several open source products, which sounds like a big integration challenge. IBM is re-basing the next release of Lotus Symphony on Open Office 3. Can Bluenog say the same about Hippo CMS? Do they care about future versions of Hippo CMS or are they content with keeping the older code, essentially turning these pieces into their own proprietary code?

If I were an enterprise IT manager considering Bluenog I wouldn’t let their use of open source sway me at all and evaluate them as a proprietary software vendor. I would also start asking questions about how they plan on sustaining the development of the product. Bluenog’s approach to using open source may have helped initially to get the first product out the door faster. However, the enterprise software market is a marathon not a sprint.

This is a repost of a blog originally posted on the Collaboration and Content Strategies Blog

Border Disputes in Enterprise Use of Open Source 3C

This is the fourth in a series of blog posts intended to help IT managers understand open source licensing and its implications. In this post I cover the risk of inadvertently licensing proprietary software as open source by mixing it with a GPL-licensed product.

Recall that my research focuses on the use of communication, collaboration, and content management (3C) solutions within enterprises. As it turns out, a large number of the leading open source 3C products are licensed under the GPL. So care must be taken if organizations choose to integrate these products with enterprise systems. The concern has to do with the GPL’s Copyleft provision, which states that a system must be licensed under the GPL if any GPL-licensed source code was used to create it and it was distributed. A previous blog post discussed hereditary and permissive open source licenses in more detail.

But let’s say this up-front, if your plans do not include modifying the source code of (or integrating with) a GPL-licensed product, or if you have no intention to distribute any software which involves GPL-licensed software (either linked or integrated with another system) then you should have nothing to worry about.

The issue I want to highlight here is where organizations are considering integrating a GPL-licensed product with an enterprise system. In some cases it is fairly straightforward to determine if a piece of software falls under the GPL. For example, if a developer links their source code with GPL-licensed source code then the resulting program is considered a derived work and would have to be licensed under the GPL, if it were distributed.

In her book “The Open Source Alternative: Understanding Risks and Leveraging Opportunities” Heather Meeker does a good job describing the “border dispute” of the Copyleft provision in the GPL. The problem is the GPL itself is not always clear as to what defines a program that is considered derived from GPL software. Meeker is very good at setting the scope of the issues and then exploring a number of scenarios regarding the applicability of Copyleft.

However, while Meeker’s background and analysis is interesting I don’t intend to explore the legal issues brought on by the GPL in cases such as loadable kernel modules in Linux or proprietary operating systems running within a Xen host. What I want to briefly touch on here are the issues surrounding the use of GPL-licensed software within enterprise environments, most notably those which may have to integrate with corporate systems.

So let’s explore these issues by going through two scenarios:

  1. Configuring Drupal to use an enterprise’s directory system. For example, an enterprise uses Microsoft Active Directory as a central source of usernames and passwords. Should we be concerned with integrating Active Directory with a Drupal installation via an LDAP interface using the LDAP integration module?
  2. Surfacing data originating from an enterprise system within a sidebar on a blog running WordPress. For example, the latest sales numbers are displayed on a blog written by a marketing director, via a plugin which pulls data from their proprietary sales tracking system.

At first it may not be obvious that either of these scenarios would qualify as a derived work and be subjected to Copyleft. In both cases the GPL-licensed products involved (Drupal or WordPress) would probably not run on the same computers as the proprietary systems with which they are communicating.

To get some guidance we can refer to the Free Software Foundation. As Meeker says in her book: “The Free Software Foundation (FSF) is in some ways the de facto enforcer of the GNU General Public License (GPL).” To help clarify these types of questions about the GPL, the FSF has a frequently asked question list on their website. The answer to the question “I'd like to incorporate GPL-covered software in my proprietary system. Can I do this?” provides some illumination as to how the GPL applies to the above scenarios. It says in part:

“However, in many cases you can distribute the GPL-covered software alongside your proprietary system. To do this validly, you must make sure that the free and non-free programs communicate at arms length, that they are not combined in a way that would make them effectively a single program.”

In other words, it matters a great deal how a GPL-licensed program integrates with a proprietary system, regardless of whether they are on the same system (and, we should also note, given the pervasive connectivity of the Internet, it doesn’t matter if the two systems are on the same network of even in the same company). If they operate as a single program then the FSF considers them a single program now subject to Copyleft.

So, the key is to be able to demonstrate that the two systems involved can still be considered separate. In the first scenario (Drupal using Active Directory) communication between the two systems is done via a well-known protocol (LDAP). All of the software used in the Drupal system can operate as a separate entity by connecting to any LDAP-compatible directory, not just this particular Active Directory. The two systems are clearly separate programs.

The second scenario is less clear. In her book Meeker suggests “to focus on the spirit of the GPL rather than its letter” and goes on to say the degree in which the proprietary code can be considered a “black box” will help clarify whether there is sufficient “arms length” (as the FSF describes it above) between the two.

If the proprietary sales tracking system was custom-written by company employees and the company wrote a custom extension to serve the data along with a custom WordPress plugin to pull the data and display it within the blog, then this sounds like two systems performing as a single program and subject to Copyleft, if either of the two were distributed.

On the other extreme, let’s say the company purchased a widely available sales tracking system, which provides sales data in RSS feed, and an RSS feed is fetched by a WordPress RSS plugin (which can be used with any RSS feed) that simply displays the feed items on the blog. This certainly seems to qualify as a “black box” and the two systems can be considered separate.

In closing, while is makes sense for enterprises to use GPL-licensed software (after all, a large number of the leading open source 3C products are GPL-licensed) care must be taken when integrating them with proprietary systems.

This is a repost of a blog originally posted on the Collaboration and Content Strategies Blog

The Roles Open Source Can Play in an Enterprise Vendor's Business

This is the third in a series of blog posts intended to help IT managers understand open source licensing and its implications. In this post I cover the roles an open source product can play in an enterprise vendor’s business (which are enabled by open source licenses) and what this means for the enterprise itself.

A previous post discussed the four key levers of open source licensing that can support a vendor’s business model:

  1. Hereditary versus permissive licensing (and the impact of Copyleft)
  2. Source code ownership rights
  3. Limitations around attribution
  4. What defines “distribution”

These levers are important to enabling the roles a vendor intends a software product to play in support of their business objectives, which are listed below. I’ll go through each of these in detail:

  • Commoditizing a Function
  • Increasing Accessibility to Code, But Retaining Ownership
  • Sustaining a Community
  • Delivering Services
  • Providing Support

Commoditizing a Function: This role is enabled by permissive open source licenses. For example, the Apache web server has commoditized basic web serving. Large companies like IBM have been the biggest contributors to these types of projects, often supplying the most developers and even contributing code that becomes the basis of new projects.

Nearly all open source products benefit from these products since they provide the foundation for other opportunities (e.g., LAMP-based solutions). IBM benefits by incorporating these in commercial product offerings, enabling contributions to come from a wider audience of developers (thereby sharing some cost), providing a forum to explore new technologies and standards (reducing risk and increasing interoperability), and reducing the chance of competing technologies from becoming standards (for example, the Apache web server has remained the most popular web server despite efforts from companies like Microsoft).

Increasing Accessibility to Code, But Retaining Ownership: This role is enabled by dual licensing of software. In particular, companies have licensed software they own with both a proprietary license and a hereditary open source license, such as the GPL. The classic example of this is MySQL. In the content management market, Alfresco is a good example.

The key to enabling this dual licensing approach is having ownership rights to the source code. For example, take a look at the Sun Contributor Agreement. The author of a contribution that makes it into the core product must give ownership rights to Sun.

In this role the GPL discourages competitors from incorporating MySQL source code into a proprietary product (since distributing the resulting product would require it to be licensed under the GPL) while also increasing visibility enabling others to interoperate with it. Nearly every Linux distribution comes packaged with the GPL version of MySQL, making it an easy choice for many developers to use. I’m sure Alfresco would love to have the same type of relationship with Linux at some point.

Sustaining a Community: For all of the complaints made against the GPL (mostly by commercial software vendors) it is hard to dispute the success of a number of communities supporting GPL-licensed products. For example, the  Drupal community has over 350,000 members and the Wordpress community has produced over 4,200 plugins. These are extremely active communities and are examples of what many established commercial vendors have been striving to build for years.

None of the main commercial entities involved in these products (Acquia for Drupal and Automattic for Wordpress) control the source code, nor license it separately. The GPL seems to level the playing field, enabling community members to compete on aspects other than proprietary software offerings. Rather, community members use the source code as a basis for competing in downstream markets such as custom website development, various types of services, and support. The result is a robust open source product that incorporates cutting-edge innovations at a pace commercial software vendors have difficulty matching.

Delivering Services: One of the ways Acquia and Automattic leverage their open source products is to provide services and support. For example, basic hosted Wordpress.com blogs are free. But, Automattic also provides premium blogging services as well as software support for enterprises. Acquia also provides support and later this year will offer site hosting and a premium site-search service (based on Solr, an Apache-licensed product, and provided via a Drupal module). Of course, many online service providers use open source software. The most recognizable being Google and Yahoo.

Providing Support: Although community leaders (such as Acquia, Alfresco, and Automattic) offer paid support services for their open source products, there are also companies that provide support for a broader selection. These include OpenLogic and SpringSource. For example, OpenLogic provides support for MediaWiki (the software which runs Wikipedia) as well as hundreds of other open source products including development tools.

Most enterprises will need some type of commercial support for open source products, unless they intend to maintain a staff with sufficient skills to do it themselves. So which type of support should you use, a contract with a community leader or a support-only vendor? Each situation can be different but, in most cases, I would first consider going with the community leader (since this contributes to the long-term viability of the product), unless the use of the product is limited and the risk of problems low. Either way, I think there is room in the market for both types of open source vendors and their positioning will be sorted out over time.

Clearly, open source products need viable community leaders and these companies will likely provide the best support. However, enterprises can only be expected to maintain so many vendor relationships and there are literally hundreds of opportunities for enterprises to use open source (many, of which, do not have a commercial entities behind them) so the open source support vendors should have plenty of business to go after.

What does this all mean to enterprises wanting to use open source solutions? When considering a particular open source product,first understand the role it plays in the plans of vendors supporting it.

  • Products with strong communities behind them will tend to be more innovative, likely have enterprise support options, and be around for some time.
  • Those products without strong communities need to be assessed as if they were a commercial product being sold by the vendor providing support.
  • If they have neither a strong community nor a viable commercial vendor behind them, either reconsider your options or proceed with caution and look for signs that the community will continue growing.

The key is understanding the long-term viability of an open source product, whether it is backed by a vendor or a community.

In my next post I will discuss some of the risks involved with open source licensing, thoughts on mitigating these risks, and open questions that still remain.

This is a repost of a blog originally posted on the Collaboration and Content Strategies Blog

Key Levers of Open Source Licenses

This is the second in a series of blog posts intended to help IT managers understand open source licensing and its implications. In this post I cover the basics of open source licensing while also highlighting aspects that can enable vendor business models and influence how an enterprise approaches using open source products.

The definition of an open source license is generally considered to be the responsibility of the Open Source Initiative (OSI), a non-profit corporation formed in 1998 to promote the development and use of open source software. The OSI definition of an open source license is called the Open Source Definition (OSD) and is made up of 10 requirements that must be met before a license can be considered open source. OSI maintains a list of approved software licenses that have gone through their license approval process. Software creators can use the OSI Certification Mark logo and notification text if their software is licensed with one of the OSI approved licenses.

OSI presently lists 72 approved open source licenses. However, only a few of them are in wide use. For example, Freshmeat (a site that tracks open source software) says that over 60% of open source projects use the GNU General Public License (GPL). To make open source licenses easier to understand it is best to break these down into two broad categories: hereditary licenses and permissive licenses.

The most controversial, and most recognizable, hereditary open source license is the GPL. The terms of the GPL most relevant to enterprises using open source products are:

  • The source code must be made freely available.
  • Once software is licensed as GPL its licensing terms cannot be changed (the only exception being an owner, who retains all rights to the original source code).
  • Any modifications to the GPL-licensed source code, or any software incorporating GPL software, must also be licensed under the GPL and may also be required to be made freely available. This is also known as the “Copyleft” provision. However, this provision is only triggered when the software is distributed.

In the diagram below, source code licensed under the GPL is mixed with “Your Source Code,” which could be as simple as small changes to the GPL-licensed source code or as complex as software intended to be kept proprietary (either custom developed or purchased). The GPL’s “Copyleft” provision requires the resulting software to also be licensed under the GPL, if it has been distributed. Resulting software not distributed is not required to be licensed under the GPL.

 Hereditary License Example

For many businesses, which sell commercially licensed software, the GPL is viewed as “viral” and a threat to their business model. Open source products licensed under a permissive license, such as the Apache License, are generally acceptable to commercial software vendors and not seen as a threat. The diagram below illustrates why:

Permissive License Example 

The key points from the above diagrams are:

  • Enterprises need to be careful when integrating with products with open source hereditary licenses. However, I should also note that care should be taken for integrating with any licensed software.
  • The act of distributing the resultant software (“Something New”) triggers the Copyleft provision of the GPL. Unless the software is distributed then the provision is not invoked. In an enterprise context, distribution of source code generally means giving copies of it to someone outside of the enterprise. However, there are other hereditary open source licenses that define “distribution” much more broadly and includes the act of using the software over a network (for example, a web application being used over the Internet) and may not involve the transfer of source code at all.

Other levers that are involved but are not obvious from the above diagrams:

  • A source code owner (the original author or somebody who has obtained ownership rights) can license the software any way they like. For example, they can release one version under the GPL and another under a commercial license.
  • A few open source licenses have other restrictions requiring some form of attribution. This can be simply attributing ownership in the source code or retaining the use of the owner’s name or logo in screens seen by someone using the product.

To sum it up, the key levers of open source licensing, which can support a vendor’s business model, and which enterprises should be aware of are:

  1. Hereditary versus permissive licensing (and the impact of Copyleft)
  2. Source code ownership rights
  3. Limitations around attribution
  4. What defines “distribution”

My next post will discuss the types of open source businesses these levers enable and what this means for enterprises wanting to use open source solutions.

This is a repost of a blog originally posted on the Collaboration and Content Strategies Blog

Open Source Software Licensing for IT Managers

A recent article from Bruce Perens, a leading open source advocate, entitled “How Many Open Source Licenses Do You Need?” reminded me of how confusing open source licensing can be for IT managers who aren’t plugged into the open source world. Although the article is published on a website intended to be read by IT managers it was clearly written for companies producing open source software. After writing down some of my own ideas for explaining open source licenses to IT managers I decided to turn these into a series of posts.

But first, some background. My research at Burton Group focuses on the use of communication, collaboration, and content management (3C) solutions within large enterprises. What this means is I don’t come to this topic from only a developer’s or a system or network administrator’s perspective. The 3C solutions we cover are usually considered infrastructure components that can be leveraged by applications. We tend to have a foot in both the infrastructure and application side of IT.

What we see driving IT management interest in open source is:

  1. Saving money through lower licensing costs.
  2. A desire to tap into innovative solutions, particularly those driven by active open source communities.
  3. Using open source software to learn about emerging technologies (for example, much of what is called Web 2.0 was first built with open source)

The concerns IT managers have with open source software are:

  • How well does the software work?
  • Will it integrate with my existing infrastructure and applications?
  • How well is it supported?
  • Is it secure?
  • Are there any risks with using open source software?

In my client dialogues about open source a topic that often drives discussion is licensing. One of the keys to effectively applying open source solutions is to understand a vendor’s business model and the role the software plays in their market plans. An open source license supports that role and business model. Therefore, understanding open source licenses is important because:

  • They are an indication of the business model used by an open source company (and commercial software and services companies using open source software).
  • Each of these business models has a different set of factors to pay attention to in terms of how they use open source and what they must do to succeed.
  • They also influence how an enterprise might use an open source product. For example, maybe you are using an open source library in one of your applications or perhaps you are using a full product (like an open source blog) but are thinking of integrating it with an application. Each of these scenarios comes with a different set of opportunities and risk.

My next post will be an introduction to specific open source licenses, the levers they can bring to bear on a software market, and what they can mean to an enterprise using open source software.

This is a repost of a blog originally posted on the Collaboration and Content Strategies Blog

Google Chrome

Initial reaction to Google removing the “beta” label from Chrome is surprise. The New York Times observed that Gmail still “sports the ‘beta’ label.” And later: “But Google said it would also have a newer version of Chrome that will always be in beta".”

One likely reason for dropping the “beta” label so quickly is Chrome being an open source project, which traditionally have a production (often called “stable”) release built with code that has been strongly vetted and a development version based on the latest check-in code (which is, unsurprisingly, often called “unstable”). Debian, the open source Linux distribution, has 5 releases of their software: stable, testing, unstable, experimental, and oldstable.

I wouldn’t be surprised to see Chrome dropping the “beta” label entirely.

SaaS and Open Source? You are asking the wrong question!

Most everyone knows that Yahoo, Google, and many Web 2.0 companies built their SaaS offerings using open source software. Yes, they use open source to save licensing costs. Yes, they used open source to develop their services quickly using Linux, Python, PHP and a host of other high-quality components. They also benefit from the improvements these open source components see year after year.

But, does this mean that SaaS represents the best use of open source?  No, not from a customer perspective. In my opinion, many of the discussions I've been reading lately focus on the wrong question. It's not if SaaS and open source are complementary (of course they are) but how do they complement each other and, more importantly, what does this mean for the customer.

Open source is free and SaaS is often free (as in free email and free social networks). But the primary benefit of open source isn't cost savings, it's choice (to a CIO this means "mitigating risk"). Users of open source can be assured that their data or content sitting in an application will continue to be usable, even if a commercial vendor drops a service or stops selling software.

SaaS (regardless if it was built using open source software or not) that delivers a proprietary service is still a proprietary solution and that removes customer choice. And, yes, I am equating Google Sites to Microsoft SharePoint in this regard. As a customer I may not care how a solution is built but I absolutely care about choice (and as a CIO I really care about mitigating risk).

Open source software that you install on your own equipment is interesting. It gives me choice but at the cost running it myself. But, open source software provided as SaaS is downright compelling because I get the advantages of both SaaS and open source. Someone else takes care of it and I retain choice.

Syndicate content