Your SlideShare is downloading. ×
0
Internal Open Source
Internal Open Source
Internal Open Source
Internal Open Source
Internal Open Source
Internal Open Source
Internal Open Source
Internal Open Source
Internal Open Source
Internal Open Source
Internal Open Source
Internal Open Source
Internal Open Source
Internal Open Source
Internal Open Source
Internal Open Source
Internal Open Source
Internal Open Source
Internal Open Source
Internal Open Source
Internal Open Source
Internal Open Source
Internal Open Source
Internal Open Source
Internal Open Source
Internal Open Source
Internal Open Source
Internal Open Source
Internal Open Source
Internal Open Source
Internal Open Source
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Internal Open Source

548

Published on

Talk from OSCON 2013. …

Talk from OSCON 2013.
Most companies, big and small, have some code that is shared by many but owned by few. It may be in the form of useful libraries for common tasks like logging and configuration. It may be in the form of internal services that cross business functions. Managing these libraries and services often falls onto the teams that originally created them, or on a core tech team that owns all shared software. This model has many drawbacks; slow changes, a lack of transparency for users, and a tendency to cause bottlenecks for other developers.

The modern enterprise has fully embraced OSS, but there is still an opportunity for us to learn from the processes used to create that software and apply it to our internal shared software. Encouraging shared contribution across teams to these code bases, with a “committer group” that ensures quality and stability, solves many of the challenges of shared software. It’s also a great opportunity to give developers exposure to code they may otherwise not have the time to examine, and increases shared knowledge across the company.

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
548
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
9
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • Part 1: Benefits gained from OS-style community development, in generalBenefits to companies, in specificHow to identify projects that could benefit from theseLessons learned: Big CompanyLessons learned: Small company
  • ORGANIZATIONAL CHALLENGE
  • You will be assimilated
  • Startup: everyone sit in a roomOSS: Built-in tolerance to friction because distributed dev is fundamental
  • Eases friction esp in large orgMore than just shared sourceEspecially in distributed orgOf processOf decision makingLeads to higher Quality
  • Especially in distributed orgOf processOf decision makingLeads to higher Quality
  • Quality comes from transparencyQuality via processAllow developers to learn and level-up from each other
  • Learn from each otherMeetups, Conferences*Identify quality and maturityEngagement beyond immediate team, to others in the companyAbility to switch teams with lower overhead, helps internal mobility
  • retention
  • Logging standards, alerting, often evolves into libraries to enable standards
  • Collective code ownership:Principle of AgileRequires quality discipline (testing, mentoring, pairing)Doesn’t scaleHow do you focus responsibility?When all code is written this way, it can slow down development
  • Small co of 15 devsCollective code ownershipStorefront and infra teams
  • Transcript

    • 1. INTERNAL OPEN SOURCE RUNNING INTERNAL PROJECTS WITH OPEN-SOURCE PRACTICES CAMILLE FOURNIER RENT THE RUNWAY @SKAMILLE
    • 2. MOTIVATION
    • 3. FRICTION Communication overhead
    • 4. FRICTION Communication overhead • Meetings meetings meetings Increases with more people Amplified by distance
    • 5. MORE THAN JUST AVAILABLE SOURCE
    • 6. BENEFITS Reduce Friction Enable Internal Mobility Improve Quality Strengthen Community and Culture Improve Retention
    • 7. WHERE TO FIND INTERNAL OSS?
    • 8. SHARED NEEDS
    • 9. SHARED NEEDS OSS exists and thrives in places of shared need >1 developer + >1 project = shared needs Start simple!
    • 10. HOW DO WE DEAL WITH SHARED NEEDS? We don’t; each team implements exactly what they need Shared software is collectively owned by the whole team • “Collective Code Ownership” We create a “core” team that owns all centralized code
    • 11. THE “CORE” TEAM Benefits: Dedicated resources working on shared software Downside: Team is not using the shared software Can make for sane software but can also lead to feature bloat Great starter material for internal open source
    • 12. CASE STUDY: BIG COMPANY
    • 13. CASE STUDY: BIG COMPANY Some centralized libraries not even released with source Federated organizations developing their own code Disparity of ways of doing development across the company A desire to centralize and share functionality A desire to code cross-team
    • 14. NEEDS Shared Repos that are visible to the whole engineering staff Shared ticketing system Mailing lists Code Review system Support for builds and artifacts
    • 15. BARRIERS TO ENTRY Expected: Management buy-in Actual: Platform and tools for running shared projects
    • 16. ADOPTION Within a matter of months, over 40 projects moved to open platform Entire teams moved all of their development onto shared platform Created a shared platform that everyone could use for SDLC management Opened the whole company to more involvement with external Open Source Community
    • 17. CASE STUDY: SMALL STARTUP
    • 18. CASE STUDY: SMALL STARTUP All source code is viewable by all tech employees Infrastructure team writes and owns core services Need to move fast Time constraints and heavy business pressure
    • 19. NEW STRUCTURE Business-focused Pods No more core infrastructure team Shared infrastructure services across Pods No dedicated resources for shared code
    • 20. DEVELOPER POLL Does visibility into the code bases of other teams make a difference in your experience here at Rent the Runway? 1 – It is something that provides a lot of job satisfaction for me 5 – I never look and don’t care
    • 21. DEVELOPER POLL Does being able to modify all code make your job easier? 1 – Much easier, I would quit if I could not do this 5 – I never do this and never want to
    • 22. WHAT SHOULD WE BE DOING? Responses Pull Reqs/ Code Reviews QA Signoff Limited Committers
    • 23. LESSONS Hard to find the time to maintain cohesion between all projects when 100% “volunteer” May want a core infrastructure team that acts as a gatekeeper group When you don’t adopt all OSS best practices (such as formal code reviews) quality is perceived to suffer
    • 24. FINAL THOUGHTS OSS practices bring a great deal of developer joy Can help identify weaknesses in your systems Need to follow ALL of the best practices of OSS to make it work best Start the way you want to grow
    • 25. CONTACT ME! Tweet me @skamille Email me camille@apache.org Read me http://whilefalse.blogspot.com/ Rent the Runway is hiring engineers! Email me!

    ×