1) Protect your data (part 1)

Cloud security is the number one issue with using public clouds. Many organizations are building applications that include personal information, confidential information, or intellectual property that needs to be protected. Help all the paranoids sleep better by building in security features from the start, even going to the point of overkill if necessary. Database encryption is a common way to protect data at rest, but also consider treating your cloud instances as single use servers.  Remove all the keys and passwords from disk once your application is running and disable all unnecessary connections including ssh. Adopt a devops strategy that allows quick launches and centralized logging and management. If a server does stop responding or gets rebooted for some reason, just throw it away and get a new one.  Taking a few extreme security measures will help you get more opportunities to utilize the true power of the cloud.

2)  Protect your data (part 2)

Cloud technology does pose some new challenges. At this point, server failure rates can vary and the faster options include storage that does not persist across restarts or failures. Data loss is a real risk unless a high availability or replication strategy is adopted. There are also plenty of cloud based data solutions popping up, including Cloudant, Amazon RDS, and Rackspace MySQL Cloud, that can put the HA burden on someone else’s shoulders. Bottom line, losing data will kill a project fast.  Keep it safe.

3) Architect for failure (and recovery)

As I mentioned before, there can be more variables affecting the reliability of cloud servers. Not only can servers fail, but the underlying hardware can have issues, and whole cloud regions can be affected by outages. This is compounded by the fact that you are no longer in direct control of when the hardware may be restarted. Several times recently we have received notices that hardware our servers were running on were going to be rebooted. If you are using some of the cloud security measures mentioned above that make your application not able to restart, these outages may require some intervention to keep your cloud application running as smooth as possible.

Creating an architecture for these realities of cloud solutions doesn’t have to be overwhelming. The important part is to consider the effects of failures on your users and decide what your tolerance for failure is. That tolerance can be a guide to the technologies to put in place to handle the failure scenarios. Perhaps you are fine with periodically restarting the application or going to a hot spare, or maybe your application must be up at all times and you need to consider deploying across regions or even across clouds to ensure the greatest resiliency possible.

4) Work in the cloud

Just as there can be a big difference between a developer’s machine and a traditional production environment, there are differences with cloud environments as well. It’s important to get a feel for the specifics of how cloud servers will affect your application by doing significant work and testing in the same cloud environments you expect to deploy to. By having your developers working with the cloud on a daily basis, you’ll start to develop an understanding of where the bottlenecks will occur and how they will affect your application.

5) Keep an eye on costs

One way to really put a damper on your cloud party is to surprise your boss with an unexpected cloud bill for much more than you anticipated.  With automation, functional testing, and continuous integration always validating your code, it can be very difficult to track the number of instances used (of course you are doing at least some testing against production-like environments, right?) Cents per hour may seem very cheap, but it’s easy to implement a testing strategy that can use tens or hundreds of servers per run, depending on the project (note that cloud instance billing rounds up: 1 minute = 1 hour). Without some form of visualization of the costs, nickels and dimes can add up unexpectedly. Fortunately, awareness can go a long way to alleviate some of the hidden costs. Updating the testing strategies to reuse servers when possible or considering utilizing an internal development cloud for most test runs can prevent cloud costs from escalating out of control.

Of course, these are not the only things that will make you successful in the cloud, but these are some of the things we experienced as we started building the CloudSwing platform. What other key issues have you experienced when building your cloud based enterprise applications?

Subscribe to The Enterprise Open Source Blog via email

Follow @openlogic
Follow @cloudswing
Follow @esweid01

This work is licensed under a Creative Commons Attribution 3.0 Unported License .

Understanding and interpreting open source licenses is not always an easy task. Open source licenses are essentially unilateral; if you use the software, you agree to the terms of the license.  There is no protracted negotiation process in which you ruminate and refine terms, as is often the case for custom-developed software. Open source licenses may not track on U.S. Copyright Act statutory language or use accepted license wording. Alternative language or definitions may be used instead of legal terms of art or expanded to encompass a global perspective.  All of this can cause ambiguity when it comes time to interpret the license for compliance.

