March, 2012 | Enterprise Open Source Software Blog

Building the Business Case for Open Source Code Scanning

Posted by Jesse Hood on Fri, Mar 30, 2012

I often talk to people who are having a hard time developing the business case for purchasing and implementing a source code scanning tool or purchasing an application audit service. I respond by describing that a legitimate and successful business case in 2012 needs to include the following:

At minimum, a general understanding of the basics of open source software

Both the want and need to find and implement a solution

The organizational drivers and resources to develop a solution to a problem or to enhance and compliment an existing system that lacks efficiency or accuracy

Cross-functional approvals and resources from multiple departments

Accurate and balanced vendor evaluation and selection criteria

Hopefully some of the ideas in this article will resonate to help all of you continue building the business case as you consider how or when to start a scanning and license compliance initiative.

I’m going to start with the “want to” - a company that understands that complying with all licenses for third party code it uses, including open source software, is the right thing to do. Yet, that company may not have the resources or urgency to make the purchase and implement a plan. As a result, the “want to” is always harder to sell on than “need to.”

Complying with open source licenses, as requested by the original authors of open source projects, is the responsible approach to using other people’s software. To quote a colleague of mine on our engineering team, “it’s generally frowned upon to use someone else’s software code without proper attributions.” Scanning software code is now a pretty important part of ongoing compliance strategies for organizations. Those that understand this and appreciate the hard work of others want to comply, and are complying, to the best of their ability.

The founding ideology of this industry still exists today for good reason and the organizations in North America and Europe that are interested in ensuring license compliance are doing so to keep open source alive and healthy. In fact one could present numerous arguments and examples to support the fact that our day-to-day lives now rely on open source software. Consumer products like smart phones, newer cars, flat screen TV’s, most computers, all ISP’s, probably any cloud computing environment, maybe even a brand new waffle maker, all have open source software embedded in them. Those open source software components are most likely, if not definitely, being re-used by the company distributing it in their products. The reality is that if any company intends to keep using open source and selling technology, that has been created because of the history of the open source industry, then respecting the terms of open source licenses is just as important as respecting any commercial software license.

The “need to” category represents potential business risks that turn the "want" into an immediate need. Below are several examples as to why an organization needs to implement an open source scanning solution:

The organization understands and values all of the reasons included in the “want to” category and realizes that every day that passes without implementing some kind of process to proactively vet code bases for open source is increasing the exposure and risk of a “want to” turning into a “need to immediately.” The final outcome of some of these projects might identify a very low level of risk and exposure. Nevertheless, not actively addressing this potential (in order to determine risk) is a very dangerous approach to the use of open source software.

The organization has unknown exposure to security vulnerabilities in old versions of open source or the organization has already had some kind of breach in security due to an outdated open source environment.

There is a product road map or technology release schedule for the organization that has made an intentional (or unintentional) decision, to distribute open source software in a commercial product or to use open source in a customer facing web site.

The organization has been contacted by one of the governing bodies that are interested in enforcing license compliance -or- the individual author of an open source product has contacted the organization directly to inquire about the usage of their copyrighted software. If this kind of inquiry goes unanswered the worst-case scenario is a suit eventually getting brought against the organization(s) in question for violating the license or copyright.

There is a merger and acquisition (or divestiture) planned sometime in the calendar year and the assets to be acquired (or sold) have a known or high probability of including open source components.

There has been significant turnover in the personnel that have been involved in the use of open source and collecting any voluntary information about the usage and associated licenses would be impossible.

The organization outsources software development to a third party and:

The thing is, your company may not "need to" right now, but is it worth waiting until there is an urgent reason and scrambling to find a solution? The best business case is the case that includes a proactive approach, instead of reactive.

A few other considerations are included in my older blog articles and if there are other valuable reasons that our audience “wants to” or “needs to” start scanning source code to identify the open source please engage in a discussion on the forum below!

Subscribe to The Enterprise Open Source Blog via email

Follow @openlogic
Follow @cloudswing
Follow @JesseH303
View Jesse Hood's profile

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

0 Comments Click here to read/write comments

Tags: Legal & Compliance, Scanning & Provisioning, Scanning, Compliance, Governance, Open Source Management, Open Source Trends, Legal

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

Posted by Aaron Mandelbaum on Wed, Mar 28, 2012

