Seth Godin blogged the other day about how wants can turn into needs when people have all their basic needs met, and it got me to thinking about how different organizations with similar open source usage models can have very different perceptions about the necessity of open source support. Why do some companies approach open source support as a luxury — nice to have, but not worth prioritizing until a problem occurs — while others place it firmly in the need column?

Licensing Often Sets Expectations

Few companies purchase commercial software solutions without also purchasing ongoing support, but the dynamic is often markedly different for open source. Open source software is of course different from commercial software in some very significant ways — free to download and try, often introduced to the organization bottom-up rather than top-down, typically easier to customize, and so on – and these differences clearly play into perceptions about open source support.

When a commercial software solution is purchased, there’s typically a willingness to pay an annual maintenance fee in order to protect the initial investment in the software. Take away the up-front investment in licensing, and the perceived importance of investing in support services often goes away as well. In other words, the licensing can set expectations about other costs associated with the software, such as support.

A quick look at Google's global monthly search statistics confirms that the number of people looking for open source downloads by far outnumbers those looking for support, consulting, or training services for that software.

Open source software – 450,000 Open source code – 74,000 Open source download – 40,500 Find open source – 3,600

Open source help – 18,100 Open source support – 8,100 Open source training – 4,400 Open source consulting – 880

The True Cost of Free

Let’s be clear about one thing: open source isn’t exactly free. Sure, you can download it and try it out without paying a licensing fee, but a variety of other expenses can come into play throughout the life of the software. You’ve probably heard this before, but it bears repeating: open source is free as in puppies, not free as in beer.

Just like commercial and even proprietary software solutions, open source software requires personnel to configure and maintain it. Those employees may require training on new versions, or you may hire new personnel who need to be trained. Consulting services might be needed to assist with migrations and special projects. And last but not least, commercial open source support might be required to help resolve problems and keep critical systems up and running. In this regard, open source is no different from any other type of software.

Now, none of this will come as a surprise to most CTOs, but I’ll wager that many still perceive open source as somehow different from commercial software. "Sure, I realize that there will be costs associated with open source over time," one might say, "but we’ll cross that bridge when we come to it." In other words, we’ll wait until the want becomes a need.

Evaluating Needs vs. Wants

As I mentioned at the top, not all organizations view open source support as a want. Indeed, some of the world's leading companies have firm policies that all software used in the enterprise — including open source — must be backed by technical support. What drives companies to take this approach? I believe there are several best practices common to these organizations:

• Software is software: Companies that view open source support as a need do so because they treat all software the same regardless of the source. Whether open source, commercial, or proprietary, these companies have a policy that all software must be approved for use and supported. These companies also strive to ensure compliance with open source licenses.

• Low risk profile: Should a serious issue arise, these companies want to ensure that help is just a phone call away. Support can certainly be purchased on short notice, but what happens if a critical system breaks after hours or on a holiday? Even if a problem happens on a Monday morning, can management and procurement approve the purchase quickly enough to avoid serious repercussions? Companies with a low risk profile address these questions by securing open source support ahead of time.

• Access to the community: Most open source support providers employ or contract with members of the open source community, so a commercial support contract can connect a company to the community that actually develops the software. This can be critical when it comes to fixing bugs, suggesting new features, or committing your own changes and enhancements back to the open source project.

Summary

Whether you view open source support as a want or need likely depends on many different factors. The amount of open source software used in your organization as well as how that software is used undoubtedly factors into the equation, and there may be other considerations beyond the best practices I highlighted above. How do you view open source support and other costs associated with open source? Have your views changed as your organization has increased open source usage in recent years, and do you expect any changes in your viewpoint in the near future?



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
.

The Software Package Data Exchange (SPDX) standard is getting some love lately and this is good news for open source license compliance. Which is, in turn, good for open source in general. If you are involved in software license compliance activities you need to include SPDX in your plans for the future. It will allow you to manage the risks of software licensing in a more efficient and predictable way than ever before.

SPDX defines a standard way to represent the contents and licensing of software packages. This standard representation provides a shared vocabulary for tools involved in managing license compliance. The SPDX standard is being developed under the auspices of The Linux Foundation as a way to ease complying with the licenses of open source software. The model provided by SPDX is fully compatible with proprietary software licensing also. This means that SPDX provides a uniform way to represent the licensing of any software package. Being able to treat both open source and commercial software the same way allows license compliance processes and tools to be simplified and streamlined.

