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.

1. Innovate More. Code Less.
Optimizing open source utilization.
Dave Gruber
Director of Developer Programs
Black Duck
Stewards of ohloh.net

2. 2
How much open source do you use?
30%
80%
Average Best in Class
Average represents the portion of FOSS in the overall codebases of 500
large enterprises surveyed by Gartner (2012)

3. 3
Where do YOU find FOSS?
30k projects
28.5k projects
108k repositories
3.2m repos, 350k projects 260k projects
9.5k projects
250k projects
250 projects

4. Sifting though the world of open source
GitHub: 350,000 projects
SourceForge: 260,000 projects
GoogleCode: 250,000 projects
Bitbucket: 108,000 repositories
Codeplex: 29,000 projects
LaunchPad: 28,500
Foundations: 500+ projects
Photo from http://splits59.com/blog/?p=49

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 are
still working on a project?

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. So, how many projects are active?
Dayssincelastcommit
1000
2000
3000
4000
5000
6000
100 90 80 70 60 50 40 30 20 10
% of All Analyzed Projects
1 Yr
17.3%

8. But do these 17% have a team?
100 90 80 70 60 50 40 30 20 10
% of Active Projects in the Past Year
NumberofContributors
10
20
30
40
50
2827
2
2 or more
49.3% (8.5% of all analyzed projects)

9. Github Repo Analysis
0
2000
4000
6000
8000
10000
12000
14000
# of projects with xx stars
# of projects with xx forks
<10% of repos have 3+ stars (~320k of 3.2m)
p
r
o
j
e
c
t
s
Stars
12k projects have 100+ stars
Data from April 2013

10. Languages of live projects
Other
C
C#
C++
Java still leads the pack!
JavaScript
Perl
Python
PHP
Ruby
Top 5000 live projects

11. Take-aways
• Only a small fraction of all the projects ever started
gain long-term traction.
• < 9% of all projects analyzed are “live” (1+ commits
in the past year, and 2+ committers ever.)
• While Java still leads the pack, newer projects
trending towards Python, JavaScript, Ruby & PHP.
Activity Matters
…so check before you use!

12. So how can we sift through
all these projects?!
Find Evaluate Approve Track

13. Finding FOSS is “easy”
• Searching the “forges”
• Github.com/search
• Code.google.com
• Sourceforge.com/directory
• Codeplex.com/site/search
• Bitbucket.org/repo/all
• Ask StackOverflow, Google Search
Find Evaluate Approve Track

14. Search public directories
Public FOSS Directories
– ohloh.net 590,000 projects
– olex.openlogic.com 330,000 projects
– ostatic.com 120,000 projects
– Maven Central Repository search.maven.org
– Free Software Foundation http://directory.fsf.org 6850 projects
– osalt.com ~500 projects
– EOS Directory (Enterprise-ready OSS) ~400 projects
Public FOSS Code Search options
– code.ohloh.com 23b+ LOC
– krugle.org
– Codase.com 250m LOC
– grepcode.com (Java only)
– Symbolhound.com/codesearch
– Searchco.de

15. Choosing the “right” project
1. 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. 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 structure
Find Evaluate Approve Track

17. So where are the answers?
A little harder, but still available
5. Are there known vulnerabilities? (National Vulnerabilities DB)
• osvdb.org/search/advsearch
• web.nvd.nist.gov/view/vuln/search
• HP Fortify scans some FOSS projects
6. How well maintained is the project?
• Check the bugbase, see how many high priority bugs are open and
for how long
7. 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. So where are the answers?
The tougher ones
9. Any outstanding lawsuits?
• Google search for project name & “lawsuit”
10. Is there commercial support available?
• Companies like Credativ in Germany and OpenLogic in the US
support a subset of FOSS projects
11. Does the project use encryption?
• Sometimes documented on project sites, otherwise explore the
project
12. What is the quality of the code?
• Limited # of code quality audits from Coverity (scan.coverity.com)

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 in
advance!
• Automated solutions exist to help.
Find Evaluate TrackApprove

20. Inventory, Catalog & Tracking
Know what and where you use FOSS!
– Vulnerabilities
– Possible license issues
– New releases
– Reuse
Scan for existing FLOSS, then stay current.
Find Evaluate Approve Track

21. 21
An Open Source Policy defines:
1. Where and how FOSS will be used
2. Acceptable licenses
3. Release and redistribution of FOSS
4. FOSS request, evaluation & approval process
5. Support & maintenance requirements
6. Community participation guidelines
“Companies must have a policy for procuring OSS, deciding which
applications will be supported by OSS, and identifying the intellectual
property 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
4 steps to creating your policy
1. Identify key stakeholders
– Senior technical managers, Architects
– Release managers, Security managers
– Legal
2. Obtain stakeholder commitment
– Understand your use cases (products, applications,
components)
3. Draft the policy
– Sources, licenses, selection criteria
– Approval process
– Audit and monitoring process
4. Review and approve the policy