Email Article

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

.

0 Comments Click here to read/write comments

Tags: Open Source Trends, Support, Training

Open Source Technologies Thrive in the Age of SaaS and Cloud

Posted by Rod Cope on Mon, Mar 26, 2012

Email Article

As we are moving some infrastructure to SaaS applications, I am reminded of previous debates about the effect of SaaS applications on Open Source Technologies. It's pretty clear that the growth in Open Source has accelerated and has even been enabled by the presence of game changers like SaaS and Cloud. The ability to cheaply and rapidly get new products to market has made the use of Open Source vital to many organizations and the sheer number of options is staggering. At OpenLogic, we build SaaS applications and those applications use hundreds of Open Source components. In fact, CloudSwing now contains more Open Source libraries in less than a year of development than OLEX has in over 4 years of development.

There are a few areas where Open Source has yet to make significant inroads that SaaS applications may have affected going forward. The inability to create a serious competitor to MS Office coupled with the rise of Google Docs have made it very difficult for Open Source alternatives to gain any real significant momentum. The most significant Open Source option has been hampered by continued uncertaintly around OpenOffice/LibreOffice communities in the wake of Oracle's acquisition of Sun. The other area where SaaS offerings are likely affecting the growth of open source options is true enterprise groupware. Sure there are plenty of mail server options in the Open Source space, but a true enterprise level competitor to MS Exchange has never really taken off. Hosted options such as Google Apps for Business and Office 365 are now giving many companies an easier option than managing a in-house alternatives.

While end user applications are often the last things for Open Source options to replace, foundational pieces such as libraries, frameworks, and servers continue to be areas of strength that are leading the industry into the future. Big Data is dominated by Open Source options such as Hadoop. Almost all the hot new frameworks (Ruby, Rails, Node.js, Python, PHP) in web application development are being driven by Open Source communities. Cloud platforms are dominated by Linux OS's such as Ubuntu and Open Source frameworks (Heroku/Rails).

In addition to the new technologies driving the industry forward, many of the old reliables continue to remain popular with our customers. We continue to see strong interest in key components such as Apache, Tomcat, JBoss, and MySQL. Interest in Open Source is very broad as companies continue to search for the best technologies to solve their problems. Expect this trend to continue to grow as new ideas build on each other to take the industry to even greater heights.

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
.

0 Comments Click here to read/write comments

Tags: Software Development Lifecycle, Open Source Trends, The Cloud

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

Posted by Jilayne Lovejoy on Fri, Mar 23, 2012

Email Article

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
.

0 Comments Click here to read/write comments

Tags: Legal & Compliance, Scanning & Provisioning, Training, Licenses

Open Source Management: Guidelines for Setting your OSS Scan Objectives

Posted by Dave McLoughlin on Wed, Mar 21, 2012

Email Article

When scanning your software for open source software, it is important to set and understand your objectives. Your objectives may effect how you approach the task of finding the various open source software components and licenses, what the final reports will look like, and what you ultimately do with the information.

0 Comments Click here to read/write comments

Tags: Scanning & Provisioning, Scanning, Compliance, Governance, Open Source Management, Security

Open Source Management: Dealing With New OSS Releases

Posted by Peter Williams on Mon, Mar 19, 2012

Email Article

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
.

0 Comments Click here to read/write comments

Tags: Legal & Compliance, Governance, Open Source Management, Software Development Lifecycle, Open Source Trends, Security, Training

Open Source Management: Take the Open Source Maturity Quiz

Posted by Aaron Mandelbaum on Fri, Mar 16, 2012

Email Article

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.

0 Comments Click here to read/write comments

Tags: Legal & Compliance, Scanning & Provisioning, Governance, Open Source Trends, The Cloud, Support, Training, Licenses

Establish an Open Source Governance Process to Improve Open Source Support

Posted by Greg Bell on Wed, Mar 14, 2012

Email Article

I’ve been blogging a lot lately about the benefits of open source governance – as well as suggesting ways to get started on your open source policy and create an open source governance training program – but one thing I haven’t yet talked about is the relationship between open source support and governance. In many respects, open source governance and support are two sides of the same coin, but interestingly many of the organizations we speak to about open source support haven’t yet established even a basic governance process.

In this post I’ll make the case that an open source governance process can greatly improve the efficacy of your open source support procedures, and likely save you money in the long run.