Making it even more difficult, the more troublesome compliance terms have yet to be litigated, most notably the derivative works question in regards to the GNU General Public License.  However, that does not mean there is no guidance; organizations that have authored or maintain a license often provide a frequently-asked-questions resource to proselytize their interpretation.  Whether a court would agree with their interpretation may be debatable, but so long as there is no judicial opinion regarding specific compliance terms it is wise to pay attention to these resources.   For the more common and established licenses, seasoned open source attorneys can also rely on community-accepted practice for compliance.

Interpretation Made Easy

It should go without saying that open source licenses are no different than any other intellectual property license; that is, there are conditions or requirements that need be met and restrictions that need to be minded. A helpful starting point is to break down the requirements into an if/then statement.  For example, if you distribute the code – the triggering event or use of the code – then you must provide a copy of the license – the requirement or obligation.

How you use the code – the triggering event – will determine what conditions or requirements need be met.  By identifying your usage model for the open source software in question, you can then start to filter which license requirements are needed for compliance.  Keep in mind that some triggering events may demand further analysis.  Does the license define “distribution” based on copyright case law?  Does the definition of distribution or conveyance include access to the software via a web-based platform?  Is it possible that how you use the use of the software will change over time, thus changing what requirements or obligations are triggered?

Once you know how you are using the open source software and thus, what license requirements you must comply with, then you must ask “how”?  How must you provide the copy of the license?  Sometimes the devil is in the details; for example, is it enough to retain the license in the header of some of the source files or do you need to have some kind of license notice in every file?  Where does the license go if you are distributing the work in binary form?  Some licenses may have specific guidance on how a condition must be met and some are vague, requiring you to decide what seems reasonable.

Once you have sorted out what you need to do to comply with the open source licenses, then you need to consider if there are any conflicts between the licenses or their terms. Sometimes there can be conflicting obligations and two licenses end up incompatible. Typically this occurs when there is a derivative work involved. For example, if you have created a derivative work by combining two projects, each under a different license that requires you to release a derivative work under the original license, it would be impossible to comply with both licenses. Depending on the open source license, you may also have a licensing conflict with your end-user license agreement (EULA); for example, if an open source license disallows imposing further restrictions on the open source software and your EULA includes restrictions on the number of users or prohibits reverse engineering, you need to include a “carve-out” that the open source license applies as to the open source software.

At the end of the day, when it comes to complying with open source licenses, there is often no definitive answer. Because there is no established jurisdiction interpreting, for example, whether dynamic linking creates a derivative work, you may simply have to make a determination based upon your interpretation of the license. How you make that call may hinge on the risk profile of your company or how your product is engineered and therefore involve discussions among your business and development teams.

What open source license clause would you most like to see a court opinion on?

Do you have any tips you can share regarding how you approach open source license interpretation?

Subscribe to The Enterprise Open Source Blog via email

Follow @openlogic
Follow @cloudswing
Follow @jilaynelovejoy
View Jilayne Lovejoy’s profile

This work is licensed under a Creative Commons Attribution 3.0 Unported License
.

Cloud technology and cloud based solutions are having an impact on all stages of the current technology adoption life cycle, and although the book was published in 1991, the principles and characteristics defined appear to be solution agnostic and still resonate 20 years later with recent references in articles like, 5 More Books for the Aspiring Funnelholic, Crossing the Content Chasm, and Will Google+ Cross the Chasm?.

So what exactly are the stages of the technology adoption life cycle, and where do you stand when it comes to cloud solutions?

The 5 Stages of the Technology Adoption Life Cycle described in Crossing the Chasm:

The Innovators: Technology Enthusiasts

These are the people who can “see the light” when no one else can.  They are the people like Bill Gates and Steve Jobs, who understand a market demand for a product that hardly exists.  The innovators are few and far between, but are the first ones to take something out of the box, throw away the instructions, and see what it does.

Early Adopters: The Visionaries

Mr. Moore hit the nail on the head when he said, “Visionaries are that rare breed of people who have the insight to match an emerging technology to a strategic opportunity, the temperament to translate that insight into a high-visibility, high-risk project, and the charisma to get the rest of the organization to buy into that project.”

Early Majority: The Pragmatists

This group is known to be that which makes up the majority of the market volume when it comes to new technology adoption.  Pragmatists rely on data and benchmarks to make their decisions, not the new shiny toy coming out of the box.  The pragmatist characteristically relies on trusted advisors, and the influence of the early adopters to help make their decisions.  Pragmatists are just that, they are pragmatic.  They care about the quality of the product, the goings on in the company who provides the product or solution in question.

