Saturday, 6 July 2013

10 FUDs on Open Source Softwares

Open source softwares play a key role in reducing the effort required for any software application. Many of the cross cutting concerns in software development will be addressed by open source softwares and the developers can just concentrate on implementing the business functionality alone. But, when we think of using an open source software as the critical component of the application (such as core framework or the server runtime), both managers and architects may have many FUDs (Fear, Uncertainty and Doubt). This write up tries to analyse some of those FUDs. Please note that when I say open source software (OSS), I generally mean a stable software with good community involvement. (Eg. Apache Tomcat)

FUD 1: Open Source Softwares will have lot of Bugs
I will say that any software will have bugs initially. The important thing is to unearth them at the early stage and fix them.
Most of the popular OSS will be downloaded and used by hundreds of people. The good thing is that they will not be using it just for the purpose of testing. They will be using it in their real business scenarios. All the major bugs will be reported during this time and most of them get fixed as early as possible depending on the criticality. Another point to mention here is that, people will start using the software even before the final release is out. So, by the time it get released, most of the bugs would have been fixed.
In short an OSS will be tested by hundreds of testers in the real business scenario. And their commitment will be more, when compared to a few salaried testers in a company, because they are the real users of the software and it is very important for them to ensure that there is no major issue in the software.

FUD 2: If there is an issue who is going to support me
Almost all the commercial softwares have an option to opt for professional support. In case of open source software, there is always a concern on who will provide support when something goes wrong.
There are multiple points to be noted here
a. Forums provide support
All the popular OSS have very active forums. 99% of our issues would have been already faced by someone else before. So we will get the solutions directly from the forum. If it is not already addressed, we can post our issue, so that someone else could respond to that.
One problem is that, there is no SLA associated with these forums and there is no guarantee that we will get a response. There are some guidelines to be followed while posting in such forums.
1. Be specific. Focus on our real technical issue and explain it in detail without mixing it with our business requirements.
2. Don't just say that "I have this issue. Please help me to solve this". Explain the options we have tried and their results.
3. Don't just be a leecher. Be a contributor. Remember that community is all about give and take. Contribute to the forum wherever possible. If we are active contributors, we have better chance to get response for our queries. Being active in the community, we may even build good rapport with the key developers of the  OSS.
Forum based support is very less for most of the commercial softwares, as the number of users will be less and there is no active community.

b. Easy to help ourselves with debugging
Being open source, we have the full source code of the software available with us and we can easily debug our issues on our own. We can look into the internals of the software and see how the inputs are getting processed and what is the root cause of the issue.

c. Commercial support options are available for OSS
If you still want the peace of mind of a commercial support, you have that option for most of the OSS. Many vendors provide commercial support for OSS.

FUD 3: Whom will I blame if something goes wrong
Proprietary software from big vendors are often used as a protection mechanism in front of customers. Generally we try to say that it is an issue with X software and we are in touch with Y company. This will help us in keeping the customer quiet for a few days, especially if Y is an industry giant. But what is the reality here? After all, our customers are valuable to us and it is not fair to cheat them.
In my experience, it is very difficult to add value from a commercial support for a proprietary software. We, application developers, sit at one side without having the full picture of the proprietary software and the vendors sits at the other side without having the full picture of our application. Support providers can mostly give just some hints, on which we need to work based on our experience and resolve the issue.

On the other hand, if it is an opensource software we may not get the protection I mentioned initially. But we will have the full picture of both our application and the open source software, and thus we will be in a better position to resolve the issue in quick time, for the benefit our customer.

FUD 4: OSS may perform poorly when compared with commercial counter parts
Most of the proprietary softwares are developed after doing a great amount of research with proper planning and design. OSS normally evolve over time based on the need. So there is a high chance for proprietary software to perform better than OSS.
There is also another side for this. Normally proprietary software will  be overloaded with lot of features which can provide them marketing benefit and this can make the software heavy. On the other hand, OSS may be lean and lightweight with just enough functionality which is most relevant.
Conclusion is that, only by critically evaluating the software we can make a judgement on performance.

FUD 5: It is very difficult to develop, manage and monitor as I don't have a good console or IDE.
This is a point where I generally tend to agree with the FUD.
Proprietary software will normally have good user interfaces, because that is a key element for them to market the software. But open source software will mostly concentrate on the core engine. We may need to do some less user friendly operations like editing some configuration files. Monitoring the software also can involve some manual technical activity. For many proprietary softwares, all these could be possible directly with console/IDE.

FUD 6: My customer may not like the use of OSS
When we are doing a services project for customers, this can often become an issue. There are organisations whose policies will not permit the use of OSS. And CIOs of some organisation may not have trust in OSS. In the second scenario we can try to convince them on the merits, with very little chance of success. This may be a case because of which we may need to avoid OSS.
But when we are selling products, things could be different. It is our product which we are selling and it is we who provides guarantee for the product. Here the customer need not worry much on what we are using within our software. After all, most of the commercial softwares, especially in Java world, use open source libraries within that.

FUD 7: If I need an extra feature, what will I do
Getting a new feature implemented in any software is a challenge no matter whether the software is open source or proprietary. Let us see what are the options available in both cases.