Reuse

A key value to SPDX is the reuse it can facilitate. Once a package has been analyzed, an SPDX file can be saved containing that information. The next time that package is encountered, rather than redoing the analysis, the previously saved SPDX file can be used. The shared vocabulary provided by SPDX means that other tools, organizations and people will be able to understand the information. This sharing could be purely internal if your organization maintains a library of SPDX files for packages it has seen in the past. Or the sharing could even be across multiple organizations if, for example, the supplier of a package could provide SPDX files to purchasers so that they know how to comply with the licensing of that component. You could even get SPDX data for open source packages from an independent third party. We recently published SPDX files for six popular open source packages. That data is free for anyone to use. Feel free to download and use them to streamline your license compliance process.

Another level of reuse supported by SPDX is the license list. This list is a curated set of common open source licenses. The list exists primarily so that an SPDX consumer can be sure they know what it means when an SPDX file states that a package is licensed under, for example, the GPL version 2. Licenses on the list are given a unique, permanent short name and a permanent URI. These identifiers provide a way to communicate about which licenses are used by a package in an unambiguous way. The license list also indicates when it exists in other license lists. This can be helpful working with legacy data, or communities that maintain their own license lists. Using the license list as your primary repository of license info is often a simple, highly effective, way to utilize the value of the SPDX standard.

Automation

The automation potential of SPDX is the aspect I find most compelling. I am a software developer so that is not particularly surprising. The superb machine processability of SPDX data opens the door to huge improvements in license compliance processes. Imagine being able to amalgamate various existing SPDX files for libraries you use, spot check them for correctness, then run a scanner on your code and merge that information into the SPDX data and then feed that into a tool that gave you a simple checklist of things to do before shipping your software. Now imagine being able to do that with minimal manual effort. That is the promise of SPDX. All of the tools you use speaking the same language so that you can easily integrate the best tools available, whether they are open source, commercial or custom built. With SPDX 1.0 we have the technology we need to facilitate that dream. Already most vendors in the license compliance space support SPDX. The SPDX working group also provides a great set of open source tools for working with SPDX data. This means that we can start automating and streamlining the compliance process today.

Future proofing

Vendor neutrality is another important feature of SPDX. This is important regardless of whether you use bespoke tools, the tools of a single vendor, mix and match tools created by various vendors or don't use any tools at all. The shared vocabulary provided by SPDX means that you are never locked in to a particular tool. If you find a new tool to improve your compliance efforts you can take all the data you already have and import it, or take it's output and use that data with your existing tools. Even if you currently have a completely manual process SPDX still has potential benefits. Using the open source tools provided by the SPDX working group today means that you can easily move to a more automated process in the future with minimal effort. The freedom provided by SPDX is hugely valuable.

As you can see SPDX is a giant leap forward for license compliance. It provides capabilities for improving the quality and reducing the difficultly of license compliance efforts. These benefits come from the ability to reuse previously completed work, automating the process more aggressively and avoiding vendor lock-in. At OpenLogic we are strong supporters of the SPDX effort, both by contributing significantly to its development and by supporting SPDX data directly in our scanning and compliance tools and services. Improving open source license compliance is better for everyone and SPDX provides a real way to achieve that goal today.



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
.

BROOMFIELD, Colo. April 20th 2012—OpenLogic, Inc., provider of enterprise open source solutions for the data center and the cloud, today announced that its open platform as a service,  CloudSwing, is now available on AWS Marketplace. OpenLogic CloudSwing is a Platform as a Service (PaaS) that provides complete choice around infrastructure, components and programming languages. In addition, CloudSwing provides easy configuration, cost tracking, application monitoring and enhanced enterprise grade security for public or private clouds.

Enterprise developers interested in learning how they can quickly and easily deploy to the cloud can see OpenLogic’s video “OpenLogic CloudSwing Demo: Your App. Any Stack. Any Cloud: https://bitly.com/CloudSwingPaaS.”

AWS Marketplace is a new online store where customers searching for business and development software can find, compare, and immediately start using software in the Amazon Web Services cloud.

“We are excited to be among the first participants of the AWS Marketplace,” said Rod Cope, CTO and Founder of OpenLogic. “OpenLogic is uniquely positioned to offer easily deployable open source stacks and full enterprise grade support for both fixed and custom built stacks in the cloud.”

OpenLogic’s products available in the new AWS Marketplace provide:

• Stack flexibility: OpenLogic will provide pre-configured stacks including LAMP, Nginx, Tomcat, Node.js and Rails and custom stacks using OpenLogic CloudSwing. CloudSwing enables users to quickly and easily deploy either pre-built or customized technology stacks in the Amazon cloud and track associated costs of the deployment.

• Enterprise grade security: All stacks pre-configured with security best practices.

• Enterprise support: Commercial grade support including business hour or 24x7 with response time commitments as low as one hour.

• Flexible pricing: For a flat monthly fee, OpenLogic customers get unlimited support incidents on all of the components in the open source stack. There are also free options for customers who do not need support.

To view OpenLogic products and services available in the AWS Marketplace, please visit:

http://www.bit.ly/openlogicAWSMarketplace.

 

About OpenLogic

OpenLogic is a leading provider of enterprise open source solutions for the cloud and the data center.  OpenLogic helps hundreds of leading enterprises across a wide range of industries to safely acquire, support, and control open source software.  OpenLogic offers certification, commercial-grade technical support and indemnification for over 650 open source packages backed by the OpenLogic Expert Community.  OpenLogic also offers CloudSwing, a complete open PaaS solution for enterprises seeking to deploy applications and customized open source stacks in the cloud, and OLEX Enterprise Edition, a SaaS solution for open source scanning and governance.

 



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
.

 

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.

Read the full article

 

Apache HTTP Server: New Features for Version 2.4

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.

Read the full article

 

Cloud Technology, Big Data & Hadoop

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.

Read the full article

 

Preparing for Your First Cloud App

There’s a lot of confusion out there around the so-called “cloud app”.  What is it, just another term for “SaaS”?  Or does it refer to running your own application in a public cloud?  As with many phrases that include the ubiquitous word “cloud”, it can mean just about anything.  In the context of this post, “cloud app” refers to an application you’re running in a public cloud, such as Amazon AWS or Rackspace Cloud.

Read the full article

 

5 Ways an Open Source Governance Process Can Improve Your Organization

Is one of your resolutions for the new year to create an enterprise open source governance process for your organization, or review and update your existing governance process? If your organization doesn’t already have an open source governance process, this should definitely be on your list of goals for 2012. Likewise if you have a governance process that’s outdated, incomplete, or inconsistently implemented throughout the organization.

Read the full article



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
.

In a recent blog article Using Categorization to Simplify Open Source License Compliance I talked about simplifying open source compliance through license “categorization” where I listed the common categories used in many open source licenses. In this article I’m going to talk about creating an open source compliance checklist based on those categorizations.

In OpenLogic Exchange Enterprise Edition (OLEX), we have analyzed several hundred open source licenses and created a list of high-level obligations for each license. For example, in OLEX the Apache License 2.0 list of obligations looks like this:

• Distribute copy of license
• Give notice of or fulfill other requirements related to modified files
• Obligation to include notice text or files
• Obligation to include copyright or trademark notice
• Obligation to indemnify contributors
• Obligation to apply license to original or derivative works
• Restrictions regarding use of trademark
• Termination of patent license upon filing of patent litigation

If you don’t have the luxury of an OLEX Enterprise Edition subscription, you will want to take a similar approach and summarize the list of obligations in easily digestible “chunks.” This will make it easier for the team to take steps to comply with the various licenses used.

Next you want to examine under what conditions you need to meet certain obligations. For example, the requirement to supply documentation about modifications to open source are only triggered when you modify the code. By creating a set of triggers tied to your list of obligations you can quickly determine if you need to take steps or not.

You can then use these sets of triggers to ask your development team how they are using the open source in your product. Once you have their answers in hand, you can begin to eliminate the obligations you don’t need to meet which in turn helps keep the list manageable.

Some common triggers include: distribution, modification of source and creation of derivative works via linking. So for example, you can confirm that open source found in your source files is indeed distributed with your product or not. It is surprising how many files that contain open source in your source tree actually don’t get distributed with the final product. Or, if your code links to an open source library, how so? Dynamically or statically? The answer to these questions allows you to pick the relevant obligations.

Once you understand your list of high-level obligations by license and when those obligations are triggered you can begin to build your checklist. When we build compliance checklists for our customers we build the list by obligation type and license, then also list the responsible packages. For example if we identify a modification requirement in a license, we list the products that have been modified (down to the file level), so that we can later verify modification requirements have been met.