Late Majority:  The Conservatives

Mr. Moore interestingly describes this group’s characteristics to be similar to the great football coaches of Mike Ditka, Chuck Knox, George Allen, and John Madden.  To give this analogy some perspective, Bill Walsh, the legendary coach of the San Francisco 49ers, was referred to as the visionary and Sam Wyche of the Cincinatti Bengals was the technology enthusiast.

Late Adopters & Laggards:  The Skeptics

These are the anti-sponsors for the adoption of a new technology.  “What skeptics are struggling to point out is that new systems, for the most part, don’t deliver on the promises that were made at the time of purchase.”  The influence a skeptic might carry with their words could possibly end any hope that you have of adopting a new technology into your organization.

Although the book is primarily written from a marketing point of view, the real value proposition, and the reason it is still receiving references 20 years later, is that no matter which hat you wear in your organization, whether you provide a solution or might be looking for a solution, the principles and detailed depiction of the life cycle, can help identify the best way for you to reach your technology adoption goal.

Where are you in the technology adoption life cycle when it comes to cloud technology?

We’d like your input!

We are going to be creating a few LinkedIn groups to cover the topics that we discuss here on the blog, but in a more forum type of environment, Q&A setting, to run in conjunction with our posts.  We will also be hosting upcoming Hangouts on Google+.  Be sure to add us to your Google+ circles at the top of this page on the right hand side to receive updates on “whens” and “whats” of these upcoming Hangouts.

If you have suggestions for the The LinkedIn group’s topics for discussion, or topics you’d like answers around in an upcoming Hangout, please submit them in the comments section below!

Subscribe to The Enterprise Open Source Blog via email

Follow @openlogic

Follow @AaronMandelbaum

View Aaron Mandelbaum’s profile

This work is licensed under a Creative Commons Attribution 3.0 Unported License

.

Let’s identify the set of steps you would take to handle a support issue for proprietary software.
First, you would have a system administrator consult the software documentation to learn more about the issue at hand to find a solution to the problem. If the administrator cannot resolve the issue with the use of documentation, then do one of the following:

• If you have business-level or production-level support from the software vender, open a support ticket with them at this time.
• If one is available, post your issue on the online community for the product (forums, mailing lists, wikis, etc.).
• Seek out another existing employee who might know how to solve the issue.
• Contract a third-party expert to help fix this issue.
• If the issue is actually a bug with the software itself, issue a bug report to the vender.

Believe it or not, the general steps to handling an issue with open source software line up almost identical to the steps above. At times it’s actually easier to deal with a bug fix for open source than it is for proprietary software. In open source, bugs are typically submitted to an online issue tracking system, which is public to any user. For simple everyday support issues there really isn’t much difference between open source support and proprietary software support.

What about when complex errors occur? For example, you may not be able to find anyone else from the online community that has experienced the issue. And nothing is popping up when typing the error messages into Google. In this case, the issue could be related to your data and specific use of the software. This would explain why no other users have experienced the same issue.

So what are you to do when there is no answer online and you’re having an issue with the software? And now here lies one of the great benefits of open source: you have access to crack open the black box and see what is inside.

A skilled software developer has access to the actual source code that makes up the open source project – unlike if the issue was occurring within proprietary software. The developer will be able to debug the issue by crawling through the code rather than waiting for assistance from outsourced tech support or vender support. Sometimes the issue can be majorly complex, and crawling through the source code is often the only way to truly diagnose the problem. When/if the issue is identified as a bug in the software, a skilled developer or contracted third-party expert can rebuild the software with a self-made fix for this issue – no vender interaction required.

Proprietary software support issues can hit the “black box” – that is, getting a fix for a problem is quite rare and you’ll usually need to find a workaround for the support issue instead. Typically, the bigger the vender, the harder it is to obtain a fix. The beauty of open source support is whether you’re fixing the issue by hiring a third-party open source software expert (such as OpenLogic) or by utilizing an existing employee, you can always take full control of your support needs.

Subscribe to The Enterprise Open Source Blog via email

Follow @openlogic
Follow @cloudswing

This work is licensed under a Creative Commons Attribution 3.0 Unported License

