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.

2017 Microservices Practitioner Virtual Summit: How to Avoid Creating a GitHub Junkyard - Lauri Apple

529 views

Published on

As a former journalist, I tend to think in terms of storytelling. As an open source evangelist, I invite you to do the same. What you share on GitHub tells a story about you, your development practices, and your openness to others in the open source community. If you're motivated to gain users, contributors, and positive feedback about your projects, then building a compelling, coherent narrative is essential. In this talk, I'll share insights gained from "editing" Zalando's GitHub repository so we can tell a better story. From 400+ projects of widely differing quality, reliability and maintenance levels, we've winnowed our offerings to make our highest-quality work more discoverable. I'll share how we used GitHub and other tools to create guidelines, categories, and processes that bring sanity to our storytelling. If your organization is facing similar GitHub-bloat challenges, or looking for ways to manage your repos more effectively, you might find some help here.

Published in: Software
  • Nice !! Download 100 % Free Ebooks, PPts, Study Notes, Novels, etc @ https://www.ThesisScientist.com
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Be the first to like this

2017 Microservices Practitioner Virtual Summit: How to Avoid Creating a GitHub Junkyard - Lauri Apple

  1. 1. HOW TO AVOID CREATING A GITHUB JUNKYARD LAURI APPLE, ZALANDO
  2. 2. On the Menu ● Intro ● Asking Why Before Hitting Publish ● Building Junkyards: A Case Study ● Cleaning Up: The Big Dig ● Closing: Status report, learnings
  3. 3. About You ● Managing a GitHub org? ● GH manager at company? ● Do OSS b/c fun? ● Proud workaholic?
  4. 4. About Me ● Agile producer (coach+PM) ● OSS Evangelist for 1700+ techs ● Open Org Ambassador (Red Hat) Primary Projects: ● LappleApple/Feedmereadmes: README help, project advice, maturity model ● LappleApple/awesome-leading-and-managing
  5. 5. ● 15 countries ● 20+ million active customers ● ~3.6 billion € net sales ● 200,000+ products ● 12,000+ employees ● 200+ million visits/month About Zalando
  6. 6. http://zalando.github.io/
  7. 7. ● Polyglot, poly-org (four) ● Big on infra, APIs ● Maturing: quality over quantity Zalando.github.io
  8. 8. Why We Open Source ● Personal development ● Give back ● Improve quality ● Reputation ● Recruitment
  9. 9. But Why Do We OSS? ● Motivations? ● Why this way? ● Why make so much ourselves? ● Is it sustainable? — Kind? — A burden? https://www.flickr.com/photos/ksayer/5614813544/
  10. 10. Why I Ask Why Print Journalism Online Blogging Craftsmanship, relationships Speed, volume, anonymity Limited space Unlimited space Best editors were hardest Editor also time-crunched
  11. 11. Software Hamsters ● Busy = status symbol ○ Fun ○ Heroism ○ Pressure ● Burns us out ○ Multitasking -10 IQ points (Levitin) ● http://www.talenteconomy.io/2017/05/04/busy-now-status-symbol-needs-stop/ ● https://www.flickr.com/photos/haundreis/2760350708
  12. 12. https://medium.com/@jboogie/everyone-is-too-busy-is-not-a-prioritization-strategy-45ac4d525ab5
  13. 13. Asked a Colleague Q: Do you actually enjoy maintaining all that stuff? A: That’s a hard question Should it be hard?
  14. 14. Asked Another Colleague Q: What if GitHub charged per repo? A: “LOL … we would change a bunch of things” Why not change the things now, voluntarily?
  15. 15. OSS Isn’t Really Free ● Cost: maintenance, goodwill, perspective ● Craftsmanship suffers ● “Throwaway” aspect ● If no one editing => GitHub junkyard
  16. 16. https://www.flickr.com/photos/hugo90/5116732240/ Building Junkyards: A Case Study
  17. 17. 2008-2015: Command & Control
  18. 18. We Made a Little FOSS Octocat: “I’m still hungry”
  19. 19. Switch to Autonomy/Mastery/Purpose Model ● Autonomous teams ● Open Source First ● Choose your stack ● Share your code (and do other stuff, but ...) ● Share we did
  20. 20. Our GitHub Release Cycle
  21. 21. Jan 2016: 400 projects ● Open sourcing all the things ● “Coding in the open”: Z-specific ● Didn’t know what we had ● Compulsive release cycle ● Not asking why/what value
  22. 22. Our GitHub Junkyard: Lots of Dogs ● Not friendly ● Quality varied ● Stability unclear ● Missing docs, tests, files ● Not responding to PRs
  23. 23. How We Were Building OSS
  24. 24. High Friction Was Our Aesthetic ● Works well, but ... ● Lots of moving parts/onboarding ● Value hidden ● Team realized it eventually ● Now: deprecating
  25. 25. ● GitHub charged? ● Asked community? ● More time? ● Thought about costs? Would We Have Build It This Way If...
  26. 26. ● Want new, novel ● Pressures ● “No time” ● “Might be useful” ● Nostalgia ● “True OSS = share everything” https://www.flickr.com/photos/daveseven/6044653558 We Don’t Plan Junkyards
  27. 27. Harsh OSS Ecosystems :(
  28. 28. Finding theCleaning up: The Big Dig https://www.flickr.com/photos/inetflash/ Goals: ● Apply basic storytelling ● Craftsmanship focus ● Sustainability, less is more Rare chance to shape culture at mega-scale
  29. 29. Takes a While, and Requires Care What’s Fast: ○ Guidelines ○ Templates ○ New orgs What’s Slow: ○ Craftsman mindset ○ Culture shift ○ Trust-building https://www.flickr.com/photos/elephantom/391190
  30. 30. Guidelines: Minimum Viable Process
  31. 31. Supporting Resources ● Templates: README, product, .md files ● Guidance for asking why, what, how ● Recycled https://github.com/zalando/zalando-howto-open-source
  32. 32. Organize Repos
  33. 33. Craftsmanship Coaching ● Discipline => freedom ● Avoid burnout ● Optimize ● Plan ● Customers ● Are we solving problems? For whom?
  34. 34. 1.5 Years In ... ● 55 repos ● More “why” ● Community-oriented ● Project discovery ● Archiving to GHE ● Nike, Starbucks ● Tests, docs, files ● Incubator: from +8 pages to 1.5
  35. 35. Challenges https://www.flickr.com/photos/kamshots/9692645837
  36. 36. Craftsmanship Habits Take Time ● “Put it on GitHub” = done ● MVP: No != Not Yet ● FOMO ● Complying != not intrinsic Motivation ● Dreaming bigger https://www.flickr.com/photos/26675187@N03/5466550549
  37. 37. Getting Friendlier Over Time ● READMEs help to ... ○ Managing expectations better ○ ETA for responses to PRs ○ Build status ○ Clarity about plans ○ If working software not the goal, can say so
  38. 38. Getting Leads/Heads Buy-in ● Delivery pressure ● Don’t always analyze “busy” ● Product mindset not for all ● Delegation ● Technical debt: something to complain about, not fix
  39. 39. Need Maturity Model Mindset ● OSS strategy ● Incubator cleanup ● Peer Review Group ● Mgmt support ● Community non-negotiable ● Training, coaching
  40. 40. Closing Tips ● 1. Clean up, don’t wait ● 2. New? Start now ● 3. Ask why ● 4. Don’t make cleanup your burden ○ Slack ○ Keep it simple
  41. 41. “The moment a new contributor posts a PR or a draft patch, a timer starts. The longer maintainers take to respond to their submission, the lower the chance that person will ever contribute to the project again.” — @fuzzychef And then you might have a junkyard https://community.redhat.com/blog/2017/04/ contributors-speed-matters/ Please Respond to People
  42. 42. Thanks! ● Zalando.github.io ● github.com/lappleapple/feedmereadmes ● @lauritaapplez ● lauri.apple@zalando.de

×