Open Source Technologies Unplugged

1. Open Source Technologies Unplugged IT Infrastructure Management Conference 2005 Dave Gynn Optaros Application Infrastructure Practice Lead dgynn@optaros.com

2. Agenda • Overview • What is Open Source Software (OSS) • Where does OSS come from • Why do people use OSS • Current landscape • Project landscape • Commoditization: Application Servers • High Collaboration: Application Frameworks • Over-served: Content Management Systems • Vendor landscape • IT process affected • 5 things you should be doing today to safely adopt OSS

3. What is Open Source Software (OSS)? • First and foremost, it is software • Just like you can buy from vendors • Just like you can build for yourself • Uses a licensing model that promotes collaboration • Grants rights to use • Grants rights to modify • Grants rights to redistribute • Not just “free” software • Zero licensing cost promotes adoption and collaboration but is not the purpose of OSS • Most commonly associated with Linux • Other well-known projects are the Apache web server, the Mozilla Firefox browser, and OpenOffice.org office suite

4. Where does OSS come from? • Enterprises are large contributors • Employ individual developers • Contribute code • Participate in consortia • Vendors are also deeply involved • Use OSS as a competitive weapon • Collaborate with OSS projects to lower costs • Offer OSS as an entry level product for other products • Participate in consortia to share development costs and build standards • There is a misconception that OSS software comes solely from hobbyists working in their spare time

5. Why do people use OSS? There is no single reason why you should use or get involved with OSS. Different groups are involved for different reasons. Benefits and risks are unique to your situation. • Developers • Carry skills from job to job; improving skills and learning best practices through peer review • Enterprises • Lower software license costs • Reduce vendor reliance; gain control by having more choices • Help set/influence direction • Reduce risk • Software vendors • Lower overall solution cost; strategic moves against competitors; loss leader; support more hardware • Hardware Vendors • Lower overall solution cost

6. Project Landscape Wherever motivational forces align, OSS projects are developing. There are a few patterns that are found. • Areas where products over-served the needs of the users • Areas of high commoditization often due to standards and maturity • Areas of high collaboration between users and developers Content Management CRM Over-served Application Frameworks Portals Collaboration Middleware/ESB Application Servers Commoditized Workflow Engines Databases Operating Systems

7. Commoditization: Application Servers • Why this area is rich for OSS • Industry standards exist for Application Servers so they are easy to swap out • Application vendors can reduce overall cost by certifying against OSS • Projects: • Java/J2EE: JBoss, JOnAS, Geronimo, Tomcat • LAMP Servers: Lightweight servers for Perl/Python/PHP • Other: Zope, Cocoon • Recent news: • IBM’s purchase of Gluecode which makes them the sponsors of several Geronimo developers • Three OSS servers were recently J2EE certified • Comparison to proprietary equivalents: • Less focus on monitoring/management applications • Less likely to suffer from featuritis

8. Over-served: Content Management Systems • Why this area is rich for OSS • Proprietary CMS vendors over-served the market for too long and pushed Enterprise suites at the expense of other solutions • Even the mid-range CMS vendors were constantly being acquired and absorbed • Projects: • Plone • Mambo • Drupal • Alfresco • Recent news: • Alfresco launched by a co-founder of Documentum • Comparison to proprietary equivalents: • Currently mostly competitive against workgroup solutions

9. Collaboration: Application Frameworks • Why this area is rich for OSS • Application Frameworks is an area where multiple enterprises have had experience building their own frameworks. Therefore enterprise developers are very capable of collaborating with the projects. • At the same time, proprietary, in-house frameworks are problematic because you can’t hire experienced developers and in-house frameworks stagnate over time • Projects: • Web Frameworks: Struts, Spring MVC, WebWork, Tapestry • Persistence: Hibernate, Castor, iBatis • Configuration: Spring IoC, Hivemind, PicoContainer • Recent news: • Recent decisions around Java specifications for JSF and EJBs have driven renewed interest in Java frameworks • New scripting frameworks from Ruby and Python are cross-pollinating with other languages • Comparison to proprietary equivalents: • Most proprietary equivalents have migrated to other areas • Many companies however still maintain internally developed frameworks

10. Vendor Landscape: Traditional Over time, Enterprises and Vendors have formed complex organizational structures and processes to coordinate the buying, selling, and usage of software Enterprise Vendor Purchasing Sales & Marketing RFP License Mgmt Engineering Vendor Mgmt Product Management Bug Report Vendor Bakeoffs Quality Assurance Release Management Consulting/ Training Hotfix Release Management Support Services IT Operations Support Software