Cue the controversial Stop Online Piracy Act and the Protect IP Act, fondly known as SOPA and PIPA. Both bills had intentions to combat copyright infringement on foreign sites by preventing US-based sites from linking to, advertising on, or funding sites that provide pirated content. Sounds great in theory, but the problem is in the bills’ broad language. As it stood the bill would allow for the Justice Department to target websites who were unknowingly or unintentionally hosting links to pirated content. Those sites – including big user-oriented sites like Facebook – could essentially have the plug pulled on them unless they censored the user-generated content to be certain they weren’t hosting anything deemed illegal (this is where the uproar about censorship comes from). You can check out a nice breakdown of SOPA here.

SOPA and PIPA were very recently put on hold after much protesting and petitioning from the likes of Wikipedia, Google, the Free Software Foundation, and angry Internet surfers everywhere – but you can bet this isn’t the last we’ve heard of bills such as these. So what would similar bills mean to open source software if they were realized? Here’s what the potential impact could look like:

Impact on the Virtual Community

Open source communities are an essential part of open source software. In many cases, online forums are some of the only ways to get documentation, technical support or notice of software updates (that is, unless you use a convenient third-party resource like OpenLogic). SOPA, again based on its non-specific language, could have required a site owner to strictly monitor or possibly censor user comments in social platforms, including forums, to avoid risking a user posting a link to a site that promotes or facilitates piracy. These sites, worst-case-scenario, would be liable for the content uploaded to it – if those sites didn’t take control over their user-generated content, you may not be able to find them anymore. Alex Howard at O’Reilly Radar does a great job of explaining this – read more here.

If similar legislation came to fruition, it would likely impact many if not most OSS community websites. For example, let’s say a developer visited a forum and decided to add his two cents and provide a link to extra information. Maybe that link went to a site that provides pirated content or access to pirated content (even if the developer wasn’t aware of this). Theoretically, if the owner of the forum didn’t take action to delete that comment then the site owner could end up in deep water.

The foundation of open source is built upon the freedom of the Internet, and free communication (without liability risk) is one of the most important aspects of the open source community – without it open source wouldn’t function as it was originally intended.

Impact on Open Source Software Usage and Development

Open source projects found (or possibly even perceived) to be aiding online piracy could encounter problems if bills like SOPA and PIPA were to pass. For example, earlier last year the Department of Homeland Security demanded Firefox take down its option to add on MAFIAAfire – an open source project designed to redirect users to alternate domains when they try to access domains (some of which were piracy-aiding) that have been seized by the ICE. Instead of just giving in, Mozilla sent a letter requesting justification of the project’s illegality. If legislation like SOPA and PIPA had been enacted at that point, Mozilla may not have had much of a choice in the matter – they could have had to either remove MAFIAAfire from their repository of add-ons or face harsher consequences, at worst, being shut down. The same could go of any other open source project deemed to be aiding or promoting online piracy – the project could be shut down.

The Open Source Initiative (OSI) articulated its disapproval in an open letter issued in opposition of SOPA and PIPA, stating:

“…the Stop Online Piracy Act (SOPA), PIPA requires the use of internet censorship tools, undermines the global nature of the internet, and threatens free speech online. PIPA introduces a deeply concerning degree of legal uncertainty into the internet economy, particularly for users and businesses internationally…”

The OSI went on to list specific issues relating to freedom of speech in the letter, but also expressed its concern that SOPA could create a need for excessive compliance measures, as any web property unknowingly using even a shred of open source that could be interpreted as ‘piracy-friendly,’ it could be shut down. This would ultimately hinder the use of open source, chilling development and possibly risking financial support for the community.

Of course, this post covers what would be “worst-case-scenario” – with SOPA and PIPA stalled, we hopefully won’t have to face harsh legislation like this as a reality. Currently there’s already a bill in line to take its place (check out the OPEN Act, which appears to better protect the freedom of the Internet and is backed by Google, Facebook, Twitter and others). The important thing to remember is that future of open source software is reliant on open Internet and freedom to communicate openly. Not only are these basic human rights, but also these two rights in particular are the ideals the open source community is built upon in the first place. It’s important we continue to give input and preserve the fundamentals that open source stands on so it can continue to grow.

Subscribe to The Enterprise Open Source Blog via email

Follow @openlogic
Follow @cloudswing

