FAQs

Who's Accountable?

This is a common concern for organizations investigating open-source solutions. When purchasing a commercial product, the vendor commonly offers support as part of the purchase price. If the product fails in some way, there's someone to contact, and an entity to be held accountable for the integrity of the software.

There are several avenues to explore to alleviate these concerns. Some open-source organizations run a commercial, for-profit company that offers commercial and enterprise grade support that is on-par (or far exceeds that of most commercial software companies) for the open-source products they distribute. Alternatively, firms like Fenix who provide professional services and integrations of open-source software offer a warranty for the solutions they produce for their client in addition to on-going support packages. Whichever avenue your organization chooses, rest assured that open-source does not equal lack of accountability.

What About Security?

Security is of the utmost importance to the open-source community. Given that the contributors of these open-source products use them themselves, and may rely on them as a critical piece of their own businesses, security is aggressively protected. The agility of the open-source community often means that if or when a security flaw is discovered, it is addressed quickly - with a turnaround time that most commercial solutions cannot come close to matching.

I'm Concerned About Quality

 There is the old adage "you get what you pay for". Many people ask themselves, "if it's free, how could it possibly be as good as a commercial solution that costs thousands?". In order to answer these questions, one must look at what makes an open-source project successful.

  1. Community - an open-source project thrives on the contribution of developers who believe in the product and stake their reputations and careers on the quality of that product. A project that may be merely "good" with three developers at the helm may become "great" when opened up to hundreds if not thousands of professionals.
  2. Competition - like in any industry, competition drives innovation. It may be unintuitive to consider the effect of competition on projects that aren't directly financially motivated. However, any developer involved in an open-source project will tell you that innovation and notoriety achieved by other projects motivates them to improve their own software.
  3. Collaboration - just as often as competition will fuel innovation and quality, the strength a project will gain through collaboration and knowledge sharing is just as important. Open-source software thrives in a community culture of collaboration and the wealth of knowledge shared and consumed by developers world-wide. Obviously it would be disingenuous to imply that open-source is always better than closed-source, as that is certainly not the case. Nor is it the intention to imply that all open-source software is of high-quality. The main point to be taken away is that open-source software has an equal opportunity to produce world-class quality software as its commercial counterparts.

If I'm not paying a monthly/annual cost - how is the solution being supported?

The way this works is through perpetual support of the very users who use the tool in the first place.  So although a user might happily download the software without ever giving feedback, there may be a day when this same user might add something useful or enhance an existing feature and share it with the community.  It's the last part - sharing with the community - that is the key to the operation.  The community benefits from working code, and thus it is in every user's best interest to help out when they can.

Of course, that's not to say you have a programmer out in the wild world, ready to help you with your specific enquiry at every turn.  Sometimes you will need to wait a significant amount of time for updates to a codebase, but the point is that in the absolute worst case scenario you have the option to open the hood and fix it yourself or ask an expert to assist.  In fact, firms like Fenix offer support packages for just such occasions. 

Who does it belong to?

A good deal of open source software packages are distributed with licenses that allow you to freely modify and re-distribute your code.  Common licenses for frameworks include GNU General Public License and MIT License.  This question entirely depends on which software package you are using as each one may involve a different license.

In general, though, the code you have on your server won't belong to anybody in particular, as often times it was developed through the collaboration of many people.

Crippled open source solutions .... "when open source isn't really open source"

"Buyer beware" - there are times when projects will lure in users with the promise of open-source software but are actually offering a way to monetize on the framework with add-ons that give you the "real" functionality. These projects go against the philosophy behind community built software, as there is little to no incentive for people to participate in making the product better. 

Luckily, the most popular frameworks end up being purely open source and leave these "crippled open source" projects in the dust.  Again the agility of community involvement will help to propel a piece of software to greater heights.

If I build on, or modify an open source product for my organization, will I be forced to release the code?

This will depends entirely on the open source license the software is released under. The most commonly used licenses like MIT, GPL or OSL grant the licensee the ability to download, modify and use the software without any requirement that the subsequently modified or combined code be released.

However, in the event you choose to distribute the software produced on or with an open source product, these licenses stipulate that the software must be released under the same (or a compatible) license.

Basically, what it all boils down to is you cannot take a piece of open source software, modify or extend it, and then convert it into a commercially distrubted product. For the vast majority of organizations, these licenses will not limit their ability to use the software as they see fit, nor will it force an organization to distribute any code written specifically for them.