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



Follow @openlogic
Follow @cloudswing

Subscribe to The Enterprise Open Source Blog by Email

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

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 23^rd (or 25^th) 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

Follow @openlogic
Follow @cloudswing
Follow @AaronMandelbaum

View Aaron Mandelbaum's profile

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

.

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:  http://spdx.org/wiki/spdx

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

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

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

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.

Notifcations

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

Follow @openlogic
Follow @cloudswing

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

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.

2. 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.

3. 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.

4. 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

Follow @openlogic
Follow @cloudswing

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

So let’s say your company Acme Inc. hosts several software applications that are based on open source technologies. Your development team seems to be pretty skilled at writing code, and for the most part utilize these open source libraries effectively.

For example, you have a Jboss Application Server hosting your web application (an open source application server), use Maven to manage your dependencies, JMeter to test your software, and so on. All sorts of open source software elements are scattered about.

At this point (whether you realize it or not) - you utilize open source technology heavily and rely on it for your company’s success.

But then during the testing of a production release, you encounter a software bug in your open source library that is a blocker (a “blocker” is a term used to describe a bug that prevents key functionality in your application). In a panic, every one of your developers struggles to find a way to get your release to come out on time.

Thankfully, one of your rock star developers pulls down the source code for the open source library from the internet, gets a build working on this development environment, identifies the issue in the code, fixes the problem, repackages the library, and the updated version of the library is used. Problem solved, disaster prevented, release is on time!

Two important points to note about this whole thing:

First point: Unfortunately for many software companies, there is no rock star to save the day. Most developers do not dare check out the source code and attempt a fix. It is an daunting task, especially for developers who are already stretched thin on their own projects.

Second point: After you have made a change in the source code, now what do you do? You end up maintaining a branch from the original version of the product. Now when you upgrade to a new version of the software, you are stuck spending lots of time trying to re-incorporate your fix into the latest branch (if that is even necessary, it might already be fixed).

What is the solution? Promote open source software collaboration in your organization! Allow individuals in the organization to spend some of their time throughout the day becoming contributors to the open source software packages you use and you will both have the in-house expertise you need, have connections to other contributors in case you hit a nasty issue, and your fixes will be incorporated in the actual versions of the project you are using.

You might feel that your organization simply doesn’t have the resources available to do any open source contributions. Especially in a slow economy, developer time is expensive and needs to be properly allocated.

In this case you will probably not make changes to your open source software unless you are experiencing a major issue that you need to solve. And if you have already made the changes, have tested it and the issue is resolved… it really doesn’t take that much more effort to release the fix to the community. And remember, releasing the fix to the community helps you in the long run – as the fix will then likely make it into the later releases.

And it is definitely worth mentioning that getting your in-house programmers to do bug fixes is not your only option. Another option is to purchase short term open source support from a company like OpenLogic. You can rely on third party support to make the changes to the open source project, and rely on them to submit the fix to the community.  This is a great option when you need one of those urgent fixes but you do not have the in-house knowledge or resources to put forth.



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
.

The need for Enterprise Level open source support continues to rise, as does the adoption of OSS in the enterprise.  The interest of cutting costs and accelerating development is tops of everyone’s mind as we head into 2012, and an uncertain economy.  Budgets are tight and goals are as aggressive as ever for what is sure to be an exciting year with the inclusion of cloud technology in most IT budgets around the globe.

There is a responsibility facing enterprises to produce higher yields from the resources that have been allotted, and adoption of OSS is the answer many are looking to for that reprieve.  Costs can be cut without compromising functionality by making the switch to open source software, however, use of such software can also expose a company to unexpected and unacceptable obligation and risk depending on the terms of the license that governs its use and distribution.  Not to mention the concerns that come along with the replacement of commercial software with regards to your team’s open source expertise and preparedness.

A top challenge facing enterprises when adopting new open source technologies are gaps in internal expertise.   Therein lies the need to leverage a 3^rd party for Enterprise Level, commercial grade support options, in order to address these gaps in training, internal expertise, technical performance, and business process.  It is not uncommon for developers to be familiar with a new open source technology, but lack the extensive hands-on experience necessary to use it in production or migrate away from a proprietary solution.

Interesting to note that just last week the French Government tendered for open source support.  The tender details a need for support on hundreds of packages, covering two-thirds of the countries twenty-two ministries, spanning three years time, at a price of two million Euros.  Pretty amazing.

With all of the excitement and discussion regarding support options, it is however, highly common, that many searches for OSS support solutions are ultimately concluded with a choice of the status quo.  The decision to make no change at all, after exploring alternative solutions, happens frequently for a multitude of reasons.

Recently we surveyed our customers to find out what their top challenges were when they began looking for a 3rd party Open Source support provider.

The #1 answer was: Lack of information that was unique to their specific needs

We heard over and over that the information that they initially received was “generic”, a “blanket solution”, written from a “30,000 foot view”.  Our research showed that people in your position are looking for information that is unique to their enterprise to make the most appropriate decision in an efficient amount of time.

I thought it might be appropriate at this point, to share with you, one of our most popular resources, the Support Evaluation Kit Download.

As a result of the feedback we received, the kit will walk you through:

• Detailed analysis of support options including key questions to consider when evaluating these options


• A comprehensive support worksheet that will help you profile your organization’s open source usage and apply support coverage scenarios


• Case studies detailing how OpenLogic’s aggregated support model helps enterprises that use multiple open source packages but lack expertise or don’t want to tie up internal resources with support issues

For those of you that are leveraging open source software to cut costs and accelerate development, can you answer yes to these key questions?

• Are your open source deployments properly tuned and optimized?


• Is your team up to speed on the latest versions and related technologies?


• Is your open source policy up to date, effective, and enforced?

If you answered no to any of the above, your organization may not be getting the full benefits of open source – and may be at risk for problems down the road.

Whether you have been using OSS for years or you are considering a switch, either way, gaps in the internal expertise within your organization may be hurting the potential effectiveness of your open source initiatives.

What are your biggest challenges when searching for an open source support solution?

Subscribe to Enterprise Open Source by Email

 

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

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