Adoption to Support to Governance

Here at OpenLogic we talk to organizations every day that have recently started using open source software and are interested in learning about commercial-grade open source support coverage. A typical “early adoption” scenario looks like this:

Engineers or IT staff start using open source in development or infrastructure projects (often without explicit permission).

Open source software usage expands as people realize it’s reliable, highly functional, and doesn’t have to go through normal procurement channels.

Management begins to realize that open source is being used within the organization, and that usage is increasing.

Something triggers an interest in purchasing an open source support contract – typically either a problem or a directive from a “higher-up” within the organization who wants to be sure help is available if needed.

The triggering event might result in the company deciding to get support through an online forum or by hiring experienced personnel rather than purchasing support from a company like OpenLogic, but the scenario remains the same: most organizations begin using open source well before they begin exploring support options. And considering this model, it’s not surprising that open source governance processes are established even later on – perhaps not until open source usage within the organization has expanded even further.

The Gap Between Open Source Support and Governance

Let’s take the above scenario a few years further down the line. Imagine now that the same company has broadly accepted open source usage and even encourages it – or at least evaluates open source and proprietary software equally – in certain scenarios.

As a result of increased usage, the company has established processes for obtaining open source support. Open source packages used in mission-critical deployments are covered by paid support contracts, but the company still relies on internal expertise and community forums for others. It’s a mixed bag, and support options even vary from division to division.

The CIO begins to get concerned that separate divisions are using different open source versions, following different support protocols, and perhaps even purchasing component-level support contracts that don’t extend to other divisions. Without enterprise-wide visibility into how open source is being used as well as which open source packages and versions are in use, it’s difficult to evaluate the organization's needs and standardize support protocols and contracts. An open source governance solution is long overdue.

Bridging the Gap with an Open Source Governance Solution

Whether the company develops its own governance solution or turns to a platform like OpenLogic Exchange, establishing governance processes creates transparency around the lifecycle of open source usage. Management can communicate and enforce policies about which open source licenses, packages, and versions are approved for use. Employees can follow a standardized request process for new or unapproved packages. Open source is tracked as it’s brought into the organization, and source code scanning enables the organization to verify that unapproved open source is never distributed outside the company.

With this visibility management can truly evaluate open source support needs, and then standardize and improve support processes across the enterprise – and likely reduce costs as well. Internal expertise can be better leveraged across divisions, unnecessary support contracts can be eliminated, and division-level contracts can be expanded to cover other relevant parts of the business. Standard support protocols for specific packages and versions can communicated throughout the organization, and the company can also explore aggregate support contracts that cover multiple open source packages for users throughout the enterprise.

Open source governance ultimately helps the organization standardize its support protocols, reduce support costs, and facilitate cross-divisional sharing of knowledge and expertise. It’s a happy ending, but what if the organization had implemented enterprise-wide governance processes years earlier when it began to explore support options? How much time and money could have been saved? And what other benefits might have been realized by better managing the pace of open source adoption as the company’s usage model matured?

Summary

With competing priorities and deadlines, it’s not surprising that open source governance processes typically aren’t established until an organization has moved well past the early adoption phase. However, I believe that it’s worth the effort to implement governance processes as early as possible, and continually evaluate and expand those processes as necessary going forward.

Open source governance has the potential to greatly impact the bottom line relative to open source support costs, not to mention other benefits such as standardizing procurement procedures and helping ensure compliance with open source licenses. The sooner you can implement a governance solution in your organization, the sooner you can begin to realize these benefits.

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
.

0 Comments Click here to read/write comments

Tags: Governance, Support

Open Source License Management

Posted by Aaron Mandelbaum on Tue, Mar 13, 2012

Email Article

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 during which to ruminate and refine terms as is often the case for custom-developed software.

Adding to the difficulty in understanding and interpreting open source licenses is the fact that 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.

This white paper examines the three most common open source licenses – GPL v2, LGPL v2.1, and Apache v2 – covering everything from the background of each license to practical compliance tips and sticking points to be aware of. Topics include:

Brief introduction to open source software

Overview of common open source licenses

License interpretation guidelines

Tips for open source license compliance

Resources to help you get started

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
.

0 Comments Click here to read/write comments