23. 23
Open Source Governance
1. Aligns FOSS usage with FOSS policy
– Includes SW supply chain
2. Assists developers early in the SDLC
3. Closed-loop
– Monitors the state of a system and reports if
it’s meeting its goals

24. Automating Governance
Code Build TestPlan
Application
development
cycle
Release
Open source
governance
lifecycle
Description
Version
Vulnerabilities
License
Maturity…
Cryptography
Acquire Approve Catalog Audit Monitor
Open
Source
KnowledgeBase

25. Are you an Open Source Free-Loader?
Ok, so you use…
• But do you contribute?
– That’s ok. “Freeloading” is just the beginning
and where everyone starts.

26. FOSS Adoption Lifecycle
Opportunistic Policy
Tactical
decision
Mission
critical
Strategic
imperative
Engagement
Engineer driven Business strategy drivenTech mgmt driven
Usage Contribution
V
a
l
u
e

27. Why contribute?
• As you customize to meet your needs, the
community can help further refine.
• If you customize and don’t contribute back,
you own it forever. Give back and the
community can help evolve and maintain.
• You got something of value for free, why not
give back?

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 can
accelerate it’s development.

29. Getting more out of FOSS
What if you could leverage the methods
behind FLOSS for internal development?
– Is there an opportunity to leverage the inner
workings of open source development to
refine internal development?
– What’s to be learned?

30. The application of best practices, processes,
culture and methodologies
taken from the open source world
and applied to internal software development
and innovation efforts.
30
“Innersourcing”
6/5/2013

31. 6/5/2013 31
Characteristics
1. Transparency
2. Collaboration
3. Self-organization
4. Egalitarianism
5. Meritocracy

32. 1. Transparency
2. Collaboration
3. Self-organization
4. Egalitarianism
5. Meritocracy
6/5/2013 32
1. Need-to-know
2. Self-motivated
3. Org boundaries
4. Chain of command
5. Autocratic
FOSS Internal
Compared to internal dev

33. 6/5/2013 33
Ethos Processes
Tools &
Mechanisms
Inner-Source
3 Pillars of Inner-Source

34. Open access: to all code, documentation, and how decisions
were made. Shared, common directory to find SW for reuse and
knowledge.
Open participation: No artificial boundaries to joining and
contributing.
Open communication: Visible decision making process.
Documented history of all decisions and the reasoning behind
them.
Open governance: Process is designed and managed in the
open. Process changes to meet the needs of the people
participating.
Open leadership: Leaders are respected based on their ability
to execute. If people don’t like the direction of a project, fork it!
6/5/2013 34
Ethos

35. Processes
Governance
– 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 see
6/5/2013 35
Incubate Develop Maintain

36. Mechanisms and Tools supporting
the methods
6/5/2013 36
Forge
Bug Tracker
Wiki
Basic
Infrastructure
Requirements

37. Mechanisms
6/5/2013 37
Code Quality in the open
• Bug tracking is typically limited to individual teams
Anyone can report issues
New contributors can engage by fixing a bug
Forge
Bug Tracker

38. Mechanisms: Communications
Public wikis
– Single point of communication
– Self-documenting
– Archive history of project decisions and
progress
Email lists
– Decision making in the open
– Self-documenting
– Open to all to participate
IRC Channels and Forums
– Open developer discussions
6/5/2013 38
Wiki

39. 1. Better code - Greater internal code scrutiny
2. Increased innovation and focus on value-
added development - More knowledge sharing
and code re-use
3. Better resource allocation - Broad expertise
4. Extensive support and buy-in from organization
5. Improved productivity, morale and retention -
motivated contributors, job satisfaction!
6. Faster development
6/5/2013 39
Potential Benefits

40. Technology is the “Easy Part” - be aware of:
6/5/2013 40
Challenges
• Management & developer Mindset
• Lack of communication and shared purpose
• Culture shock and dissonance
• Lack of process consistency
• Technical mindset shift from delivering
binaries to delivering source code
• Mindset shift from delivering final product to
incremental quality code

41. 1. Define clear community goals, vision, behaviors and
expectations
2. Identify ‘seed-collaborators’ and catalysts
3. Choose 1-2 small/common technologies/projects to start
4. Deploy Inner Source platform mechanisms
– Forge, Wiki, Bugtracker, Lists, Forums
5. Define a governance model
– Communications and incentive program
– Who coordinates/approves changes/releases
6. Talk to Management about HR ramifications
– Employee performance reviews
– Managerial expectations/comfort levels
6/5/2013 41
Getting Started

42. 42
A free, community resource
Dave Gruber
Director Developer Programs
Black Duck
dgruber@blackducksoftware.com
@davegruber5
ohloh.net