Subscribe by Email

Your email:

Connect With Us!

Current Articles | RSS Feed RSS Feed

What is an Open Source Software Governance Policy?


In an effort to save time and money, and leverage valuable code bases, most companies use open source software. Many companies, large and small, have formal open source policies. Even more companies have informal open source policies, e.g., a company may not want to use any software under a General Public License, and that information is spread via word of mouth. I often hear people mention that they have been ordered to write an open source governance policy, and they are not sure where to start. This blog covers what an open source policy is, and the various topics to address when developing an open source policy.

The Best-In-Class Open Source Policy


In the time that I have spent with OpenLogic, I have worked with companies across many industries, and with companies ranging from a handful of developers to thousands of developers. One thing they have in common is that they typically have some type of open source policy, some far more developed than others.

Recent College Graduates and the Open Source Licensing Conundrum


The growing acceptance of open source software in the workplace prompts a strong push for open source training for recent college graduates. I cannot speak for all recent college graduates, and I cannot speak for every university, but I can speak from my experiences and the experiences of others I have talked with on this subject.

Open Source Training: An Interview with Matt Atwater


Large corporations are becoming increasingly interested in the value of deep open source knowledge. While some corporate leadership may inherently understand the intricacies of open source training inside and out, I would argue that for most companies interested in training, the characteristics and processes are anything but well known. To shed light on such topics, I sat down with Matt Atwater, the Director of Support and Professional Services at OpenLogic, to ask him a few questions regarding open source training.

Open Source Software Management: A Review of Wazi Articles


Cacti Makes Device Monitoring Simple

Every organization must monitor its infrastructure’s uptime and performance. While the popular Nagios application is a good general-purpose monitoring program that you can extend with plugins to handle just about any task, you may do even better by employing Cacti as a graphical front end to RRDTool‘s data logging and graphing functionality. Cacti was developed specifically to monitor and collect performance information, while Nagios is more oriented toward state changes, such as noting whether a daemon is up or down.

View the full article here


Build Cross-Platform GUI Applications With wxWidgets

If you develop GUI applications, you probably know what you want from a toolkit or framework. Chances are that the ability to build apps that run on multiple platforms is high on the list, along with ease of use and deployment. Those are among the strong points of wxWidgets, an open source library designed to make it easy to create cross-platform GUI applications.

View the full article here


ViewVC Helps CVS and SVN Go GUI

Almost everyone who works with version control systems (VCS) feels the need, sooner or later, for a graphical interface, because sometimes a GUI makes your life easier. ViewVC is a full-featured browser interface that’s portable as can be, given the design choice (web-based) and the programming language (Python). It was originally created for CVS users and later extended to support Subversion as well.

View the full article here

Using Nagios to Monitor Your Clusters' Health

The Nagios network monitoring and alerting framework lets you easily keep track of a wide variety of hosts and services, and generate reports and alerts targeted to specific teams or individuals. By using plugins, you can further enhance Nagios’s functionality, giving it capabilities not available in the core product. One such plugin lets you monitor the health of your cluster instead of that of individual hosts.

View the full article here

Must Know WordPress SEO Tricks

Many new WordPress users are under the impression that WordPress already takes care of search engine optimization (SEO) upon installation. However, the out-of-the-box WordPress installation that most people rely on doesn’t offer the best SEO results possible. If you want your WordPress sites to rank as highly as possible on search engine results pages, adopt the following techniques to enhance your sites’ placement in results from Google and other search engines.

View the full article here

Subscribe to The Enterprise Open Source Blog by Email

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

Open Source Software Support: How Well Are You Minding the Gap?


More and more enterprises are using open source software projects such as Linux, Apache, Tomcat, MySQL, and ActiveMQ as a significant and growing part of their IT portfolio.  Some enterprises work with one or more open source vendors to get commercial grade, open source support for the OSS they use.

However, there are also a substantial number of open source users that view support as an after thought and find themselves scrambling for a solution at the 23rd (or 25th) hour.   Just last week we began our quarterly Open Source Benchmark Report survey focusing on the support aspect of open source software usage.

One question we included in the survey was, “What is the biggest OSS challenge facing you in 2012?”  The answers covered a wide range, but there was one consistent theme:  when it comes to support, time is of the essence and time needs to be accounted for when obtaining support.

In our Predictions and Trends for Open Source in the Enterprise report that we concluded at the end of 2011 and published earlier this year, there were a few stats that jumped out to me relative to this discussion:

    • 60.1% of enterprises surveyed rely on internal expertise for open source support

    • 26.9% of enterprises surveyed consider themselves having deep expertise on OSS projects

    • 40.5% of enterprises surveyed think it is too hard to find support for open source software