Tags: Legal & Compliance, Scanning & Provisioning, Compliance, Governance, Open Source Trends

Apache HTTP Server: New Features for Version 2.4

Posted by Aaron Mandelbaum on Mon, Mar 12, 2012

Email Article

The Apache Foundation released Apache HTTP Server 2.2.0 at the end of 2005. Now 7 years later there is a new major release of Apache HTTP Server. Apache HTTP Server currently has 65% market share according to Netcraft. There has always been two competitors in the web space - Apache and IIS - but in late 2007 Nginx was born and has been grabbing more and more market share everyday. Looking at the release notes for Apache 2.4 you can see that this release has a few features that match Nginx's feature set. Apache HTTP 2.4 has included something for everyone: performance increases; lower memory usage; new modules; program enhancements and new features for old modules.

I have picked 10 pieces from the change log that I feel are important to know about.

Run-time Loadable Multi-Processing Modules (MPMs)

Multi-Processing Modules (MPMs) are responsible for binding to network ports, accepting requests from clients, and dispatching children/threads to handle requests. Before Apache 2.4 MPMs had to be statically compiled into the Apache binary and this would cause a re-compile if you wanted or needed to change from a threaded or server based Apache instance. Now with the new Apache 2.4 release you can pass the --enable-mpms-shared option to your configure which will enable shared or Dynamically loaded MPMs. With this feature enabled, you can on-demand change the MPM your server is using, which is great for testing and environments when you want the same Apache binary but different MPMs.

Event MPM

Nginx used to be the king for event driven web servers. Yet, if you look at the market share, you can see that Nginx has grown its share while Apache has lost share. I believe this has to do with the mobile market where you have more requests that are long-running but of a small size. This demand stresses a server that needs one thread running for every client.

The event MPM is the "fix" for Apache's "keep alive problem" making it so Apache no longer needs to have one thread open per concurrent client. There are still issues with this module and one of them occurs when using SSL. Since the event MPM is based on the old worker, it will step down to normal worker functions when you are on a https connection. You will also need a system that is compatible with KQueue and EPoll for the event MPM to work.

NameVirtualHost is deprecated

You do not need to use the name virtualhost anymore when you create a virtualhost context. Apache finds and enables NamedVirtualHost for you so you can now remove the NameVirtualHost settings.

Config file variables

This is a good one! Now you can use variables in your configuration files that make the file much more versatile and clean. You can now add the "Define rootDir /var/www" and just use that variable (${rootDir}) throughout the file; I think this is a great new feature for Apache 2.4.

Reduced memory usage

I think this is one more stab at NGinx since one of the two reasons people go to NGinx is memory usage (and Event driven) so this is a welcomed addition. I do not have any statistics yet, but as soon as we start hammering Apache 2.4 in the lab here at Openlogic we might release some data to see how Apache 2.4 performs in the memory space.

mod_heartmonitor new module

Status: Experimental! This is a module that Apache and mod_balancer needs to get a full feature set for loadbalancing and proper load distribution in a cluster setup. You have mod_heartbeat that talks to mod_heartbeatmonitor using UDP packets so that a frontend Apache can correctly loadbalance clusters of Apache using busy/idle workers information.

mod_sed new module

Status: Experimental! mod_substitute is still available and probably the module you would use for a production server. However, mod_sed is a more advanced substitution module that allows you to edit the response body using sed. This is a very promising module and I can't wait to see what this can do under load.

mod_session new module

Mod_session and mod_auth_form together will allow you to configure Apache to handle the form authentication and then pass the credentials back to your application which is a great add-on to Apache. For a legacy system where you want to implement a better more standard authentication mod_session combined with mod_auth_form is a great fit.

"We want to instead provide a service to module developers as well as sys-admins who have always needed to worry about implementing sessions, in one way or another," Jagielski said. "Mod_session provides a universal framework that people can use, which has been lacking for a long time."

Jim Jagielski, ASF President and Apache HTTP Server Project Management Committee

mod_ssl enhancements

mod_ssl has a few new tricks up its sleeve and the biggest might just be that you can now share your SSL Session cache between Apache servers using a memcache server. Online Certificate Status Protocol (OCSP) is now somewhat supported; Apache can be configured to check the client certificate. Apache also supports OCSP stapling, where the server verifies the certificate during a client handshake.

