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.

1. HOW TO AVOID
CREATING A
GITHUB
JUNKYARD
LAURI APPLE, ZALANDO

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. About You
● Managing a GitHub org?
● GH manager at company?
● Do OSS b/c fun?
● Proud workaholic?

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. ● 15 countries
● 20+ million active customers
● ~3.6 billion € net sales
● 200,000+ products
● 12,000+ employees
● 200+ million visits/month
About Zalando

6. http://zalando.github.io/

7. ● Polyglot, poly-org (four)
● Big on infra, APIs
● Maturing: quality over quantity
Zalando.github.io

8. Why We Open Source
● Personal development
● Give back
● Improve quality
● Reputation
● Recruitment

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. 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. 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. https://medium.com/@jboogie/everyone-is-too-busy-is-not-a-prioritization-strategy-45ac4d525ab5

13. Asked a Colleague
Q: Do you actually enjoy
maintaining all that stuff?
A: That’s a hard question
Should it be hard?

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. OSS Isn’t Really Free
● Cost: maintenance, goodwill, perspective
● Craftsmanship suffers
● “Throwaway” aspect
● If no one editing => GitHub junkyard

17. https://www.flickr.com/photos/hugo90/5116732240/
Building Junkyards: A Case Study

18. 2008-2015: Command & Control

19. We Made a Little FOSS
Octocat: “I’m
still hungry”

20. 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

21. Our GitHub Release Cycle

22. 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

23. Our GitHub Junkyard: Lots of Dogs
● Not friendly
● Quality varied
● Stability unclear
● Missing docs, tests, files
● Not responding to PRs

24. How We Were Building OSS

25. High Friction Was Our Aesthetic
● Works well, but ...
● Lots of moving parts/onboarding
● Value hidden
● Team realized it
eventually
● Now: deprecating

26. ● GitHub charged?
● Asked community?
● More time?
● Thought about costs?
Would We Have Build It This Way If...

27. ● 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

28. Harsh OSS Ecosystems :(

29. 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

30. 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

31. Guidelines: Minimum Viable Process

32. Supporting Resources
● Templates: README, product, .md files
● Guidance for asking why, what, how
● Recycled
https://github.com/zalando/zalando-howto-open-source

33. Organize Repos

34. Craftsmanship Coaching
● Discipline => freedom
● Avoid burnout
● Optimize
● Plan
● Customers
● Are we solving problems? For whom?

35. 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

36. Challenges
https://www.flickr.com/photos/kamshots/9692645837

37. 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

38. 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

39. 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

40. Need Maturity Model Mindset
● OSS strategy
● Incubator cleanup
● Peer Review Group
● Mgmt support
● Community non-negotiable
● Training, coaching

41. 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

42. “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

43. Thanks!
● Zalando.github.io
● github.com/lappleapple/feedmereadmes
● @lauritaapplez
● lauri.apple@zalando.de