Finally, once you have your checklist in place you can work with your various functional teams to verify that all physical steps have been take to comply. Has your documentation group updated the product documentation to include the appropriate trademark, copyright and attribution requirements? CHECK. Has your development team met all modification documentation requirements and made sure they didn’t remove any copyright statements? CHECK. Has your legal team reviewed your product EULA agreement to make sure it doesn’t conflict with any of the open source licenses and are they fully aware of any restriction on use and have agreed that your organization can meet these restrictions? CHECK. If you need to provide source code via physical medium or hosted download site, is your organization prepared to fulfill requests? CHECK.

The process of license compliance is not trivial but by taking advantage of license categorization, high-level lists of obligations and triggers, you can make the process manageable.

I invite you to comment and provide insights on how your organization complies with open source licenses. If you are interested in learning more about OLEX or services provided by OpenLogic can assist you in your compliance, please feel free to contact us at sales@openlogic.com.



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
.

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
.

Open source software is used by organizations both large and small for everything from desktop applications to mission-critical infrastructure, but many enterprises have inconsistent open source support coverage or lack technical support altogether. Just as most companies won’t use commercial software without technical support coverage, it’s important to evaluate technical support needs and options for any open source used in the enterprise. For some companies it makes sense to rely on internal expertise for open source support, while others require commercial-grade support coverage for some or all of the open source software they use.

In this post I’ll outline the key issues you should consider when evaluating support options for the open source deployed in your organization. I’ll also link to a resource that can help you work through the pros and cons of each option.

Supporting Open Source with Internal Expertise

It’s not uncommon for enterprises to rely on internal expertise for open source support, especially when open source is first introduced to the organization. After all, it’s usually an organization’s developers or IT staff who first bring open source into the company, and it often makes sense for those same individuals to support the technology they want to use on the job. In this situation, the internal support team typically utilizes open source community forums and mailing lists to help troubleshoot and resolve problems.

This approach to open source support may be appropriate for smaller organizations, companies in early adoption phases, non-critical open source deployments, and companies with extremely tight budgets. However, as open source becomes a bigger and more critical part of development and/or IT infrastructure, organizations need to move beyond internal expertise and treat open source support the same as commercial software.

Some of the key issues you need to consider when evaluating this option are:

• Project Maturity – Is the project community large, does it respond to questions in a timely fashion, and is documentation available?

• Nature of the Deployment – Is the open source package used in mission-critical applications? How long can you wait for help if problems arise?

• Frequency and Nature of Issues – How often do you expect issues to arise, and how complicated might they be? Will you ever need support outside of normal business hours?

• Staff Time and Expertise - How much experience does your staff have with the software? Do they have time to spend resolving support issues?

• Privacy - If an employee posts a question on a community forum, are you at risk of disclosing confidential information? Is there a policy against this?

• Bug Fixes - Should you encounter a bug in the open source package, are your personnel capable of creating and submitting a fix to the community?

Component-Level Support for Open Source

Component-level support contracts are typically purchased to cover open source used in mission-critical infrastructure or applications, or to “fill expertise gaps” when personnel lack the time or expertise necessary to support particular packages. This option is often a good fit for organizations that are just beginning to use an open source package and have limited expertise. Organizations also may purchase component-level support after relying on internal expertise during initial phases of testing and experimentation.

Component-level support offers enterprises the flexibility to mix commercial-grade support for some packages while relying on internal support for others. It also allows organizations to scale coverage levels as needs evolve. However, “one-off” open source support contracts like this typically cost more on a per-package basis than contracts covering multiple packages, and may also be limited in scope when it comes to integration issues.

Some of the key issues you need to consider when evaluating this option are:

• Open Source Experience – How broad is the support provider’s experience with open source software?

• Community Involvement – Is the support provider involved with the open source community behind the package? Has it contributed code or patches to the community?

• Indemnification – Does the provider offer indemnification coverage for the open source it supports? What are the limits and remedies?

• Cost – How much does support cost? How many incidents are included in the contract? Are there limitations? How does this compare to other providers?

• Versions – Which versions of the package are supported, and how often does the provider “sunset” coverage for older versions? Will you be forced to upgrade in the future in order to maintain coverage?

• Integration – If the open source package is used in conjunction with other software, will the provider fully troubleshoot issues related to the integration or blame the problem on other applications?

Aggregated Open Source Support Coverage