mod_proxy_balancer enhancements

Here is the list from Apache:

More runtime configuration changes for BalancerMembers via balancer-manager

Additional BalancerMembers can be added at runtime via balancer-manager

Runtime configuration of a subset of Balancer parameters

BalancerMembers can be set to 'Drain' so that they only respond to existing sticky sessions, allowing them to be taken gracefully offline.

Balancer settings can be persistent after restarts.

There are some very cool new features here, but I think the one that is going to get most people excited is the new draining function so that you can easily remove servers from the balancer even under daytime load. Adding a new server to you balancers under load without the need to restart the cluster and have that server stick after a restart is also a great feature.

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
.

0 Comments Click here to read/write comments

Tags: Open Source Trends, Support

Upcoming Webinar: Choosing the Right Open Source Support Model

Posted by Aaron Mandelbaum on Thu, Mar 08, 2012

Email Article

Who: Presented by Kim Weins, Strategic Marketing Advisor to OpenLogic

0 Comments Click here to read/write comments

Tags: Open Source Trends, Support

Cloud Technology: Choosing a Public Cloud Provider

Posted by Rod Cope on Tue, Mar 06, 2012

Email Article

As you almost certainly know by now, the world is chock full of cloud providers. Hundreds of them. Which should you choose if you're just getting started and why?

Like most "which technology should I use?" questions, this one has the typical answer, "it depends." If you only want to use or "rent" somebody else's software for maximum convenience, you want a SaaS (Software-as-a-Service) solution. Now that the easy answer is out of the way, let's get down to business.

IaaS or PaaS?