If 60.1% of respondents said that they rely on internal expertise, but only 26.9% of respondents say they consider themselves to have a deep internal expertise on OSS projects then:

    • How much time are the 26.9% spending to increase their internal expertise?

    • How much time are the 60.1% spending to make sure that their internal expertise stays up to par as versions and packages are continuously updated?

    • How much time are the 40.5% spending to simply find a solution?

Here at OpenLogic we see time and time again the urgency and need for an open source support solution, often as the first point of contact.

When you use open source software as part of your IT portfolio, you are counting on an output that depends heavily on the amount of time it takes your staff to achieve the desired results.  It then becomes the inherent task to mitigate the risks that can increase the time it takes to produce the outputs needed.

Purchasing individual support contracts can be expensive, and choosing an open source support provider from an aggregated business model might hit your P&L and tap into your dollars and cents budget, but wouldn’t it be more advantageous to budget for an expense that allowed you to produce the necessary results that you've signed up for?  Rather than jeopardizing the output because you didn’t budget the right amount of time into your equation?

Using open source software can provide advantages such as cost savings and flexibility, but if you aren’t budgeting in a line item support cost OR a time cost, then you aren’t looking at the complete cost of using open source software.

If you have ever been on the London tube, you would have heard the warning, “mind the gap,” every time before boarding the train.  The instructions here are to watch your step as you go between the platform and the carriage.  You are reminded to do something so simple that would normally be taken for granted. Be that as it may, no matter how many times you’ve ridden the tube, it is important to remember to “mind the gap.”  If you forget to "mind the gap" there is a good chance that you will trip and stumble or worse, and no one wants to see that happen.

Are you minding the internal open source support gaps or just ignoring them until you stumble?

Subscribe to The Enterprise Open Source Blog via email

View Aaron Mandelbaum's profile

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


The SPDX License List: The Gateway Drug to Full SPDX Adoption?


The SPDX License List is just one part of a larger effort to make reporting open source software licensing information more efficient and thus ease license compliance.  As an active member of the SPDX legal work group, it began as a simple matter of raising my hand that I took on the task of 'keeper of the list.'  Or so it seemed.

When I began working at OpenLogic, my first task was to read all the most commonly used open source licenses, analyze the license requirements, and help create the framework which would become the OLEX Open Source License Compliance module to our scanner.  This necessarily brought up some tangential questions.  Do we have this license already in our database and, if so, is it truly the same license?  At what point does it become a different license?  What is considered part of the license text and what isn't?  What should the license be called?  How should the formatting look when the license is displayed on the page? Later, my role would evolve to include using our product to perform open source audit services for our customers.  There is nothing like drinking your own Kool-Aid to encourage improvements at the macro and microscopic level.

Now, let's just be clear; I am not a developer.  I managed to teach myself basic html and css to round out my interest in graphic design and support a side business building static websites for the small businesses of friends and relatives in a previous life.  This means I have just enough knowledge of website coding to make me dangerous. Combined with a strong opinion about the way things should look and a meticulous eye for detail (some people refer to this as perfectionism, but one look at my garage would disqualify me from that classification) means I have spent more time than I wish to admit thinking about things like whether to use bullets or numbering as the list-style for the clauses of the BSD license and making up "rules" to ensure that all the red-headed step-children that are open source licenses are treated equally and consistently in order to make our tool reliable, predictable, and practical.  So, it is really quite appropriate that I fell into the role of the keeper of the SPDX License List.

What is the SPDX License List?

First you may be wondering, what is SPDX?  The Software Package Data Exchange® (SPDX™) specification is a standard format for communicating the components, licenses, and copyrights associated with a software package.  The idea began as a way to reduce redundant work across the software supply chain.  By creating a common format to report data about software licenses and copyrights, license compliance is then also facilitated.  Software, systems, and tool vendors; foundations; open source services companies; and systems integrators work side by side to develop the specification as a collaborative effort under the SPDX work group, which is hosted by the Linux Foundation.  The first version of the specification was released in August of last year, with version 2.0 in the works as you read this.

In the early days of the specification development process, it became apparent that a way to refer to common open source licenses by a short reference would be very helpful and reduce the amount of information contained in an SPDX file.  Thus, the SPDX License List was born.  The license list contains the full name of the license; a standard identifier; a url to the official version of the license and to the Open Source Initiative (OSI) website if the license is OSI approved; the license text itself; and any official license header as suggested in the license.  Then there is the need for some kind of matching guidelines to make sure that when one SPDX user identifies a license as "Foo,” it is indeed the same license as what someone else identifies as “Foo” and the same license as what is listed on the SPDX License List.

Of course this is not the first list of its kind or endeavour to reach such goals.  Increasing feedback and participation in the SPDX legal work group indicates that many others either have their own such similar effort or would appreciate being able to adopt a list already created.  Because the thing is, creating such a list and its attendant guidelines is not nearly as easy as it sounds.  Yet, wouldn't it be nice if we got to a point that when someone says "BSD 3-clause," we all - the collective and sometimes cacophonous world of open source software - would know exactly what that meant?