This work is licensed under a Creative Commons Attribution 3.0 Unported License

Binaries vs. Source Code

When do you have to supply binaries in your scanning effort? Open source scanning tools like OSS Deep Discovery can scan and find snippet-level matches within source files. If you are using open source libraries you may think that simply providing source code is sufficient, but here are a few rules to consider when deciding whether to include binaries.

1) If you only have compiled versions of some libraries you may have no option — you have to include the binaries. But often, compiled versions of open source libraries can be easily obfuscated and may not be recognized by the scanner. In cases like this, if you know of binary-only libraries in your code, it is in your best interests to try to find and download the original source. You will have a much better chance of getting accurate results, and the scanner may even find some additional open source components you didn’t know were used in the original open source library.

2) If you have the source code to all binaries you provide in your final application, then there is little reason to include binaries. They may only complicate the results and make reconciling the scan more difficult.

3) There are some circumstances you may want to include binaries when you also have all the source available. On Linux systems, for example, running “ldd” can provide good information on how your code is linked to standard open source libraries in the operating system. This linking can provide additional information about license obligations that are triggered on the combination or linking of programs.

Build vs. Runtime Components

While it is much easier to just provide everything when running a scan, you may want to think about run vs. build-time components. Here are a few examples of where this can be important.

1) Many times build components are licensed under the GNU General Public License (GPL).  Scans that include build-time components (that do not get distributed with your application) may turn up matches that are hard to explain to your legal department or compliance group. For example, if you are careful not to use GPL code for policy reasons on a commercial application, but a scanner shows several matches to GPL-licensed code, you then need to help your less technical folks understand why these components are not distributed, why it’s not a compliance issue, or why GPL is in your code when you said it wasn’t.

2) There are times that simply including everything is a good thing. It helps confirm what open source components get distributed with your application so you make sure you don’t accidentally ship something that triggers some unintended license obligations.

Additional Components

A common mistake I see people make when preparing to scan their projects for open source is to accidentally leave components that include open source out of the scan. Here are a few considerations to keep in mind when preparing to scan your code.

1) Does your build process download and use components that are not in your source code repository? If additional code is downloaded at build time, make sure that those additional components are included when you run the scan. This is particularly important if you use tools like Maven.

2) Does you product rely on additional components that are not part of the build environment you are scanning? This may seem like an obvious question, but sometime we get so close to our work we miss the obvious. When preparing files to scan double check that you have included all components you ship.

Performing an open source scan and audit of your code is an important component of the modern software build process. Keeping these relatively easy set of considerations in mind can help make the process more efficient and easier to manage.

Subscribe to The Enterprise Open Source Blog via email

Follow @openlogic
Follow @cloudswing

This work is licensed under a Creative Commons Attribution 3.0 Unported License
.

I want it yesterday!

Developers want to get stuff done. The thought of engaging in a procurement process is enough to sap the energy from almost any idea. We will just go back to reading hacker news instead of slogging our way through all that red tape.

Open source tools, on the other hand, are always close at hand. It takes almost no time from conception to actually writing code if you are using open source tools. Even better you can wait until you have something interesting to demo before you ask for forgiveness. With commercial offerings you almost always have to ask for permission, and we all know that is a sure fire way to get your pet project shut down.

Choice is important

Open source software suffers from the paradox of choice. There are often so many choices that it is a little paralyzing. On the other hand, the only thing worse than having too many choices is having too few. Faceless procurement processes practically guarantee that you will end up using a suboptimal tool. (This is not just a problem for developers; it happens any time someone other than the intended users chooses the tool.) Nobody wants to be stuck on a death march, and using a suboptional tool set is one way to make sure a project has problems.

The blow of so many open source choices is softened by the freedom to download several and give them a try in realistic situations. Deciding what tool to use based on check lists of features is very unsatisfying. Trying out different tools for a small project is a much better approach. This approach is devastatingly easy with open source. Just download the package and give it a shot. Commercial offerings, on the other hand, usually make this somewhat more difficult. You are likely not able to get a download and license without talking to a sales droid. Even if you are able to make it through the “lead generation” gauntlet, commercial products usually have steeper learning and setup curves because of their closed nature.

It’s the information, stupid

