Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Innovate more, code less, optimizing foss utilization - Dave Gruber


Published on

Best-in-class companies are leveraging up to 80% of their code from the world of open source, necessitating new, robust management and governance practices. With over 650,000 open source projects available, and Java still in the top three languages use in open source projects, our ability to adequately leverage this opportunity requires a systematic approach to the search, selection, and management of open source. In this session we will talk through a phased approach to increasing your use of open source, leading to faster Java development while significantly reducing risk.

Published in: Technology
  • Be the first to comment

Innovate more, code less, optimizing foss utilization - Dave Gruber

  1. 1. Innovate More. Code Less.Optimizing open source utilization.Dave GruberDirector of Developer ProgramsBlack DuckStewards of
  2. 2. 2How much open source do you use?30%80%Average Best in ClassAverage represents the portion of FOSS in the overall codebases of 500large enterprises surveyed by Gartner (2012)
  3. 3. 3Where do YOU find FOSS?30k projects28.5k projects108k repositories3.2m repos, 350k projects 260k projects9.5k projects250k projects250 projects
  4. 4. Sifting though the world of open sourceGitHub: 350,000 projectsSourceForge: 260,000 projectsGoogleCode: 250,000 projectsBitbucket: 108,000 repositoriesCodeplex: 29,000 projectsLaunchPad: 28,500Foundations: 500+ projectsPhoto from
  5. 5. And are all these real projects?Lots of projects, but…– How many are active, how many abandoned?– How many have a team?How important is it that people arestill working on a project?
  6. 6. How many projects are active?• 550,000+ projects on Ohloh.• 271,372 with a code analysis.• 96,824 with a commit in the past 2 years.• 46,883 with a commit in the past year.• 29,303 with a commit in the past 6 months.• 21,251 with a commit in the past 3 months.• 12,870 with a commit in the past month.• 5,629 with a commit in the past week.• 1,224 with a commit in the past day
  7. 7. So, how many projects are active?Dayssincelastcommit100020003000400050006000100 90 80 70 60 50 40 30 20 10% of All Analyzed Projects1 Yr17.3%
  8. 8. But do these 17% have a team?100 90 80 70 60 50 40 30 20 10% of Active Projects in the Past YearNumberofContributors1020304050282722 or more49.3% (8.5% of all analyzed projects)
  9. 9. Github Repo Analysis02000400060008000100001200014000# of projects with xx stars# of projects with xx forks<10% of repos have 3+ stars (~320k of 3.2m)projectsStars12k projects have 100+ starsData from April 2013
  10. 10. Languages of live projectsOtherCC#C++Java still leads the pack!JavaScriptPerlPythonPHPRubyTop 5000 live projects
  11. 11. Take-aways• Only a small fraction of all the projects ever startedgain long-term traction.• < 9% of all projects analyzed are “live” (1+ commitsin the past year, and 2+ committers ever.)• While Java still leads the pack, newer projectstrending towards Python, JavaScript, Ruby & PHP.Activity Matters…so check before you use!
  12. 12. So how can we sift throughall these projects?!Find Evaluate Approve Track
  13. 13. Finding FOSS is “easy”• Searching the “forges”•••••• Ask StackOverflow, Google SearchFind Evaluate Approve Track
  14. 14. Search public directoriesPublic FOSS Directories– 590,000 projects– 330,000 projects– 120,000 projects– Maven Central Repository– Free Software Foundation 6850 projects– ~500 projects– EOS Directory (Enterprise-ready OSS) ~400 projectsPublic FOSS Code Search options– 23b+ LOC–– 250m LOC– (Java only)––
  15. 15. Choosing the “right” project1. What languages are used?2. What’s the license for the project?3. How is the documentation?4. How well maintained is the project?5. How active is the project?6. What is the quality of the code?7. Is the code widely used in other places?8. Size and complexity?9. Are there known vulnerabilities?10. Any outstanding lawsuits?11. Is there commercial support available?12. Does the project use encryption?
  16. 16. So where are the answers?The easy ones (look at the code or project page)1. What languages are used?2. What’s the license for the project?• Or check a project directory like Ohloh, OLEX, etc.3. How is the documentation?• Look in the wiki, check Ohloh (counts comments)4. Size and complexity?• Review the code and structureFind Evaluate Approve Track
  17. 17. So where are the answers?A little harder, but still available5. Are there known vulnerabilities? (National Vulnerabilities DB)••• HP Fortify scans some FOSS projects6. How well maintained is the project?• Check the bugbase, see how many high priority bugs are open andfor how long7. How active is the project?• # of active committers, commit stream (Project or Ohloh)8. Is the code widely used in other places?• Search StackOverflow, google, download stats
  18. 18. So where are the answers?The tougher ones9. Any outstanding lawsuits?• Google search for project name & “lawsuit”10. Is there commercial support available?• Companies like Credativ in Germany and OpenLogic in the USsupport a subset of FOSS projects11. Does the project use encryption?• Sometimes documented on project sites, otherwise explore theproject12. What is the quality of the code?• Limited # of code quality audits from Coverity (
  19. 19. Approvals• Do you have a formal approval process?• How many of these questions are required?• Know your FOSS policy.• Speed up the process by getting answers inadvance!• Automated solutions exist to help.Find Evaluate TrackApprove
  20. 20. Inventory, Catalog & TrackingKnow what and where you use FOSS!– Vulnerabilities– Possible license issues– New releases– ReuseScan for existing FLOSS, then stay current.Find Evaluate Approve Track
  21. 21. 21An Open Source Policy defines:1. Where and how FOSS will be used2. Acceptable licenses3. Release and redistribution of FOSS4. FOSS request, evaluation & approval process5. Support & maintenance requirements6. Community participation guidelines“Companies must have a policy for procuring OSS, deciding whichapplications will be supported by OSS, and identifying the intellectualproperty risk or supportability risk associated with using OSS.”“Once a policy is in place, then there must be a governance process to enforce it.”– Laurie Wurster, Research Director at Gartner Group
  22. 22. 224 steps to creating your policy1. Identify key stakeholders– Senior technical managers, Architects– Release managers, Security managers– Legal2. Obtain stakeholder commitment– Understand your use cases (products, applications,components)3. Draft the policy– Sources, licenses, selection criteria– Approval process– Audit and monitoring process4. Review and approve the policy
  23. 23. 23Open Source Governance1. Aligns FOSS usage with FOSS policy– Includes SW supply chain2. Assists developers early in the SDLC3. Closed-loop– Monitors the state of a system and reports ifit’s meeting its goals
  24. 24. Automating GovernanceCode Build TestPlanApplicationdevelopmentcycleReleaseOpen sourcegovernancelifecycleDescriptionVersionVulnerabilitiesLicenseMaturity…CryptographyAcquire Approve Catalog Audit MonitorOpenSourceKnowledgeBase
  25. 25. Are you an Open Source Free-Loader?Ok, so you use…• But do you contribute?– That’s ok. “Freeloading” is just the beginningand where everyone starts.
  26. 26. FOSS Adoption LifecycleOpportunistic PolicyTacticaldecisionMissioncriticalStrategicimperativeEngagementEngineer driven Business strategy drivenTech mgmt drivenUsage ContributionValue
  27. 27. Why contribute?• As you customize to meet your needs, thecommunity can help further refine.• If you customize and don’t contribute back,you own it forever. Give back and thecommunity can help evolve and maintain.• You got something of value for free, why notgive back?
  28. 28. Why start and manage?• If you create something of value…– That’s NOT a competitive differentiator…– But you depend on it…Building a community around it canaccelerate it’s development.
  29. 29. Getting more out of FOSSWhat if you could leverage the methodsbehind FLOSS for internal development?– Is there an opportunity to leverage the innerworkings of open source development torefine internal development?– What’s to be learned?
  30. 30. The application of best practices, processes,culture and methodologiestaken from the open source worldand applied to internal software developmentand innovation efforts.30“Innersourcing”6/5/2013
  31. 31. 6/5/2013 31Characteristics1. Transparency2. Collaboration3. Self-organization4. Egalitarianism5. Meritocracy
  32. 32. 1. Transparency2. Collaboration3. Self-organization4. Egalitarianism5. Meritocracy6/5/2013 321. Need-to-know2. Self-motivated3. Org boundaries4. Chain of command5. AutocraticFOSS InternalCompared to internal dev
  33. 33. 6/5/2013 33Ethos ProcessesTools &MechanismsInner-Source3 Pillars of Inner-Source
  34. 34. Open access: to all code, documentation, and how decisionswere made. Shared, common directory to find SW for reuse andknowledge.Open participation: No artificial boundaries to joining andcontributing.Open communication: Visible decision making process.Documented history of all decisions and the reasoning behindthem.Open governance: Process is designed and managed in theopen. Process changes to meet the needs of the peopleparticipating.Open leadership: Leaders are respected based on their abilityto execute. If people don’t like the direction of a project, fork it!6/5/2013 34Ethos
  35. 35. ProcessesGovernance– Designed for the people, by the people– Rules of engagement (how to contribute)– How decisions are made– How the rules can be changed in the future– In writing, for all to see6/5/2013 35Incubate Develop Maintain
  36. 36. Mechanisms and Tools supportingthe methods6/5/2013 36ForgeBug TrackerWikiBasicInfrastructureRequirements
  37. 37. Mechanisms6/5/2013 37Code Quality in the open• Bug tracking is typically limited to individual teamsAnyone can report issuesNew contributors can engage by fixing a bugForgeBug Tracker
  38. 38. Mechanisms: CommunicationsPublic wikis– Single point of communication– Self-documenting– Archive history of project decisions andprogressEmail lists– Decision making in the open– Self-documenting– Open to all to participateIRC Channels and Forums– Open developer discussions6/5/2013 38Wiki
  39. 39. 1. Better code - Greater internal code scrutiny2. Increased innovation and focus on value-added development - More knowledge sharingand code re-use3. Better resource allocation - Broad expertise4. Extensive support and buy-in from organization5. Improved productivity, morale and retention -motivated contributors, job satisfaction!6. Faster development6/5/2013 39Potential Benefits
  40. 40. Technology is the “Easy Part” - be aware of:6/5/2013 40Challenges• Management & developer Mindset• Lack of communication and shared purpose• Culture shock and dissonance• Lack of process consistency• Technical mindset shift from deliveringbinaries to delivering source code• Mindset shift from delivering final product toincremental quality code
  41. 41. 1. Define clear community goals, vision, behaviors andexpectations2. Identify ‘seed-collaborators’ and catalysts3. Choose 1-2 small/common technologies/projects to start4. Deploy Inner Source platform mechanisms– Forge, Wiki, Bugtracker, Lists, Forums5. Define a governance model– Communications and incentive program– Who coordinates/approves changes/releases6. Talk to Management about HR ramifications– Employee performance reviews– Managerial expectations/comfort levels6/5/2013 41Getting Started
  42. 42. 42A free, community resourceDave GruberDirector Developer ProgramsBlack