Enhancement in proprietary software:  Most of the proprietary softwares will have a standard roadmap. It will be very difficult to get a new feature implemented, if it is not available in the roadmap. Depending on the merit of the requirement, its complexity and our relationship with the vendor, we may be able to manage some of the requirement. But we cannot expect a major enhancement to be done just for us. Here, if the vendor is not doing the enhancement, we don't have any other choice as it is a proprietary software.

Enhancement in opensource software: In case of open source software, we have multiple options.
1. If it is a small enhancement needed by many, we may get it done by the community quickly. Otherwise we may need to wait.
2. Since it is an open source software, we always have the flexibility to update the source code for our need. This can be done in two ways.
a. Branch out from the original source, make our enhancement and check-in to the community. There are  multiple advantages in doing this. There is a high chance for our code to get merged with the main stream of the OSS, if it is really worth. If this happens, we don't need to worry about the maintenance of that source code anymore. If the feature is attractive to others, they will also start contributing to it and we will get benefited with it. This will also help us in getting better acceptance in the community.
b. Take the source code and enhance it without contributing back to the community. By doing this way, we can keep our intellectual property with us. But we don't get the advantages mentioned in the previous point and maintenance of this library will be our headache from now on. There are organisations who don't have a proper policy for contributing back to the community. So this may be the only option available in such cases.

Here we can see that OSS has the flexibility of multiple options in getting an enhancement done. OSS is much better placed when compared with proprietary software in this context.

FUD 8: Will they stop development of this software
This risk is there for both OSS and proprietary softwares. We have seen many softwares getting discontinued in the past in both cases. What we can do once this happens?
In case of OSS, we have the full source code available with us and we can maintain it as necessary. And, if it is a widely used software, there is always a chance for some other community to take it up. Mostly, many users of the OSS take initiative and start a co-development. We can also be part of that and have a say on the future of that software.
In case of proprietary software, we don't have choices as there is no control or visibility on the source code.
This means proprietary software has higher risk than OSS.

FUD 9: Will they change the license and make it commercial
We have already seen many open source softwares change the license to become proprietary.
Few points to be noted here
  • There is very less chance for a community driven software to become proprietary. 
  • Most of the open source licenses are perpetual and even if the software becomes proprietary, it doesn't affect the license we already obtained. We can still continue to use the open version we obtained and we have every right to maintain it. 
  • Just like I have mentioned in the previous FUD, a group may fork the source from the available open version, and will start to maintain it, if it is a popular software.

FUD 10: Will I fall into some legal troubles if I use OSS
There are many cases where organisations fall into legal trouble because of the improper use of OSS. It could be a software which requires commercial license for production deployment or it could be a GPL software which is used in proprietary product. It is very important to read the license clauses carefully and ensure proper compliance with it. Once we confirm that we are fine with all the license clauses, we are safe to use it.

Choosing the right open source software
Choosing the right open source software is very important. We need to consider following points while we choose it.

  • Does the software satisfy our key requirements?
  • Is the software well maintained?
  • Does it have a good roadmap?
  • Is there a reliable community behind the software?
  • What is the general opinion about the software?
  • Is the software stable?
  • Does it meet the required performance needs?
  • Does it have a safe license?

If we choose the right software considering all these facts, you don't need to worry about the above mentioned FUDs.

Closing Note
Most of the FUDs on open source software are mere FUDs, not facts. Whether a software is open source or proprietary is not the parameter to judge it. What matters is the value added by the software in terms of features, stability, usability, performance, popularity etc. All these parameters need to be thoroughly evaluated before choosing a software. And, if you get multiple softwares which suits your need.,  my recommendation is to go with open source software, because of the flexibility and control it offers.

13 comments:

  1. This blog post was so informative :-)

    ReplyDelete
  2. Good article.....good work mate....

    ReplyDelete
  3. I like your list because there isn't a point about cost and TCO. I hate those who put the license price as main reason for OSS.

    ReplyDelete
    Replies
    1. Spot on, Diego.
      We need to primarily consider the value add done by any software. Not the price associated with it.

      Delete
  4. Lack of training, support and documentation is my primary problem. There is no guarantee of bug fixes. Most Open Source Software lacks a commercial support option.

    It is really naive to tout the open source forums where there is no guarantee of a response (or even knowing if the response makes sense).

    Open source does make sense in many circumstances but it is hardly a panacea.

    ReplyDelete
    Replies
    1. Hi,
      Choosing the right OSS is very important. If you look at Spring and most of the Apache and JBoss projects, you have good documentation, active community involvement and professional support option.
      More importantly, when you are in open source, you should try to help yourselves by analyzing on your own. The entire codebase is at your disposal.
      Regards,
      John

      Delete
  5. The biggest FUD is the fear of trying and being convinced that Open source means lower quality since no one gets paid and of course buggy.

    ReplyDelete
    Replies
    1. Yes. As I said already, we need to critically evaluate and choose the right software, no matter it is open source or proprietary.

      Delete
    2. A good programmer writes quality code, whether a paycheck is involved or not. Conversely, Shoddy programmers will introduce bad code into proprietary software, every time they get the chance.

      So what can you do? Design & code reviews are perhaps the best way to spot problems early on. I could make the case that OSS gets vastly more design & code review (as well as testing) over proprietary software.

      In my experience, I rarely see code reviews done properly (if at all). Software is in no way guaranteed to be well-written simply because it's proprietary.

      Delete