At first blush, it seems like a simple question: Do you want direct access to the infrastructure (e.g., virtual machines) or do you only need access to abstractions (e.g., API's)? Ideally, you'd want both. Sometimes you want the convenience of pre-built, hosted, scalable services such as storage (think Amazon's S3), but other times you'd like the complete flexibility of having root access to a virtual machine under your control. I expect most enterprise developers and IT folks will agree. We want the best of all worlds and we have a hard time giving up control to a pure PaaS provider. This stance tends to rule out options like Google App Engine, Heroku, and others that look like a black box from the outside and put significant restrictions on the programming languages, application frameworks, databases, and other technologies you can deploy on them. Let me be clear however, that I would still strongly consider deploying to many of these platforms for specific use cases. An instance where I'm not as concerned about complete implementation control or strict compliance with industry standards that demand I know exactly what's going on with my data at all times and require me to prove it.

I call the "both" answer "IaaS with benefits". Among others, the list of providers in this category includes Amazon AWS, Rackspace, and Windows Azure. Each "IaaS with benefits" provider lets you control a virtual machine from the ground up. It also gives you a variety of PaaS services such as blob storage, data stores, queues, and other features. The menu of additional services ranges from just a few (e.g., Rackspace) to dozens (e.g., Amazon AWS), which means it can be an important dimension to compare when you're considering a vendor.

In summary, here's my quick answer to the "IaaS or PaaS" question: IaaS if you want total control, PaaS if you want scalability with less administration, and "IaaS with benefits" if you want to mix and match the best parts of each.

New to the Cloud?

If you're new to cloud, it's probably easier to start with an IaaS solution that gives you complete access to virtual machines. That way things are similar to what you've experienced in the past and keeps the learning curve manageable. Once you get comfortable with the environment, you might want to look into cloud storage and other "benefits" that provide flexibility and scalability. I also recommend you try different clouds to get a good feel for their feature sets and associated pros and cons. After a while, you'll have a pretty good feel for performance, reliability, manageability, and cost of various workloads on particular clouds.

This may sound like a lot of work, and it is, but enterprises never have a one-size-fits-all solution for anything. Each use case comes with its own requirements and therefore certain technologies are a better implementation fit than others. Over time, this naturally leads to using a bunch of different technologies, such as open source projects and cloud providers. Don't try to hold back the tide, but rather embrace this diversity! Use the best tool for each job to get better results and happier technologists.

Conclusion

Pick a cloud provider that lets you get started quickly and easily, but will grow with you over time. Better yet, choose an abstraction technology like CloudSwing that lets you select where you want to deploy each application. That way you can rapidly try different clouds and learn which works best for each of your use cases without concern for cloud lock-in. Whichever route you take, consider "IaaS with benefits" solutions for the flexibility and the option for total control.

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
.

0 Comments Click here to read/write comments

Tags: Open Source Trends, The Cloud, Support

Enterprise Open Source Scanning & Application Auditing Tasks: Outsource or Internalize?

Posted by Jesse Hood on Sun, Mar 04, 2012

Email Article

Scanning software code bases to identify the presence, or verify the absence, of open source materials, the associated license information, and other third party components, is now a best practice for many corporate organizations. More specifically, enterprises that are interested in achieving the goal of diligent license compliance practices, streamlined policy management, and a safe adoption strategy for open source software, have dedicated their resources to these projects.

Today’s article is a comparison of some of the pro’s and con’s involved in owning these initiatives 100% in-house or outsourcing some of the work to a company that has expertise in using source code scanning tools and analyzing open source license obligations.

The question of bringing and owning any new IT project initiative in-house vs. outsourcing the work to expert consultants is not a new one. There are many different opinions and perspectives from IT industry blogs that provide some excellent considerations on the general decision of in-house vs. outsourced. So I wont beat this one into the ground any more. This article will bring an enterprise open source management perspective to the discussion and eventual decision that needs to be made about in-house code scanning or outsourced application audit report preparations.

The biggest consideration is most likely going to be tied to the organization’s industry and the frequency expected to complete these ongoing tasks. For example a mobile device manufacturing company, ISV, or other technology company that has built their primary revenue generating activities around the commercial distribution of open source (or commercial products that contain open source) may choose to have the in-house solution that will eventually identify new open source components and policy violations on a daily basis. After completing the base line scan of a product line, the scanning can be automated so that as new code is being introduced into their development life cycle the open source audit reports are updated accordingly.

Alternatively, an enterprise that uses open source for a variety of purposes but is not building the core of their business model around the distribution of open source might choose to outsource only 1 scan a year or more realistically 3 or 4 scans of a code base each year. The target of the selected code base to be audited is covered in more detail in an article I wrote (Linear vs. Targeted: The Location and Amount of Source Code Scanning is Important) and the basic criteria might include only scanning the distributed product line(s), the acquisition (or divestiture) of any new software code, or simply a semi-annual inventory report to evaluate how the open source environment has changed over the last 3-6 months.

Another significant consideration that gets overlooked is the allocation of the human resource. Someone will need to help prepare the applications that need to be scanned and either run the scanner and associated analysis themselves or prepare to ship the applications to a company like OpenLogic for analysis. Depending on the size of the projects, size of the organization, and location of the code base, just preparing to do the scan, might be a significant undertaking. There are some general open source provisioning strategies that can really help in preparing for a source code scan to make the project much easier and accurate.

Speaking of accuracy this leads me to my next consideration.

Our OSS Deep Discovery scanner has customizable settings that will produce different levels of granularity in the scan results. Depending on what your ultimate goal is in completing a source code scan and open source application audit you may not need to open every single file to verify the presence or absence of open source or it might be critical to have the highest possible level of accuracy. Out sourcing the work is going to achieve an extremely accurate result of an application audit report, so accurate that we offer limited indemnification to our clients to back up our professional services work. Not to say that our clients who are running these projects entirely in-house can not achieve a similar level of accuracy and with our support and training on these tools you definitely can.

The final consideration I will mention is the amount of time expected and needed to complete the analysis after the scan is finished to prepare an open source application audit report. This is one area that outsourcing the work can potentially help. Unless an internal resource is already an expert in analyzing source code to accurately identify open source components they will probably need a solid 40 hour week or more of using a source code scanner to feel comfortable and confident in the work they are doing.

Every organization and usage of open source is unique so there is obviously no one right answer and the approach that seems to be the most popular for our clients is a combination of the two. Many customers are deciding to outsource the “heavy lifting” to us first to complete their baseline scan of a product line(s) and then in years 2 and 3 are taking in-house ownership of the initiative to complete their delta scans on new product versions.

Regardless of how you approach the project, there are opportunities for you to leverage the tools, expertise, and resources needed to help you get the job done right!!

Subscribe to The Enterprise Open Source Blog via email

Follow @openlogic
Follow @cloudswing
Follow @JesseH303
View Jesse Hood's profile

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

0 Comments Click here to read/write comments

Tags: Scanning & Provisioning, Scanning, Compliance, Governance, Open Source Trends, Support, Security

Cloud Technology, Big Data & Hadoop

Posted by Aaron Mandelbaum on Thu, Mar 01, 2012

Email Article

Big Data seems to be the word of the year. Everywhere you look there is Big Data staring you in the face: Blogs dedicated to discussing Big Data; LinkedIn groups with over 10,000 members focusing on Big Data topics. Just under 15,000 times each month, the exact phrase Big Data, is entered into the search engines of people across the world.

Wikipedia begins to describe Big Data as datasets that grow so large that they become awkward to work with using on-hand database management tools. Because there is so much content being created at speeds we have never before seen, there is this preconceived notion that in order to be as efficient and productive and intuitive as we all want to be, Big Data needs to be addressed to some degree or another.

Three notions that seem to be facilitating this Big Data movement include:

Faster analysis of larger operational data will help you make better decisions.

More in-depth analysis of customer data will guide you to better customer segmentation.

Insight into larger data sets will help you come up with innovative product design.

Usually when Big Data is mentioned, the reference or inclusion of cloud technology is not far behind. That discussion includes public and private clouds, scalability, flexibility, open PaaS and all of the other cloud characteristics. Therein lies the solution that many have already found, and that is Hadoop. "The Apache Hadoop software library is a framework that allows for the distributed processing of large data sets across clusters of computers using a simple programming model." Not every cloud needs Hadoop, and Hadoop doesn't need the cloud. But when leveraged collectively you have found a pretty good solution for your Big Data concerns.

Some interesting users of Hadoop include:

Amazon, eBay, Rackspace, Twitter, among many others (http://wiki.apache.org/hadoop/PoweredBy).

LinkedIn uses it on 5,200 cores to manage 7.2 PB or 7,200,000 GB of data.

Facebook uses it on 11,200 cores to manage 12 PB.

Yahoo uses it on 36,000 cores to manage 18 PB.

At OpenLogic, we store all of the world's open source code in Hadoop as part of our scanning solution.

Hadoop is now a generally accepted viable open source solution for your Big Data dilemma. It is by far the leading solution in its field. It is the Linux of large-scale data processing and is understood to be the long term solution for organizations of all sizes. Like all open source, Hadoop is a great win-win. It saves the wasted energy of developing many different and not nearly as capable closed solutions. Also, because Hadoop has become so capable, it can provide us with the reliable data management foundation on which so many of the large-scale Internet innovations of the last few years have been built.

Harnessing cloud technology and the power that Haddoop provides us with, we can realize the agility that we are all looking for, as we slowly migrate different parts of our enterprise, and even our personal lives, into some dynamic of the public and private clouds. Cloud technology offers the end user many different ways to calculate ROI and justify the move to the cloud.

Big Data can be managed with the right resources and technology while still providing you and your customers with the opportunity to be agile. Ramp up ramp down, be creative, be innovative, and use data driven decision making to do it as efficiently as possible.

Source: cloudtweaks.com via CloudTweaks on Pinterest

0 Comments Click here to read/write comments

Tags: Open Source Trends, The Cloud

Subscribe by Email

Most Popular Posts

Connect With Us!

Building the Business Case for Open Source Code Scanning

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

Open Source Technologies Thrive in the Age of SaaS and Cloud

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

What is the SPDX License List?

What's in a name?

Open Source Management: Guidelines for Setting your OSS Scan Objectives

Open Source Management: Dealing With New OSS Releases

Security improvements

Performance improvements

Productivity improvements

How to stay up-to-date

A stitch in time saves nine

Notifcations

Commit to staying up-to-date

Ask for advice

Open Source Management: Take the Open Source Maturity Quiz

Establish an Open Source Governance Process to Improve Open Source Support

Adoption to Support to Governance

The Gap Between Open Source Support and Governance

Bridging the Gap with an Open Source Governance Solution

Summary

Open Source License Management

Apache HTTP Server: New Features for Version 2.4

Upcoming Webinar: Choosing the Right Open Source Support Model

Cloud Technology: Choosing a Public Cloud Provider

Enterprise Open Source Scanning & Application Auditing Tasks: Outsource or Internalize?

Cloud Technology, Big Data & Hadoop

Enterprise OSS Blog Policy

Browse by Tag