What's in a name?

That which we call a license by any other name may smell as sweet, but how does one decide what to call it to begin with?  Let's take the BSD License for example.  If a file states, "This file is licensed under the BSD License," do you really know which one?  There are three different BSD licenses: the original 4-clause license that included the advertising clause; the "revised" 3-clause license, which is probably most used today; and the simplified 2-clause version.  Then there is the fact that the University of California rescinded the problematic advertising clause, thus effectively turning the 4-clause license into the 3-clause version for any UC Berkeley copyrighted code.  FreeBSD and NetBSD both use a 2-clause version, but with additional text included at the end or beginning, respectively.  And while there may be some who say, "who cares?" the difference can be material, and moreover, where accuracy is the goal, such differences cannot be ignored.  These are some of the questions that need to be confronted and decisions that need be made.

What better group to work on such a task than a collaborative collection of players from across the open source software space?  In the same way that Linus Torvalds' harnessed the collective intelligence of many developers to create Linux, so too can we for creating a way of referring to licenses that addresses all the detailed considerations.  The SPDX License List, due to its inherent nature of filling the needs of many, could just prove to be the gateway drug to overall adoption of the full SPDX specification.

If you have yet to, get involved!  Join one of the SPDX work groups and mailing lists (general, technical, business, or legal) here:

Let me take this opportunity to give a huge thanks to the tireless participants of the SPDX legal work group (you know who you are!) - while there is much more work to do, we have come a long way in a short time.  Cheers!

Subscribe to The Enterprise Open Source Blog via email

View Jilayne Lovejoy's profile

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

Open Source Management: Dealing With New OSS Releases


The first quarter of this year has be a busy time in open source management. JBoss has had two releases in the 7.1 series, the Apache web server has had two releases in the 2.4 series and Ruby on Rails has had two releases in the 3.2 series just to name a few. This may sound like a flurry of new releases, but is really par for the course. In the open source world releases happen all the time. Most open source projects take the release early, release often motto to heart. And for good reason too, it results in better software.

Release schedules, like everything else in software engineering, are always a trade off. The downside of rapid release cycles is that users have to deal with those releases. Dealing with any particular release is usually pretty easy, but dealing with all the releases of all your dependencies can be quite difficult. Our applications, for example, usually depend on a hundred or more individual open source components. I suspect that most projects have similar levels of open source dependency. Just keeping track of all the releases across a dependency set that large is difficult.

Just ignoring releases of the open source you depend on is a bad idea. (Though it is a pretty common approach to this issue.) Open source projects don't release just for the fun of it. When they release a new version there are usually very good reasons. Those reasons almost always include security, performance and productivity.

Security improvements

New releases of any software component are likely to include some security improvements. Open source components are no exception. Open source software is probably more secure, on the whole, than proprietary software, but that does not mean it's perfect. Most open source projects are quick to fix any security issues as soon as they are discovered. Dissemination of such fixes happen by releasing a new version of the component. If you are not using the latest release of a component, the version you are using probably has at least one known vulnerability.

Performance improvements

Open source software tends to get faster over time. Odds are that the most recent release of any open source component is faster than the one that came before it. If you are not using the newest version of a component you are missing out on that performance improvement. As we all know, speed is a feature. A very valuable feature.

Productivity improvements

Functionality improvements are easily the most common changes made to any software. Much more common than security fixes or performance improvements. This should not be surprising, developers write open source software because they want better tools. Your development teams could be writing better software and getting it done more quickly by using all the improvements being continually added to the open source you use. But only if you are staying up-to-date.

How to stay up-to-date

Now we get down to the nitty-gritty. I really wish I could tell you how to easily deal with new OSS releases, but I can't. Even here at OpenLogic staying up-to-date is a continual struggle. I do have a little bit of advice, though.

A stitch in time saves nine

Upgrade to each new release as soon as possible. It is always easier to upgrade one step at a time. If you don't stay on top of upgrading and miss a bunch of releases the upgrade process is bound to be painful. If you ever do fall behind, and you probably will, do the upgrades as soon as you notice, the problem will only get worse if you wait.


Find a way to get notified when new releases are shipped. Subscribe to the mailing list and create an email filter to flag release notices. Sign up for a release notification service like OpenUpdate. If the project has a blog, subscribe to it. Anything to increase the likelihood that you, or your team, will notice when a release is published.

Commit to staying up-to-date

If you are a manager make it clear to your development team(s) that you understand the importance of being up-to-date and make time in the schedule for those chores. If you are a developer educate your manager about the importance of keeping the open source you depend on up-to-date. Building a culture that values security, performance and productivity is the only way to ensure that your organization continually benefits from up-to-date open source dependencies.