Aggregated support contracts are ideal for organizations that use multiple open source packages and don’t want to tie up internal resources with support issues. By purchasing support from a single provider for multiple open source packages, enterprises can often simplify internal procurement and help desk procedures. In addition, aggregated coverage is likely to be cheaper than purchasing multiple component-level support contracts from a variety of providers.

In addition to the issues highlighted above for component-level providers, the following issues should be considered when evaluating an aggregated support contract for multiple open source packages:

• Number of Packages Supported – Does the provider offer support for only a few specific packages or a broad range of open source software?

• New Packages – If you begin using additional open source, will the provider be able to extend coverage to those packages? Can it extend support coverage for open source packages not currently on its list?

• Other Services – Does the provider offer complimentary open source services that may be required in the future? What are the costs of those services?

Summary

The right type of support for your organization depends on many different factors, and your open source support needs will almost certainly vary over time. Open source packages – and companies’ open source usage models – can change rapidly, so it’s worth re-evaluating your support options on an annual basis.

For a deeper look at the issues to consider for each of the open source support models, take a look at our Open Source Support Evaluation Kit. This free resource provides additional detail on the key issues outlined above and also includes a worksheet to help you work through the questions and costs you need to evaluate.



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
.

LinkedIn contains a massive amount of valuable information about potential new hires that you can use to your company’s benefit. It provides you a single website you can use to view a person’s past work history, recommendations from other LinkedIn users, education background, etc.



By itself, LinkedIn is just another website where you have to login to get what you need. And you might be thinking that sure, the data is useful, but how do I get that data into my own internal system so that our internal applications or databases can utilize that information?

LinkedIn provides what is called an “Application Programming Interface” (API), which is a fancy way of saying that you can use web services to access LinkedIn functions.

In order to use the LinkedIn API, first you must register at the LinkedIn developer website.

Once you're registered, you'll receive a secret API key. This key validates that you are you, and not someone else on the system.

There Are Many Programming Language APIs and Tools!

After getting your API key from LinkedIn, you now have to decide which programming language(s) to use in order to leverage LinkedIn. Also... are you using web server applications? Desktop applications? Are they mobile applications?

There are LinkedIn libraries and tool libraries available that can help integrate your particular programming language and application type with LinkedIn! See the LinkedIn Libraries and Tools area for more information.

Examples of Open Source Libraries that Connect with LinkedIn

PHP
Let's say your company uses PHP. You can use the open source library simple-linkedinphp to very easily and effectively access LinkedIn data from your website. The simple-linkedinphp software package is a web service wrapper around the LinkedIn API. It is designed to be extremely simple and lightweight to make integration with LinkedIn as painless as possible.

Java/J2EE
Does your company have Java-based web applications that you would like to tie in with LinkedIn? Maybe you have J2EE web applications deployed in Apache Tomcat, JBoss, IBM WebSphere, WebLogic, or others? This can be done! You can use the open source Java library Linkedin-j to connect your Tomcat web application to LinkedIn. This library allows you to access LinkedIn from your private Java web application. And keep in mind Linkedin-j provides integration with Maven and the Spring Framework as well to fully utilize the power of your Java frameworks and MVC programming.

Supporting LinkedIn API’s

You may need assistance understanding how to integrate your web application with LinkedIn. It requires some knowledge of web services, and your in-house understanding of that may be lacking. But due to the fact that the LinkedIn integration is a free service available to the public, it is easy to hire or contract a third party to set this up for you.

If you are a Java development shop and you have many various web service technologies already in use that you are afraid will cause conflicts with the LinkedIn web services, it would be best to hire a third party (such as OpenLogic) to assist you in installing the Linkedin-j java library correctly. This would ensure you follow best practices and do not have any surprises waiting around the corner.

Remember: You Don’t Have To Buy the Whole Cow

LinkedIn’s API is quite extensive. In fact it’s downright overwhelming. It’s a good idea to remember that less is usually better. You do not want to pull in too much data if you don’t need it. So if you are a recruiter looking to pull in employee job descriptions into your system… don’t also pull in their connections unless you think you will actually need them.

One major benefit of using the open source libraries available is that they are a "lean and mean" front-end to an otherwise complicated programming interface. They do not carry a lot of the extra fat that the typical user won't be needing, and that means there is less that can go wrong for you.

Try to realize that the API itself is quite complex, but doing something simple like importing the number connections for a user is not a complex action. By only taking what you need, you make your product simpler and easier to support.

