Beyond Using Open Source – Free Open Source Software License Insight Conferences Presentation

As mentioned in a previous note, I was in Seoul recently to give a talk about an organization’s governance of open source at the Free Open Source Software License Insight Conferences. A government group, the Korea Software Copyright Committee, put this event on. There were extremely nice and kind hosts, and the event itself was fun. The audience has many questions about open source licensing and governance. Here’s that presentation, and the paper/write-up that accompanies it:

Slides

Write-up

As mentioned back at the cloud computing and linux talk, I’ve been doing little write-ups of my talks recently. Also as a bonus, the conference organizers put the below into a paper and translated it into Korean – I’m not sure if that’s available online anywhere yet.

Abstract

IT is now a heterogeneous world composed of commercial, open source, and in-house software and systems. Organizations require cultural and operational changes to fully benefit from the success of OSS. Using open source software is only the first step. Beyond that there are questions of maintaining relationships with open source communities and becoming involved in the open source process. This talk focuses on a discussion of changes such as those and actionable advice for making them.

Why use Open Source?

Open source software has long been a known quantity in the technology industry and for those that use IT – virtually every business and organization in the world. Over the past few years, it has cemented itself into the fabric of the industry, it is like oxygen and water, something that is taken for granted and seems to be impossible to avoid. Still, there are many organizations who have not perfected their use and, more importantly, virtuous involvement, of open source. While the software is freely available, benefiting from it requires time and often money. Why move beyond “just using open source”? Here are some reasons:

• Low barriers to entry – traditionally, acquiring, evaluating, understanding, and then deploying closed source, on-premise software is difficult, requiring third party advice and, of course, license costs. While open source software is free, the real low barriers to are from the community that surrounds thriving open source projects.
• Public, individual driven community – a thriving open source project is about more than source code. It also includes helpful “community members” who are willing to assist new and experience users when it comes to evaluating and using software. With traditional software, users are typically dependent on paid relationships with software vendors and their partners; there are thriving closed source communities (such as Microsoft), but chances for thriving communities tend to be better in the open source world.
• Source – not to be overlooked, having access to the source code is valuable in several ways. First, though users may never actually compile or modify the code, some will be able to understand the software better by having the code. Next, in theory, the life of the software is better assured by the code being available instead of hidden or even in escrow. Third, if the project allows others to contribute code in the form of patches or features, the evolution of the project may advance faster than a single source – a vendor – could safely advance the project.
• Not just GPL – at first glance, “open source” and “GNU Public License” can seem like synonyms. Early on, many users of open source perceived GPL software as being dangerous to commercial business. While this has long been tamped down (the wide use of Linux, which is GPL’ed shows that there is no danger if applied correctly), there can still be confusion. Open source software can be covered by many different licenses than the GPL. Indeed, large foundations such as Eclipse and Apache have their own licenses. Understanding what a license means is key, but thankfully the overall community has spent much time understanding the consequences – both good and bad – of most any license out there.
• Architecture of participation – finally, the primary advantage of open source is the “many eyes” and many fingers benefit of a thriving community. Software is a magical, complex artifact of human invention, and it tends to go wrong when there are a small amount of people working and understanding it. Open source has long relied on what was once called “crowd sourcing” to drive quality and functionality. More germane for this talk, open source communities tend to be welcoming of involvement from the outside. It may limit the type of involvement, but communities are typically eager to have help. They want your input.

Using Open Source

With these benefits, and others, what are the ways an organization can use open source? As Linux proponents will tell you, the wide spread of Linux across devices and web services means that “everyone” touches an open source project daily, many times depending on how much they rely on the Internet. Narrowing scope down to an organization, there are broadly two ways to use open source software:

• In developing your own software – software vendors have long benefited from using open source to drive down their own costs. Non-software organizations should benefit from using open source in their custom built software as well.
• For production applications – more than just tools for developers, finished open source products are available for use in almost any application category: CRM, IT Management, email and messaging, and desktops.

Users of open source much avoid being naive and assuming that just because a product is open source, they will never have a reason to pay a vendor. Indeed, in each of these uses, there are increasingly commercial interests wrapped around otherwise free-to-use software. Many of these companies follow a “core” vs. “enterprise” business model, providing the foundation of their product as an open source project and selling additional “enterprise” functionality on-top of it in addition to support.

