1. 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

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

3. 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

4. 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

5. 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

6. 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

7. 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

8. 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

9. 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

10. 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