Know Your Limitations by Understanding LinkedIn Throttle Limits

Keep in mind they cannot just let you make an unlimited number of requests to their website. If that were the case your company might be able to single-handedly degrade performance for all the LinkedIn users. The LinkedIn Throttle Limits imposed on you when using their API. So they make it so you can only make a certain number of requests or transfer only a certain amount of data per day.

If your LinkedIn user is a developer, it will give your particular user 4x the amount of this limit to allow you to test your application without being hindered by the limit.

Keeping Up To Date

When accessing a third party web service such as LinkedIn, it’s always important to stay informed about changes to the API. You can stay updated on the LinkedIn API changes by subscribing to the LinkedIn blog. This will help you keep ahead of any changes you might need to make to keep the LinkedIn connection working.

But new features added to a well-developed programmers' interface stay stable with respect to old users. If they add crucial new web service methods, they will typically come in backwards-compatible with the older web service implementation. So don’t expect your LinkedIn code to break every year, but keep someone in your company up to date.



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 you've built your application with a bunch of open source frameworks and now you're ready to deploy to the cloud, but you haven't decided which cloud to use. First of all, you're not alone. Lots of developers leave deployment to the final step and don't really think too much about whose virtual servers will run the code. It turns out that not all virtual machines are created equally, however. Or, to be more precise, the context of those VM's matter. A lot. Especially when you consider that somebody (you?) has to support your app in a 24 x 7 production environment.

Let's take a look at the impact your choice of cloud has on your ability to support your open source-based applications.

Private vs. Public

This is a big one. It's hard to overstate the differences between private and public clouds when it comes to supporting applications. The primary difference is that, in the private cloud world, it's at least conceivable that you can access the physical hardware underlying your virtual machines for critical debugging purposes. The ability to monitor the host operating system, inspect the networking configuration, and run hardware diagnostics can be very helpful when troubleshooting a complex environment. In the public cloud, you must assume that all virtual machines run in the ether. The very concept of "hardware" does not exist. If you run into strange debugging situations, the best you can do is launch a number of new virtual machines and see if you can reproduce the problem consistently. With a large enough (statistically significant) sample size, you might be able to determine that a particular virtual machine is having underlying hardware issues - but don't count on it.

Another major difference between public and private clouds is how you manage storage. In the public cloud, you might have a number of choices such as instance storage (ephemeral), block storage (persistent), and a variety of storage services (e.g., relational database, key/value storage, blob storage). In a private cloud, your choices may be just as rich or significantly more limited. If you choose a storage service, either public or private, it will likely resemble a black box when it comes to debugging and troubleshooting.  You have to trust that your provider has top notch monitoring, management, back up, and fail over processes and that they don't fall down on occasion. If you don't want to be in a situation where your application is failing due to a managed storage service that's behaving badly, you'll need to run your own data storage solution.  Going with an open source package makes your data layer easier to debug, thanks to the ability to dig directly into the code if all else fails. Of course, you're likely to get better community and commercial support if you pick well-known packages like MySQL, PostgreSQL, CouchDB, HBase, Redis, memcached, Cassandra, MongoDB, and the like.

IaaS vs. PaaS

An IaaS (Infrastructure-as-a-Service) or Open PaaS (Platform-as-a-Service) provider gives you direct access to your virtual machines, which gives you unrestricted options for the use of open source. You're not limited to certain packages, versions, or configurations like you can be with "traditional" PaaS providers. In a "traditional" PaaS, the platform is usually a black box that supports a particular API or sometimes a pre-defined set of open source packages, versions, and configurations that mark the boundaries of that world.  If you want to "color outside the lines", you're probably out of luck. These restrictions can make it both easier and harder to support your applications. It's easier because you have fewer choices and therefore the PaaS provider can know how to work around existing issues. It's harder because you have to live with existing issues; you can't simply upgrade your way out of problems like buggy features and security holes.

Conclusion

Generally speaking, if you're the type of person (or organization) that:

• Doesn't want to be restricted to particular packages, versions, and configurations

• Wants to retain your right to apply patches or upgrade versions when faced with bugs or security holes

• Thinks it's valuable to have multiple support options (internal, community, and commercial)

Then you should:

• Use a private cloud or a highly reliable public cloud

• Prefer an IaaS or Open PaaS solution

• Use open source components

• Avoid using too many black box services (e.g., storage, queuing, messaging)

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
.