This might be most important reason of all. The amount of information that is available for most open source projects is just mind boggling. No matter what problem you are having or question you are wondering about, someone has probably written a blog or mailing list post about it. The solution to even really esoteric problems are usually just a Google search away.

But wait, there’s more… In the rare situations that Google is unable to answer your questions there are the mailing lists. The average open source mailing list is good enough to make you want to have its love child. The people subscribed know the product in and out, and they are always ready to talk about their baby. Give them an interesting problem to chew on and they will bend over backwards to find a solution.

Escape hatches are comforting

A final (for my list) benefit of open source to developers is the comfort of having access to the source code — even if they never use it. Often you don’t really want to have to read or modify the code of your tools, but having that option is very comforting. It means that if you run into some horrible bug, you can fix it. If you need to use the tool in some unanticipated way, you can modify it to work the way you need. If you want to use some poorly documented feature, you can always figure out how it works straight from the horses mouth. It is a lot harder to use tools that are opaque, and any tool that you don’t have the source code for is a black box just waiting to soak up your valuable time.

What is you favorite benefit to using open source?

Subscribe to The Enterprise Open Source Blog via email

Follow @openlogic
Follow @cloudswing

This work is licensed under a Creative Commons Attribution 3.0 Unported License
.

Overall Growth Ranking

1. HBase
2. Node.js
3. nginx
4. Hadoop
5. Rails
6. MongoDB
7. Tomcat
8. MySQL
9. Apache
10. Spring
11. Grails      PostgreSQL(tie)
12. Struts
13. JBoss
14. GlassFish
15. CouchDB

Category Trends

Within each category, OpenLogic also analyzed which projects were trending up (all or most of the metrics were up), trending level (some metrics were up and some were down), or trending down (all or most of the metrics were down). Below are the trends by category.

Application Server/Web Server Category

• Trending Up: Node.js and nginx
• Trending Level: Tomcat and Apache HTTP Server
• Trending Down: JBoss and GlassFish

Analysis

Node.js is helping to drive a resurgence of JavaScript. It acts as an application server for JavaScript apps, thereby increasing scalability and performance. Nginx is a high concurrency, low memory usage web server and reverse proxy that is gaining strong adoption across the internet.

Tomcat and Apache HTTP server continue to be the 800-pound gorillas in their respective categories, but with a broad adoption base, their growth is more limited than some newer technologies.

The surprise in this category is the downward trend of JBoss. Although JBoss continues to be a popular option, we see more enterprises that are shifting off proprietary application servers chossing lightweight options like Tomcat.

Frameworks Category

• Trending Up: Rails
• Trending Level: Spring, Grails, Struts
• Trending down: (none)

Analysis

It’s not a big surprise to see that Rails, an application framework for the Ruby language, is generating a lot of interest and growth. Rails is well suited to the highly scalable web applications that are becoming more prevalent in the enterprise. In addition, Rails attracts developers with its emphasis on convention over configuration, which can greatly accelerate development time.

Spring, Struts, and Grails all are trending level, showing that they continue to attract a steady level of interest in this category.

Databases and Big Data Category

• Trending Up: HBase, Hadoop, MongoDB
• Trending Level: MySQL, PostgreSQL
• Trending Down: CouchDB

Analysis

In this category many of the Big Data and No SQL projects came out on top of the overall growth rankings. Some of the growth these projects are enjoying can be attributed to the current hype around the entier Big Data category, but these technologies are also very quickly making their way onto the radar of enterprises.  These technologies are enabling brand new applications that were formerly much more difficult with traditional database and data analysis techniques. As a result, they are often chosen for new projects where they are no established database vendors to displace.

The one exception to the dominance of Big Data is the downward trend of CouchDB. CouchDB arrived on the scene a few years ago as one of the hot new NoSQL vendors. However, one of the main companies backing CouchDB is stepping away from their open source commitment and the project is a fit for a more limited set of use cases than some of the other NoSQL alternatives.  It’s possible that this project may regain its footing in 2012.

MySQL and PostgreSQL both trended level. Despite the Oracle acquisition of MySQL, it still ranked ahead of PostgreSQL in our growth rankings.

Methodology

