Linux has proven that the open source model works — it addresses two of the biggest challenges for IT professionals: the high cost of infrastructure software and the limitations a closed stack imposes on the enterprise. Open source is particularly appealing for the following reasons:
- Cost savings — Users do not pay a license fee to adopt open source software nor do they pay for updates, eliminating the large upfront cost typically associated with infrastructure development and significantly reducing the total cost of the project.
- Vendor neutrality — Open source software is developed and owned by the community. Users of the project are not locked in to a vendor’s platform and are not forced to buy proprietary modules or adopt prerequisite technology.
- Access to source code — By definition, open source projects make the source code available. This allows enterprises to inspect the code for safety, edit the code to add unique features, and not be at the mercy of a vendor.
- Innovation — With a large community that includes end users contributing to the project, open source software has proven itself to be a practical vehicle for the latest technological advancements.
Using Linux is one thing — it is a widely used and contained piece of software — but using open source software higher up the stack can be unnerving. Unlike the operating system, middleware components are often integrated with other components and there are many more options. It is like going to a do-it-yourself home store as opposed to hiring an experienced contractor: Nailing trim and blue board into a 2×4 is not very hard, but consider what happened to the three little pigs. Exposing the unknowns ensures that architects work with the right materials.
Challenge: restrictive licensing
Solution: choose a license that aligns with project requirements, and have a lawyer closely review it
Because enterprise software is often integrated with other components or embedded into larger applications, details in the license agreement are key. The wrong license restricts the use of the software and potentially leaves the organization liable for misuse of intellectual property. A lawyer needs to analyze the license agreement.
This is not a new concept — legal departments have always reviewed licenses. The difference is that with commercial software it is taken for granted that the license will at least closely meet the needs of the acquirer.
The Apache license, for example, is very popular for infrastructure software adoption because infrastructure software is often customized and connected with or embedded in other technologies. The Apache license is permissive in nature and is chosen frequently by enterprise integration developer as it allows developers to freely modify and redistribute the code.
Challenge: rogue developers
Solution: establish clear governance rules for using open source software
It is one thing for the legal department to fully understand the nuances of one license versus another, but it is another for every developer to have that same depth of understanding and appreciation of the consequences. With open source software so easily available, it is possible that a well-meaning developer would efficiently and heroically solve a technical problem by introducing outside code.
The first step to preventing this potential liability is to put governance rules and procedures in place, and make sure all team members are trained. Guidelines should include notification, legal, registration and accounting processes. There are products available (some open source!) that audit and manage open source usage in the enterprise.
Challenge: constantly changing code base of many projects
Solution: build and deploy on a stable release
Enterprise IT department require that the software they use comes in discrete, stable releases so managers can be sure that all developers are working off of the same set of bits, support the software, and track and fix issues.
Open source projects typically take contributions on a continuous basis to get new features and fixes to users quickly. While this is good for promoting innovation and progress, it is a challenge for IT managers.
One approach to overcome this challenge is to take a stable and consistent snapshot of the project and create a packaged code drop. This snapshot then goes through a standard release process as shown below. Any patches or enhancements generated during the QA cycle is contributed back to project. This approach — practiced by several enterprise software vendors — makes a clear distinction between the project and the product, but keeps the two in parallel. Such packages are often available from vendors.
Challenge: Lack of qualities of service (QoS)
Solution: look for a release team with enterprise experience
IT departments — more than most other software consumers — have high standards for robustness, performance, availability, security and other qualities of service (QoS). Although popular open source projects are typically robust due to the number of users working with and vetting the code, enterprise organizations often require more.
A team with enterprise experience injects the extra QoS that an enterprise needs into the solution. They perform extensive quality assurance tests that go beyond the tests commonly performed at the foundation, including tests for typical enterprise configurations with long running processes, multiple clients, and multiple machines. An enterprise release cycle may also certify the product on a broad range of platforms and test for backwards compatibility.
Review QA tests before bringing open source software in-house.
Challenge: limited professional services
Solution: get support from the people who wrote the code
The most important concern for IT departments when considering software of any type is how they will get quality support. When deploying mission-critical systems, development teams need 24×7, experienced support as well as training and consulting during the development phase. Equally important is getting professional services early in the software development lifecycle to ensure applications are architected properly and efficiently to avoid unexpected problems at deployment.
Many companies offer support for products they did not build, but this may not be adequate for more resolving more complex issues and guaranteeing fixes make it back into the open source project. Questions go deep and problems have to be resolved quickly. For IT, training, consulting and support must come from the people with intimate knowledge of the code as well as the ability to commit updates and enhancements back into the code base. If changes are not submitted back to the original project, the enterprise risks being out of sync with the open source community and is setting itself up for long term problems.
The challenges of open source can be addressed.
IT is not simple, but it never has been. Open source offers new options and challenges to architects, but the basics remain the same: Understand what you are bringing in-house and work with experienced people. These have always been key attributes — they are just often taken for granted when working with a reputable vendor.
Specifically, look for the following:
- License associated with open source project
- Governance rules and procedures
- Stability and productized releases
- Availability of qualities of service
- Availability and quality of professional services
With these criteria met, open source software can be deployed safely into an enterprise environment and organizations can soon benefit from the cost savings and transparency that comes with community-owned development.
Deborah Moynihan is director of open source programs at Progress Software.
Loading ...
I think Microsoft Office SharePoint Server 2007 is something you definitely want to look at. We specialise in this. There is more information on this at http://www.nsynergy.com/Products/SharePoint/Pages/default.aspx or please mail to [email protected].