11. Vendor Landscape: OSS Projects Most OSS projects do no match up to current functions and practices. So to adopt OSS, you need to modify your processes or find someone to fill the role. Enterprise OSS Project Purchasing License Mgmt Engineering Vendor Mgmt Bug Report Vendor Bakeoffs Release Management Release Management Support Services IT Operations Community Support Software

12. Vendor Landscape: New Options • The licensing model of OSS encourages a rich vendor ecosystem to grow up around the software and provide services • A number of companies now provide commercial offerings to match traditional software company services • Support and/or Maintenance - RedHat, Novell, OpenLogic, SpikeSource, SourceLabs, Covalent • Consulting - Optaros, (CapGemini, ThoughtWorks, Cignex) • Training - Virtuas • Books/Documentation - O'Reilly, SourceBeat, Pakt • Consortia - Avalanche, OpenXource, Assembla • Traditional-looking software companies are forming around open source projects • JBoss, JasperSoft, Funambol, SugarCRM, LogicBlaze • Large vendors offer traditional services for their OSS projects • IBM, HP, Sun, Novell

13. Best Practices for Getting Started Here are five things you can do today to start modifying your IT processes to safely enable the use of OSS • Establish an evaluation process and evaluation criteria • Develop a software acquisition process • Evaluate your support options • Begin testing against OSS projects • OSS-enable your developers and support engineers

14. Best Practices: Evaluation Process • What • You need to define an evaluation process and evaluation criteria • Why • The OSS distribution process can circumvent traditional purchasing department processes where key evaluation assessments are typically made. • Evaluating OSS is different. Vendor strength and code escrow are no longer concerns. Standards and community health are. • OSS projects don’t sell themselves, sales engineers won’t fly out to give demos, analyst firms write fewer reviews. Information is widely available but you need to be proactive. • OSS is licensed software and you need to understand your legal responsibilities • How • Look at OpenBRR.org - Defines a Business Readiness Rating and standard evaluation criteria you should consider • Create an Open Source Working Group to set guidelines and processes

15. Best Practices: Software Acquisition Process • What • You need to develop a software acquisition process • Why • Ad-hoc acquisition is not repeatable • OSS projects get fixed, patched, and updated frequently • OSS projects do not have account managers who will call you when new releases are available • If you plan to self-support, you will need the ability to build and patch the software • How • Many companies establish internal teams to build and release OSS project bundles or stacks • Multiple vendors provide update services

16. Best Practices: Evaluate Support Options • What • You need to determine who your support providers will be • Why • OSS unbundles software licensing and support • Proprietary software typically has only one support choice: the vendor • Depending on the OSS project, there might be multiple vendors with a range of support offerings available. Major projects have competing suppliers of enterprise grade support • Developing the capability to self-support may be a way to significantly reduce costs • How • Talk to your vendors to find out what support they offer • Experiment with self-support • Hire developers or administrators with OSS project experience

17. Best Practices: Begin testing against OSS projects • What • In addition to your existing test plans, you should begin testing your applications in a heterogeneous software environment when possible • Why • Testing against multiple platforms will reduce the cost of change downstream • The only cost is the time spent testing. And if your tests are automated, this should be reasonable. • Using OSS in your test environment gives your staff experience with OSS projects without introducing risk into your production environments • How • This will be application specific

18. Best Practices: OSS enable your engineers • What • Equip your development and support engineers and administrators with OSS tools and processes • Encourage OSS participation, within the guidelines of your employment policy and confidentiality guidelines • Why • Communities are open and welcome knowledgeable participation • Participating enables you to influence future features and direction • Your technical people need to be able to interact with OSS projects if they are going to collaborate and get support • Even casual participation in the community is good training for your engineers and will improve your OSS project evaluations and experience • How • Begin to use the tools that OSS developers use like CVS, Eclipse, JUnit • Use collaboration tools to enable sharing between internal projects • Potentially revisit your employment policy to make sure employees are appropriately encouraged to collaborate with OSS groups

19. More Information… Contact Dave Gynn, Optaros Application Infrastructure Practice Leaddgynn@optaros.com This work is licensed under a Creative Commons License You are free to: • copy, distribute, display, and perform the work • make derivative works • make commercial use of this work