Guidelines for Using Open Source

Once you have started using open source, there are several things to keep in mind. Below, some of the more important considerations are highlighted:

• Assure low barriers to entry – much of the benefit of using open source software comes being easy to understand, evaluate, acquire, and use. If your organization wraps too much onerous process and “red tape” around using open source, those benefits will be nullified and value lost. When looking at how your organization uses and governs open source, keep the principal of low barriers to entry at the top of your mind.
• Establish policies – as with any software, open source software is intellectual property and it’s use is covered by a license. Thankfully, each of these licenses has a good chance of being widely understood, though it may be as dense as closed source licenses. Each time a user of open source in your organization has to slow down to consider the licensing concerns, they’re taking away from the low barriers to entry benefits for open source. By establishing use policies – what types of licenses your organization will accept – you can speed up the evaluation and use of open source. With out well established and easy to understand policies, you will have to kick-off a lengthy review workflow for each piece of open source software developers or users want to use.
• License considerations – your license policy should be simple and straight forward. Have you legal and other departments look at popular open source licenses with the mission to approve, or disapprove, the use of each one. Create a light-weight process for employees to register the use of open source code so you can keep track of it. All of this should be inexpensive. If you would like to spend more money, consider vendors like Black Duck, Protocode, or Palamida who help automate the process of discover what open source is in use and notifying you of policy violations.

Support

When using any piece of technology, an organization should consider your support options. Inevitably, an organization will need help, if only by means of a manual or documentation. Open source is no different. But there can be different methods and expectations when it comes to open source support, including the other kind of support: your organization helping the open source community. In the open world, RedMonk breaks support options into two halves, as the widely used quip puts it: you can trade time for money, or you can trade money for time.

Trading Time for Money

Thriving open source communities can be very helpful, for free when it comes to support. While some communities may seem rude, or even hostile, all technologies tend to enjoy people asking for help: it means they are interested in, if not grateful for their software. They may be abusive towards “newbie” questions, but learning the culture of asking for free help is easy enough. What are the sources to look at for open source support:

• Mailing Lists – most open source projects maintain active mailing lists, usually divided between developers of the project (don’t use this unless you know you should) and users of the project. Before asking a mailing list a question, it’s very polite to search through mailing lists for past answers to the question. If you do send a question to an email list, it’s typically best to explain in detail how to reproduce the problem. Keep in mind that other people are helping you for free, so you want to make their job as easy as possible.
• Bug Lists – if open source software you’re using seem to be behaving unexpectedly, find the bug database and search through it for a bug and, hopefully, work arounds.
• Forums – in addition to mailing lists, some projects have online forums dedicated to discussion of the project. There may be “official” and “unofficial” forums (as with mailing lists too, actually).
• IRC – another common online collaboration service is Internet Relay Chat, or IRC. These are chat rooms that users, developers, and other log into group by topics and themes. Most thriving open source project have an IRC channel dedicated to them where a properly asked help question may be answered very quickly.
• Google is your best friend – the most useful tool is simply learning how to use Google to search for past occurrences of problems you’re having. When a problem occurs, it’s very rare that someone else has not already encountered and written up a solution to it. Always spend time in Google narrowing down, or expanding, the keywords you use to search for other user’s write-ups of problems and solutions.

Trade Money for Time

Instead of your organization spending time on “self-service” support, many commercial options exist allowing you to save time, but spend money:

• Certified Stacks – a thriving open source project typically has a commercial company wrapped around it. Several years ago, this was a very popular high-tech investment, so many of these companies exist. These companies typically produce a certified stack, or version of their software that is certified to work with certain configurations, combinations, and in different environments.
• Projects Offering Support – these same companies, and a smattering of third-party companies, offer traditional SLA-driven support for open source projects. These companies typically offer the usual 3 levels of metallurgical support: Silver, Gold, and Platinum, differentiated by speed of response time, named contacts, and other traditional offerings.
• Individuals – there are several individuals who may be able to help you at as well. “Consultants,” you may call them. Typically, these people will be obvious when you dig into the open community around a project. Some formalize their offerings, while others are usually up for paid consulting jobs helping out.

