OPEN SOURCE AND FREEWARE SUITABLE FOR GOVERNMENT Samuel A. Litt Deputy Chief Technology Officer City of New York Department of Information Technology and Telecommunications OPEN SOURCE AND FREEWARE SUITABLE FOR GOVERNMENT NYC Technology Forum, October 15, 2009

Agenda Freeware vs. Open Source Benefits and Dangers of Open Source Technology Parameters Strategies for Deployment NYC DoITT - GovTech 2009

Freeware vs. Open Source No acquisition cost, bring your own support, code may not be publicly available Open Source Community produced and supported, code is editable by anyone Open Source-Based Typically low or no acquisition cost, but support and service plans must be purchased Open source: regulated and supported by non-profit foundations. Open source-based: Bullet 1: corporation uses open source code in their licensed product, gives code and credit to community, sells product as proprietary software with open source code within it. Bullet 2: corporation hands out open source software they have modified(and provides those mods to community). The corporation then charges users for support and service if they want it. NYC DoITT - GovTech 2009

Benefits of Open Source Category Potential Benefit Example Cost Free or Low Cost Licenses Non-profit source code development Service and Support Lower support costs for open source-based solutions Customization Free to Modify Anyone can improve Modularization Easily adaptable Development Community Decentralized Yet Collaborative Ideas are incorporated based on merit Global effort Sponsors Funding for Advancement Open source-based efforts support new development Competition Alternate Sources of Solutions and Services Competition can reduce prices, increase innovation Free PDF utilities may be better than commercial offerings NYC DoITT - GovTech 2009

Dangers of Open Source Category Potential Danger Example Enterprise Appropriateness Compatibility with Legacy Standards Different formats change functionality Existing Skill Sets May not leverage user expertise IT Department may require retraining for new systems Existing Infrastructure Integrating back-end management tools can be difficult Middleware Encumbered Propriety Software Essential systems may not work with open source solutions Service and Support Quality of Support Support may be limited to internet forums An SLA may be required Security Code Available to All Anyone can view code and look for weaknesses Middleware: VMware, Single Sign On, Enterprise Vault, etc. NYC DoITT - GovTech 2009

Technology Parameters Security Highly secure and stable IT platform essential to working with confidential information Support Enterprise-class support necessary to preserve continuity of operations Cost-effectiveness Existing infrastructure must integrate with open source solutions Cost benefit NYC DoITT - GovTech 2009

EA Feasibility Reduce Reuse Re(fresh)cycle Can dependencies on proprietary solutions be avoided? Reuse Can open source solutions leverage existing infrastructure, middleware, and skill sets? Re(fresh)cycle Can a change to open source wait until the next technology refresh cycle? Three eco-friendly steps to figure out if there is even a chance an organization can use open source effectively. Build to standards NYC DoITT - GovTech 2009

Strategies for Deployment Baseline Requirements What is the bare minimum users need to perform their functions? Impacts and Gaps How will open source affect your core enterprise operations and infrastructure? Cost-Benefit Is a reduction in cost worth any deficiencies in a new solution? NYC DoITT - GovTech 2009

Don’t DoITT Just To DoITT Slow Down An open source solution must be properly evaluated, just like any other technology change Phased Approach If open source presents a significant change to your organization, switch over in sections Hybrid Approach Take the aspects of an open source solution that provide benefits and keep your existing systems NYC DoITT - GovTech 2009

DoITT’s Open Source POC Define Requirements Scope Identify Resources Personnel Integrate Infrastructure Middleware Verify Compatibility Functionality Test Usability Efficiency Analyze Cost Gaps Steps scroll across screen on mouse click or spacebar press. The first three are visible initially, and after the scroll the last three are visible (there are only 6). How to do a POC for open source: Define – what are you looking to use open source to accomplish within your org? What size and breadth of POC is appropriate to get a good answer to that question? Identify – what and who you need to push an open source solution to your POC users. Integrate – where do you need to integrate existing technology solutions? Is it possible to do so? What needs to be done to integrate, what specific changes need to be made to the new or current solution to bring them together? Verify – is the open source solution capable of meeting your requirements and integration prerequisites? If so, then proceed with integration and deployment. If not, then the solution is not for your organization. Test – how is the solution accepted among your uses and IT staff? Does it have the required functionality? Analyze – is the solution cost-effective to deploy? What are the gaps between it, your current solution, and your ideal setup? NYC DoITT - GovTech 2009