To develop the Open Source Trending Report, OpenLogic analyzed popular as well as up-and-coming open source projects that are used as core infrastructure in enterprise applications in order to evaluate growth in enterprise interest and adoption. The three categories analyzed were web and application servers; application frameworks; and databases and big data. For each open source project, OpenLogic analyzed eight metrics that include public data, as well as aggregated data from OpenLogic’s tools and customer base of over 250 enterprises worldwide. The OpenLogic report used the following eight metrics:

• Public data: Google search volume.
• OpenLogic Exchange (OLEX) and OSS Deep Discovery Scanner: The report evaluated OLEX search volume, views of packages, downloads, requests within corporations to use the project and matches against the project during scans. OLEX is a Software-as-a-Service solution for the comprehensive governance and provisioning of open source software used by many Fortune 100 companies.
• OpenLogic CloudSwing and Open Source Support Contracts: OpenLogic aggregated data on customers purchasing support contracts from OpenLogic for each project, as well as projects that users deployed through OpenLogic CloudSwing, an open PaaS platform.

Subscribe to The Enterprise Open Source Blog by Email

Follow @openlogic
Follow @KimAtOpenLogic
This work is licensed under a Creative Commons Attribution 3.0 Unported License .

The way I interpret this isolated piece of data is that either:

1. The vast majority of the people using open source software are so confidant that their open source compliance is spot on, that they don’t need to search for compliance solutions;
2. People haven’t looked at addressing the issue as fast as the interest and adoption of open source software has grown; or
3. People just don’t know what they don’t know and could very well be sitting on top of a ticking time bomb with issues of compliance waiting to surface.

So if you have stumbled upon this article or you are one of the 73 people in the world this month that searched for “open source compliance,” the following five steps or questions will help get you going in the right direction:

1. Identify the open source software – “What open source software do I have?”

First you need a complete and transparent view as to WHAT open source software is being used in your code base, often referred to as an audit or a package review.  You can’t begin to comply with the licenses if you don’t even know what you have.  For smaller amounts of code, you may be able to get away with self-reporting and manually inspecting files, but most likely you’ll need to use some kind of scanning technology or purchase audit services from a third party for a thorough assessment.  To learn more about the audit options that are, you can review The In’s and Outs of Open Source Audits.

2. Identify the licenses – “What license is the open source software under?”

Often, this question is answered alongside the first question.  Sometimes the answer is apparent.  For example, if you are using a well-known open source package, the license information for that package may also be well established.  However, open source packages can embed other open source under other licenses within them.  Sometimes the license stated on a project website is not what you find within the actual code.  In any case, determining the package is not enough, some amount of research is often needed to determine or confirm the proper license.

3. Identify your obligations – “What do I need to do to comply with the open source licenses”

Obligations and requirements that licenses pose can vary depending on a few factors.  First, identify what requirements or obligations the license imposes; what conditions does the license place upon your use of the software?  You also want to pay attention to any restrictions or termination clauses.  Then you will need to consider how you are using the software.  Most license obligations are triggered by how you are using the software, for example, are you distributing the code?  Have you modified it.  Read The 4 Steps to Understanding an Open Source Audit to see each step explained in greater detail.  Once you have gone through this process, you can create a compliance checklist – a list of all the steps you need to take to ensure you have complied with the open source software licenses present in your codebase, based on how you are use case.

4. Implement Compliance – “How do I actually comply?”

Now that you have determined what you need to do to comply, it’s time to do the work.  Using your compliance checklist as your guide, take the steps needed.  This will most likely include making sure a copy of the various licenses are included, attribution notices are in place, source code is provided for any copyleft licenses, and so forth.  If you can’t comply, then you may need to look at alternative licensing or replacing the code.

To learn more about implementing compliance check out A Practical Approach to Open Source License Compliance

5. Implement the changes for long-term success – “How do I stay in Compliance?”

Now that you are in compliance, how do you stay there?  As the development process moves forward, your audit and compliance may become outdated quickly.  Without instituting an open source policy and governance or tracking process, all this work will need to be re-done again.  An open source policy will lay out your overall goals and guidelines as to the use of open source software in your enterprise.   A process will be needed to track, approve, and review new open source software coming into your codebase.  Schedule periodic audits and compliance updates at regular intervals.

Staying in compliance is like keeping your attic clean. You know that when you start this process after a long lay off, you are probably going to find things you don’t like and you may have to make some tough decisions.  However, the process wouldn’t be so daunting if you knew exactly what was in there and had a structure in place to allow only the right things in. The same holds true with adding things to your attic as it does with adding to your code base.  Once you’ve done the spring cleaning, you need to have a clear understanding as to what is allowed in, where to put it, and what isn’t.  And everyone needs to be on board.

