• Save
Why FLOSS is a Java developer's best friend: Dave Gruber
Upcoming SlideShare
Loading in...5

Why FLOSS is a Java developer's best friend: Dave Gruber



The explosion of new open source projects is changing the game for today’s Java developers. With literally hundreds of thousands of FOSS projects underway, the opportunity to leverage open source to ...

The explosion of new open source projects is changing the game for today’s Java developers. With literally hundreds of thousands of FOSS projects underway, the opportunity to leverage open source to deliver “the trifecta” (faster/better/cheaper) has never been better. In this session we will explore tools and resources that can help you navigate the vast world of open source projects, in addition to sharing tips and tricks that will help you narrow the field so you can quickly get to the right projects for your next application.



Total Views
Views on SlideShare
Embed Views



1 Embed 5

http://lanyrd.com 5



Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

Why FLOSS is a Java developer's best friend: Dave Gruber Why FLOSS is a Java developer's best friend: Dave Gruber Presentation Transcript

  • FLOSS:Your New Best Friend Dave Gruber Director of Developer Programs Black Duck Software, Inc. Stewards of ohloh.net
  • Where do YOU find FLOSS? 1.8m repositories 260k projects 250k projects 108k repositories 28.5k projects 30k projects 250 projects9.5k projects 2
  • Sifting though the world of open source GitHub: 1,751,000 repositories 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
  • 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?
  • 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
  • So, how many projects are active? 6000Days since last commit 5000 4000 3000 17.3% 2000 10001 Yr 100 90 80 70 60 50 40 30 20 10 % of All Analyzed Projects
  • But do these 17% have a team? 2827Number of Contributors 50 40 30 49.3% 2 or more 8.5% of all analyzed projects 20 10 2 100 90 80 70 60 50 40 30 20 10 % of Active Projects in the Past Year
  • Languages of live projects Perl C# Ruby Java still leads the pack! PHP JavaScript C PythonTop 5000 live projects C++ Other
  • Take-aways• Only a small fraction of all the projects ever started gain long-term traction.• Less than 5% of all projects analyzed are “live” (1+ commits in the past year, and 2+ committers ever.)• While Java leads the pack, newer projects trending towards Python, PHP, JavaScript. Activity Matters so check before you use!
  • So how can we sift through all these projects?!Find Evaluate Approve Track
  • Finding FLOSS 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
  • Search public directoriesPublic FOSS Directories – ohloh.net 550,000 projects – olex.openlogic.com 330,000 projects – ostatic.com 120,000 projects – Maven Central search.maven.org – Free Software Foundation http://directory.fsf.org 6850 projects – osalt.com ~500 projects – EOS Directory (Enterprise-ready OSS) ~400 projectsPublic FOSS Code Search options – code.ohloh.com 11b+ LOC – krugle.org – Codase.com 250m LOC – grepcode.com (Java only) – Symbolhound.com/codesearch – Searchco.de
  • 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. Is the code widely used in other places?7. Size and complexity?8. Are there known vulnerabilities?9. Any outstanding lawsuits?10. Is there commercial support available?11. Does the project use encryption?12. What is the quality of the code?
  • 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
  • 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 FLOSS 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
  • 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)
  • 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 Approve Track
  • 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
  • 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.
  • FLOSS Adoption Lifecycle Mission criticalVa Strategicl imperativeue Tactical decision Engineer driven Tech mgmt driven Business strategy driven Opportunistic Policy Engagement Usage Contribution
  • 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?
  • 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.
  • Getting more out of FLOSSWhat if you could leverage the methodsbehind 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?
  • “Innersourcing” The application of best practices, processes, culture and methodologies taken from the open source world and applied to internal software development and innovation efforts.10/16/2012 24
  • Characteristics1. Transparency2. Collaboration3. Self-organization4. Egalitarianism5. Meritocracy10/16/2012 25
  • Compared to internal dev FOSS Internal1. Transparency 1. Need-to-know2. Collaboration 2. Self-motivated3. Self-organization 3. Org boundaries4. Egalitarianism 4. Chain of command5. Meritocracy 5. Autocratic10/16/2012 26
  • 3 Pillars of Inner-Source Tools & Ethos Processes Mechanisms Inner-Source10/16/2012 27
  • Ethos 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!10/16/2012 28
  • 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 Incubate Develop Maintain10/16/2012 29
  • Mechanisms and Tools supporting the methods Forge Basic Wiki Infrastructure Requirements Bug Tracker10/16/2012 30
  • Mechanisms Forge Code Quality in the open • Bug tracking is typically limited to individual teams Anyone can report issues Bug Tracker New contributors can engage by fixing a bug10/16/2012 31
  • Mechanisms – CommunicationsPublic wikis – Single point of communication – Self-documenting – Archive history of project decisions and progress WikiEmail lists – Decision making in the open – Self-documenting – Open to all to participateIRC Channels and Forums – Open developer discussions10/16/2012 32
  • Potential Benefits 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 development10/16/2012 33
  • Challenges Technology is the “Easy Part” - be aware of: • 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 code10/16/2012 34
  • Getting Started 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 levels10/16/2012 35
  • A free, community resource Dave Gruber Director Developer Programs Black Duck ohloh.net dgruber@blackducksoftware.com @davegruber5 36