15 Myths of Open Sourcing Software
Due mostly to its differentiated style of development, Open Source lends itself to a lot of doubts, queries and myths on the minds of people introduced to the concept. Most often than not, these myths tend to be the reason why Open Source is not understood well. Of course, the myths remain myths for those Open Source projects that strictly and religiously follow the tenets and principles of Open Source Software development. In those cases where these are not followed, many of the myths sadly turn into reality. Listed below are 15 myths that we came across while doing the study and clarifications for the same.
1) Community consists of all developers – People generally tend to associate Open Source communities to a group of hardcore developers working on the next big thing. While this is a perception that has undergone a sea of change, it has not been addressed fully. Open source communities are not exclusively developers. There are a many communities where the contributors are general users of the software and many of them have nothing to do with writing code. But these contributors are extremely useful all the same. They help in identifying, reviewing and clarifying requirements. Some of them offer to be alpha or beta testers of the product. In many cases they help in driving the community to develop better and more versatile applications. They represent the face of the customer and are instrumental in lending a direction to the development of software. In reality, it's generally very, very difficult to fix real bugs in anything but the most trivial Open Source software. Most of the time, what really happens is that you tell the actual programmer about the problem and wait and see if he/she fixes it. Most people do not participate in the development - even for Linux itself, most of the development is done by a very small number of people
2) Open Source development gives complete access to code – One of the bones of contention for many companies and developers is that Open Source Software is basically what it says it is – Open Source. Companies and individuals fear that if the code is open, then they are vulnerable to all sorts of threats like security, theft etc. But what they don’t realize is that not all Open Source companies have a complete set of open files. There are business models that allow companies to open some of the code for peer review and development and at the same time have other enterprise versions to be closed and restricted. While the free version of the software can be open source and subject to change and development by the community members, the company that develop the enterprise version can keep the code closed and away from scrutiny. While this might be a bit away from the central idea of Open Source, it is just another way of monetizing software development.
3) Data and source security is compromised – Open Source Software certainly does have the potential to be more secure than its closed source counterpart. But simply being open source is no guarantee of security. For those new to security, the idea that the best way to keep something safe is to hide it. This idea is known by experts as security through obscurity, and is generally discredited. Probably the greatest reason that security through obscurity doesn’t work when it comes to code is that, if security is breached, you have no way of knowing what has happened. By contrast, if the code is open to anyone to read, then the odds are that the insecure elements will be detected and corrected. Since what you want to protect is the information, not the technique used to protect it, according to most security experts, OSS tends to be more secure than proprietary software. Two main claims made by proprietary vendors: (1) that release of code benefits attackers more than anyone else because a lot of hostile eyes can also look at open-source code, and that (2) a few expert eyes are better than several random ones. Of course, because bug detection is public, detractors can say that OSS is buggier than proprietary software. However, because we have no way of knowing how many bugs in proprietary software go unfixed or unnoticed, the number of reported bugs is not a reliable measure of security. Whitfield Diffie, the co-inventor of public-key cryptography and chief security officer and senior staff engineer at Sun Microsystems, notes “It's simply unrealistic to depend on secrecy for security in computer software. You may be able to keep the exact workings of the program out of general circulation, but can you prevent the code from being reverse-engineered by serious opponents? Probably not.” Open source software projects can be more secure than closed source projects. However, the very things that can make open source programs secure -- the availability of the source code, and the fact that large numbers of users are available to look for and fix security holes can also lull people into a false sense of security
4) Open Source Software development exploits people – The Open Source development community consists of a group of people who come together to develop better quality software. This community could consist of developers, testers and end users of the software. Most often than not there is no monetary compensation to the work done and people volunteer to work for free. This leads to a lot of proprietary companies and competitors of the Open Source Company to level charges of exploitation of the volunteers to produce software for the company to profit on. But the very fact that community members volunteer to be part of the process negates this argument. Though there might not be a direct monetary compensation to the contributors, there are other benefits that keep the community together. Many times the developers will find other ways to monetize the work they do. They could take the code they worked on and use it in other areas that provide them with monetary benefits. Many of the communities work by motivating and encouraging its contributors by sending them gifts and freebees like memberships and free access to road shows, conferences etc. Apart from this, they are also compensated in terms of the recognition they get among their peer group for the work that they do. The basic law that says that nothing in this world comes for free is true in the case of Open Source Software development too. The key contributors to most open source projects today are a mix of university researchers, developers internal to companies who use that particular open source package in their work, independent consultants who profit from the increased visibility their participation brings them, and developers sponsored by companies who have identified a clear revenue stream associated with that project.
5) Open Source Software is better than proprietary closed software – There is a growing feeling that tinkering with Open Source Software code by community members leads to better software. This is not necessarily true. If the project that the team is working on is not controlled and managed properly, then the software that is developed need not be better than a proprietary product that has been executed properly. There have been many instances where mission of the community, documentation on project, code collaboration etc is not communicated properly to the members and this leads to the project getting executed in an inferior way. This also leads to a lot of dissonance among the community members and ultimately the demise of the community. This leads to the fact that Open Source Software projects are not always a success. Software experts and researchers who are not convinced by open source’s ability to produce quality systems identify the unclear process, the late defect discovery and the lack of any empirical evidence as the most important problems. While many Open Source projects are superior to their close-source counterparts, it's also true to say that a closed-source approach to a problem can have some benefits. Some of these benefits include having a more focused direction for the team, given the fact that there is just one manager and team leader, firmer schedules and deadlines, tighter management, profit incentives, salaries and bonus motivations. While this can also be true for open source projects, the "design by committee" that goes on with community projects often results in a more bloated and less focused product that tries to be all things to all people. Sometimes a simple lack of funds on the part of the developer can hamper the development.
6) More is better – Open Source Software development opens up the opportunity for contributors to incubate and develop a plethora of applications and features that can be add-ons to the original software. This is something that Open Source Software development does very well. Most of the time these features tend ot be personal pain points of the developer and might not really be of use to many others. The 80/20 rule becomes very relevant here, that only 20% of features are used by 80% of the users. While this might seem like a good thing at first, it could also be argued that eventually trying to reduce the choice somewhat for the end-user would also be beneficial. Reducing the choices would reduce the bloat and clutter that tends to overtake the project. Choice is good, but a reasonable pre-selection of options is better for the end user. Most users want their applications to be simple, straightforward and light.
7) Open Source Software development leads to interoperability issues – The Open Solutions Alliance (OSA), a nonprofit, vendor-neutral consortium dedicated to driving interoperability and adoption of comprehensive open solutions, after meeting with more than 100 customers in five cities throughout the United States and Europe, found that interoperability between open solutions tops the list of requirements among customers and channel partners who are deploying these solutions. Interoperability is a challenge among both large and small organizations. Key issues with small organizations include single sign-on and authorization, data integration and synchronization, UI and portal integration, and content management integration. In addition to these, larger enterprises also had
business process integration, production management, and legacy/proprietary integration as key issues. Across the board, non-technical interoperability issues, such as how to support and manage integrated solutions being sourced from multiple vendors are seen as pain points. Interoperability between Open Source and proprietary software is often a catch22 situation. It is simply not possible to isolate both. There is not software that is 100% free of either Open Source or Closed Source. A 2006 Forrester study showed 75% of large businesses surveyed were either using or planning to use open source software up from 60% the year before. There’s also Gartner’s prediction of 90% open source adoption in enterprise software development businesses by 2012. Interoperability used to be a major problem during the early days of Open Source Software development. But the Internet has provided a forum for thriving virtual software development community and they have been working diligently to solve interoperability issues through the consensus specification of open interfaces and encoding. Since these specifications are new to the industry, open source products are in a position to compete on an even playing field with commercial alternatives.
8) Open Source Software throws Intellectual Property out of the window – A license defines the rights and obligations that a licensor grants to a licensee. Open Source licenses grant licensees the right to copy, modify and redistribute source code (or content). These licenses may also impose obligations. What the author/licensor is granting when they grant a license to copy, modify and redistribute their work is the right to use the author’s copyrights. The author still retains ownership of those copyrights; the licensee simply is allowed to use those rights, as granted in the license, so long as they maintain the obligations of the license. The proliferation of open source licenses is one of the few negative aspects of the open source movement because it is often difficult to understand the legal implications of the differences between licenses. An important legal milestone for the open source was passed in 2008, when the US federal appeals court ruled that Open Source licenses definitely do set legally binding conditions on the use of copyrighted work, and they are therefore enforceable under existing copyright law. As a result, if end-users do violate the licensing conditions, their license disappears, meaning they are infringing copyright. The typical open source project is a grass-roots effort that contains contributions from many people. This method of development can be worrisome from an intellectual property standpoint because it creates multiple opportunities for contributors to introduce infringing code and makes it almost impossible to audit the entire code base. The risks of this development process are largely borne by the licensees. It’s a legal minefield. But many companies do clean implementations for their enterprise editions and make sure that none of the IPs is violated. As for the Open Source versions, they make sure that the contributor is duly referenced so that the violations does not reflect on the parent company. In many cases the violations are not serious enough to warrant a legal penalty, but in case it is, the licensing model of Open Source is such that the contributor is protected to a certain extent. Also, the community generally comes together to help out any such violations. It's true that software that incorporates other GPL-based software must be provided under the same terms--this is its so-called "viral" characteristic. However, even GPL'd software can be used freely. Open Source is about internet-enabled collaboration. Licenses play a role only to the extent that they set out rules designed to make sure that companies don't undermine the playing field.
9) Creating and maintaining a community is easy – Contrary to popular belief, creating and maintaining a community is not an easy task. Communities are created when a group of likeminded individuals get together to achieve a common goal such as commonly contributing to a project, improving the code base or develop faster and better code. What community members look for is recognition for the work they do and a sense of belonging to a group that is making a difference. Thus, maintaining the motivation levels of the community while pleasing the individual members are an art in itself that community managers have to perfect. Most of the time community managers spend close to 75% of their time on resolving issues and clarifying questions. Community managers have to make sure that they preserve the culture of the community as it grows. They also need to make sure that they weed out elements that are not contributing to the growth of the community. Communication is the key among other things.
10) Cannot profit from open source – The underlying argument here is that Open Source Software is not all free. It is true that open source software will reduce the amount of money that is spent on existing commercial software. The Internet, a disruptive technology based on open standards and open source software, has created huge new markets away from the software. And there are many different ways to profit from Open Source Software development. As explained earlier, there are many different ways to monetize the efforts put into Open Source development some of which are Services, Loss-Leader markets creation, Dual licensing, proprietary up selling etc. And there are many companies who are thriving on a variety of these models while remaining Open Source companies. The benefits of open source are exactly the same as the benefits of any other free market: competition between multiple suppliers results in lower prices, more innovation, and specialization to meet the needs of new niches. Open source isn't just something that matters to computer software vendors. It's a way to provide better services to your internal users and to your customers, by applying techniques of networked collaboration.
11) It is easy to setup communities anywhere in the world – It is expected that human beings being social by nature would be able to work together if goals are set properly. But it is found that this is seldom true. In the case of Open Source Software, there is a definite difficulty that s faced when trying to setup communities. In most cases the issue is more to do with culture and maturity than anything else. For instance in Asian countries where the culture of freely giving to society is lacking communitite do not seem to be able to progress beyond a few dedicated members. In these countries, the idea of a company gaining freely from their hard work is something that cannot be accepted. Likewise many of these countries do not have a robust higher education system that fosters Open Source development. This leads to a lot of engineers who are not corporate ready. A lot of post college training needs to be imparted to these students to come up to speed in doing work.
12) Open source software is cheaper than closed proprietary software – The often-repeated line is that companies that cant afford commercial software buy Open Source Software. But studies have shown that this is seldom the case. Many a times Open Source Software costs just as much to buy as do commercial closed source software. This is because most of the time the enterprise version of the Open Source Software would be developed in-house and thus would be expensive to produce even though the development is overseen using the Open Source development methodology. If this is the case, then why are businesses buying Open Source Software? There are multiple reasons: 1) Open Source Software development model is such that bugs in the system are few in number. This is precisely the reason why over a period of time the cost of maintaining Open Source Software is low. 2) Due to the collaborative mode of software development, the number of critical flaws in the software is few, which adds to further savings to the customer in terms of security and downtime. 3) Also since the Open Source engagements start from design phase itself, the cost of up gradation and adding features would be low since this would have been factored in during design stage itself if a good Open Source vendor is doing the development.
13) Open Source Software companies do not support software once sold – There are many companies proving products and services in the Open Source space and virtually all of them provide after sales service to their clients. The difference is between the free versions available and the enterprise solutions. Most often than not, service for the free trial versions are limited and where available will be restricted to communities fixing the bugs, email support or on a do-it-yourself mode. But there are the standard and non-standard ways of service level agreements for enterprise solutions and paid solutions. These are not very different from proprietary closed source SLAs. For instance, all the standard SLAs like 24X7 support, 12X5 support, patch releases, severity level support, maintenance, backups, upgrades, performance improvements etc are provided. Apart from this there are 3rd party companies supporting Open Source Software which happens to be the non-standard method of supporting the code base.
14) Open Source = Open Standards – Open Source is not synonymous to Open Standards, though many times they are confused for each other. Open Source is merely a development model. It does not mean it incorporates the best practices like Open Standards. While open source development encourages the use of open standards and protocols for interoperability, it does not guarantee software development best practices. It doesn't guarantee interoperability or security, although it sure makes them easier to implement.
15) Open source carries a greater risk of abandonment/obsolescence – Open Source Software is developed by a group of passionate individuals who volunteer to work on the project because it is important to them in some way or the other. This leads us to believe that if the interest cannot be maintained, then the project risks loosing steam and might be abandoned. In reality, maintenance/evolution of the software is distributed rather than centralized, engaging the diverse skills and talents of many contributors. Peer review reinforces the need to follow accepted standards and practices. This means that even if some people or even the founder leaves the community, there will be a stream of interested people who might feel the importance and need to be associated with the project. Of course, this also means that the documentation in the project needs to be done diligently so that others can carry on with the work that has been put in by previous contributors. Obsolesce is rarely and issue since Open Source development takes place on a continual and ongoing basis with contributors involving in the project to make a difference and develop something latest and useful.
Posts
No comments:
Post a Comment