Is there a 6th step to open source compliance that you can add?

Subscribe to The Enterprise Open Source Blog via email

Follow @openlogic
Follow @AaronMandelbaum
View Aaron Mandelbaum’s profile

This work is licensed under a Creative Commons Attribution 3.0 Unported License
.

As with any business process change, it can be difficult to find the time, inspiration, and support from others necessary to get started with creating or updating your company’s open source governance process. If you find yourself in this predicament, now is the perfect time to review the many ways an effective governance process can positively impact your organization. Here’s a list of five benefits to help motivate you and your team to get started.

1. Improved Employee Morale

Inconsistent, outdated, or (even worse) non-existent rules and processes are frustrating. If employees don’t know how, when, and where open source is allowed or even encouraged, there’s a good chance that someone will eventually make a mistake that gets him or her – and potentially the organization as a whole – into trouble. Conversely, when employees are aware of the boundaries of acceptable open source usage, know how to procure open source, and have defined processes for requesting approval for new packages, they don’t need to worry about causing problems by using the wrong open source license or package.

An effective open source governance process improves employee morale by enabling smart, appropriate open source usage while enforcing rules fairly and consistently. An effective governance process also enables employees to request approval for new open source packages or new uses of open source, thereby eliminating any inclination to go around the company’s open source policy.

2. Increased Open Source Usage

By defining boundaries and processes, you can actually increase open source usage in the organization. This in turn can bring forth other benefits such as lowering technology costs, accelerating innovation, and attracting and keeping top technical talent. After all, who doesn’t want to be part of an organization that uses the latest open source technologies and out-innovates its competition?

3. Improved Public Relations

Good intentions can go a long way, especially when it comes to public relations. An effective open source governance process can help your organization develop and maintain a positive relationship with the open source community. This might include project contributors and committers, advocacy groups such as the Software Freedom Law Center (SFLC) and Free Software Foundation (FSF), and even individual developers who may be potential customers or employees.

How exactly will your governance process create this goodwill? You’ll first have to communicate the fact that your company has an open source policy, encourages open source usage, and has processes in place to govern open source usage. This can be done with a page on your corporate website, a dedicated open source subdomain or site (for open source fulfillment, for example), and/or by encouraging employees to participate in and present at open source conferences. No matter how you do it, the bottom line is you’re likely to see positive results when the open source community knows you’re trying to do the right thing in terms of responsible open source usage and license compliance.

4. Improved Budget and Resource Planning

An effective open source governance process will help your organization better understand what open source software is in used as well as the nature if its usage. This can be an eye-opening experience for companies that didn’t previously track and govern open source usage. Organizations often learn that they’re using a lot more open source than they thought they were, and that many open source projects are deployed in production systems and critical customer-facing websites or applications.

Whether your governance process simply confirms what you thought you knew or opens your eyes to an entirely different picture, gaining accurate data will help you better plan budgets and allocate resources. You may find that that you need open source support for critical systems, or that you have redundant services contracts with different vendors that can be combined or eliminated. You may also realize that you need to put a greater focus on open source license compliance for packages used in distributed products, or that there are opportunities to replace commercial software with open source already used elsewhere in the organization. Regardless of the conclusions you draw, you’re likely to be better prepared for future planning with the data your open source governance process gives you.

5. Reduced Legal Risks and Less Chance of IP Infringement

The most obvious benefit of an effective open source governance process is perhaps also the most significant. By definition, an open source governance process will help your organization understand and control how, where, and when open source software and licenses are used – essentially operationalizing your open source policy. Assuming your policy is comprehensive and up-to-date (if not, check out my last entry, 3 Steps to Jumpstart Your Open Source Policy), a governance process that enforces it should help your organization prevent open source license violations, reduce potential legal risks, and avoid IP infringement.

What do you think is the greatest impact of an open source governance process? If you select other, please leave a comment and share your thoughts!

Follow @openlogic
Follow @gbellcolorado
Subscribe to The Enterprise Open Source Blog by Email

This work is licensed under a Creative Commons Attribution 3.0 Unported License
.