Providing Support & Patches

More than just taking support from the open source community, vital to the architecture of participation around open source is giving back to the community. There are several ways your organization can support the open source world:

Bugs

• Fix bugs – bugs exist in all software. If you encounter a bug and are able to fix it, the open source world is typically very welcoming of your assistance. Each community typically has it’s own process for accepting outside contributions and fixes, often involving sharing or assigning the intellectual property (IP).
• Social capital to spend – as you provide more bug fixes and feature contributions, your organization builds up a positive reputation. Think of this reputation as an asset, “social capital,” that your organization can strategically use to get what it wants from the project and community, even influencing future directions and features. Ideally, your desires will be benevolent and helpful, of course.
• Keeps code alive and thriving – key to the long term value and your organization’s strategic success with software is to keep the code alive and evolving as needed. By getting involved in open source projects your organization depends on and cares about, you help fund the future success of your organization by supporting the software foundation. Most important, the more involved you are, the more control you can have over the software and, thus, your own destiny.

Forking?

With the source code available, an organization may make modification to to the code and keep them for their own, or split from the main project. This is know as “forking.” Forking code is an enticing option versus waiting for the overall community to incorporate changes. Once open source code is forked, however, you’re at high risk of loosing many of the benefits of using an open source project, namely the pooling of “eyeballs” around a single, shared code base. Here are guidelines when thinking about forking:

• Avoid forking at all costs – first, if you think you should fork, don’t. Only in rare instances will forking be helpful for your organization.
• First try to merge into mainline – if you have developed your own code, try to contribute it back to the open source project.
• Only fork for business value – in very rare cases, you may depend on the changes you’ve made to differentiate your business from competitors. Contributing this code to the community may damage your organizations’ ability to compete. As an example, think of the modifications to open source that Google must benefit from. Would they benefit from sharing those core differentiators?

Still, in most cases, do not fork the code.

Incentives for Changing Culture

Changes in an organizations IT often hinge on cultural changes rather than the (relatively) simple technological changes. Moving into the advanced stages of using open source – being involved in open source – is no different. Changing culture depends on incenting individuals, then teams, and then whole companies to change and embody the resulting new culture. Why might those organization stake-holders care enough to change culture?

• Exposure to new tech and people – people in organizations can often be, or even feel, isolated from the rest of the world. More than just making them feel bad, this is a risk for organization that depend on their employees to come to work with new ideas to solve problems and help drive revenues. Being involved in open source is one to combat conceptual isolation because the open source world is, almost by definition, done all in the public, in the open. There are typically people from multiple organizations, even cultures involved, giving participants a better chance to develop a “worldly” vision.
• Resume – for individuals, having open source experience in their work experience is very valuable. While an organization may not like to think about improving the hire-ablity of their employees (it implies these employees will leave, possibly for competitors), increasing the skills and reputation of employees can be a strong incentive to keep employees happy and to encourage them to be involved in open source.
• More control over project – involvement, “showing up” is the main currency in the open source world. The more an organization is involved in an open source project, the more control they may have over the quality and future direction of the project.
• Fight employee boredom – working day-to-day in a closed world can be boring for employees. While the same can be said of using open source, getting involved in the open source world does offer a high chance of making an employees work-life more interesting.
• Open source non-core, platform code – when it comes to software that does not differentiate a business, the incentives are high for companies to use open source software, if only for lower costs. As noted earlier, companies should carefully consider the openness of core software that allows them to beat their competition.
• Commodification – ideally, a company will spend money on commodities instead of more expensive, unique offers. Companies that get involved in open source are, more than likely, helping further cement the commodification of software which drives down costs.
• Control – as mentioned many times above, the more an organization – or individual – is involved in an open source project, the more control they will share over the project.

Conclusions – Control Your Own Destiny

For an organization, open source offers the chance to of not only lower costs, more open communities to draw from, and, in the best case, innovative software. Ultimately, moving beyond simply “using” open source into being involved with and supporting open source affords the organization a better chance to share control over the ongoing life of software it depends on. This translates into more overall control of an organization’s own destiny, which is clearly a highly desirable outcome for any strategic decision, such as becoming more involved in open source.