Ask for advice

I said earlier that I did not have any silver bullets, but maybe you do? How does your organization deal with staying up-to-date and managing their open source? Have you tried something that works really well? Or things that failed miserably? If so I'd love to hear about it.

For the latest package versions, check out OLEX (OpenLogic Exchange), where we provide on-demand access to more than 330,000 open source packages, and over 500 of these open source packages have been certified by OpenLogic for use in the enterprise. The OpenLogic Certified Library is comprised of these certified open source packages. Every open source package included in the Certified Library is supported, indemnified, and maintained by OpenLogic.

Subscribe to The Enterprise Open Source Blog via email

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

Open Source Management: Take the Open Source Maturity Quiz


Open source management is increasingly becoming an important component of today's IT discussions, as companies are using open source software more widely in their IT infrastructure; So much so that Gartner expects open source to make up 30% of enterprise IT portfolios in 2012.

Selecting Your Open Source Support Vendors (And What Their Business Model Means to You)


The vast majority of enterprises use open source software as a significant and growing part of their IT portfolio.  And most enterprises work with one or more open source vendors to get commercial grade open source support for the open source software they use. In order to select the right open source support vendor, it’s important to understand their business model and how that model impacts you.

The 4 most common types of open source software support models and the implications for enterprises:

    1. Pure Open Source: Sell Support and Services

           Examples: Drupal, OpenLogic

           Lock-in: None

Vendors with this type of business model provide support and services for software that is offered under an open source license.  The vendors may focus on a single open source project (e.g. Drupal) or provide support services for many open source projects (e.g. OpenLogic).  Because the open source software is freely available under an open source license, you are not locked in to the vendor.  There is nothing that prevents you from deciding later that you want to self-support or choose another vendor, you don’t need to worry about switching out the open source software.  This approach gives you the most flexibility.

    1. Certified Distribution Model: Sell Subscriptions, Tools and Support

            Examples: Red Hat, CloudEra

            Lock-in: Some

Vendors with this type of business model take an open source project and do additional testing, certification or bundling.  Red Hat Enterprise Linux is the most well-known version of this model.  In the process of “certifiying” a release, the vendor may select or create patches and fixes.  This “certified version” is then branded (e.g. RHEL, Cloudera Distribution of Hadoop) and you are charged for some combination of subscription to this branded, certified release, support and add-on tools or services (e.g. Red Hat Network, CloudEra Manager). In this case, there is some degree of lock-in.  First, if you don’t renew your subscription, you may be required to remove branding, switch off the certified version or stop using the add on tools or services.  While this may be possible, it may require some effort on your part or require you to give up some functionality.  As a result, there is some degree of lock-in associated with these models.

    1. Open Core Model: Sell Subscriptions for a Proprietary Version

           Examples: EnterpriseDB, Alfresco

           Lock-in: Same as proprietary software

Vendors with this type of business model take an open source project and create a separate version with additional functionality that is provided under a proprietary license.  Often these vendors will only offer support if you use the proprietary version.  When you purchase this version, you have the same degree of lock-in that you would have with a proprietary vendor.  If you no longer purchase the subscription, you can’t get support.  If you want to revert to the open source version of the code, you will need to rip out the proprietary version and make sure you don’t need any of the proprietary features.

    1. Dual License Model: Sell Open Source Software Under a Proprietary License

           Examples: MySQL

           Lock-in: Can cause lock-in depending on license requirements

Vendors with this type of business model take an open source project and offer it under two licenses – an open source license (often GPL) and a commercial license.  If you don’t want to use the project under the open source license (for example when you want to redistribute), then you purchase a subscription for the commercial license.   You can still go back to the open source version later, but you will then be required to use the open source license.  If that license is not compatible with your use case, it may be difficult to change to the open source version.  One of the other challenges of this model is that a vendor must own all of the copyrights in the project in order to be able to offer it under a non-open license.  This means that either employees of the vendor must write all of the code, or any outside contributors must sign a contributor agreement that enables the company to put the code under a commercial license.  This has the practical effect of limiting the number of outside contributions to the code, and as a result, you lose the benefit of community development that is often associated with open source projects.

In order to make the best selection, it is important to make sure you understand the business model of any vendor you are considering.  You can then use the business model information as well as the requirements of your particular use case to narrow down your options and make the appropriate choice.

Subscribe to The Enterprise Open Source Blog via email

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

All Posts

Enterprise OSS Blog Policy

If you read a post on The Enterprise OSS Blog, please leave a comment. Let us know what you think, even if it's just a few words. Comments do not require approval, but they are moderated.OpenLogic reserves the right to remove any comments it deems inappropriate.


Contact Us

Browse by Tag