The document discusses the experiences of Michael DeHaan and Greg DeKoenigsberg in building and managing the open-source project Ansible. It highlights the importance of communication, effective use of GitHub, designing for user experience, modularity, and data-driven decision-making for project success. The authors compare Ansible's rapid growth and contributor engagement to other projects, illustrating the significance of community involvement in software development.

1. Building a Community in an Accelerated World
Michael DeHaan and Greg DeKoenigsberg

2. BONA FIDES
Who are these guys, anyway?

3. ABOUT GREG
Fedora, OLPC, Eucalyptus
Once upon a time, I read a paper
Modularity and Option Value

4. ABOUT MICHAEL
Lots of systems management tech
Cobbler, Func
Startups

5. WHAT IS ANSIBLE?
Config mgmt, App deployment, Cloud, Orchestration
just manages machines over SSH
expresses configuration and processes in YAML
based on Python, but supports other languages

6. LINUX REACHED 100+ CONTRIBUTORS A MONTH IN YEAR 11
1 contributor (Linus Torvalds), August 1991
102 contributors, March 2002
https://www.openhub.net/p/linux

7. ANSIBLE REACHED 100+ CONTRIBUTORS A MONTH IN YEAR 2
1 contributor (Michael DeHaan), February 2012
115 contributors, March 2014
https://www.openhub.net/p/ansible-ssh

8. WHAT'S CHANGED?
And how do you manage an open source project in this new
world?

9. KEYS TO OUR SUCCESS
1. We overcommunicate
2. We use Github wisely
3. We design for first experience
4. We design for modularity
5. We gather the right data for decisions

10. 1. OVERCOMMUNICATE

11. EMAIL FOR LONG-FORM DISCUSSIONS
When someone bothers to ask a question...
any question...
they've invested time in your project.
Answer them.

12. IRC FOR REAL-TIME DISCUSSIONS
When people need help now, be present.
This takes commitment until you have a community of users.
Almost 50% of our time in early stages of the project
Do allow your community to become self-sufficient.

13. TWITTER FOR BUZZ
Chatter and banter are great,
but problems can't be solved in 140 characters.
Drive discussions to the mailing list.
Review Twitter daily.

14. DON'T TAKE CRITICISM PERSONALLY
Respond to what requires a response.
Don't feed the trolls.
Don't do drama, and don't be afraid to ban problem users.

15. WHAT SUCCESS LOOKS LIKE
900 users on IRC
3500 ansible-project
8000+ stars on GitHub
2500+ forks, 38% turn into contributions

16. REMEMBER: QUIET PROJECTS ARE FAILED PROJECTS.

17. 2. USE GITHUB WISELY

18. THE OLD WAYS ARE GONE
Six million users are on Github.
Other issue trackers and code systems require different logins.
They all use the same tools.
They all have the same expectations.
And they contribute way more freely.

19. USE THE ISSUE TRACKER
The ticket system is flexible (and kind of horrible). Use it.
Prioritize issues quickly.
Ask for more information.
Template your responses.
Enlist bots if needed

20. DO NOT MERGE EVERY SINGLE REQUEST
You are the upstream.
You are responsible for quality.
Review patches even if it takes time.
Mentor contributors where possible.
Take the time to figure out your trusted contributors.

21. WHAT SUCCESS LOOKS LIKE
Success is having too much work
Several dozens of new pull requests, tickets, and emails a day
~900 people on IRC!
Hundreds of tweets in Japanese you don't understand :)

22. 3. DESIGN FOR FIRST EXPERIENCE

23. CAN'T INSTALL SIMPLY IN 15 MINUTES?
Keep working on it.

24. CAN'T GET A WORKING EXAMPLE UP IN A LUNCH HOUR?
Keep working.

25. DOCUMENTATION CONFUSES PEOPLE?
Keep working on it.

26. WHAT SUCCESS LOOKS LIKE
Happy users
Users starting meetups
...

27. 4. MODULARITY IS CRITICAL

28. HUGE SCALE IS A FUNCTION OF ARCHITECTURE

29. WHAT SUCCESS LOOKS LIKE
240+ modules in core
Users/customers join development community (Gawker, Zynga,
etc)
Vendors stepping up to help (Google, Rackspace, etc)

30. 5. GATHER THE RIGHT DATA FOR DECISIONS

31. PAY ATTENTION TO WEB TRAFFIC
Our docs site is awesome for this

32. WHEN IN DOUBT, ASK
SurveyMonkey is free and worth it
Got a question? Ask!

33. Finally...
DON'T BE AFRAID TO DO SOMETHING THAT'S "BEEN DONE"

34. ISN'T CONFIGURATION MANAGEMENT KINDA DONE?
Nope. Not even close.
(also, it's not all config management)

35. TAKING ON THE INCUMBENT
By the numbers

36. CONTRIBUTORS
The people who help build the software
Puppet: 41 per year of life (8 years, 329 contributors)
Ansible: 450 per year of life (2 years, 899 contributors)

37. FORKS
The people who might help build the software in the future
Puppet: 147 per year of life (8 years, 1181 forks)
Ansible: 1253 per year of life (2 years, 2507 forks)

38. STARS
The people who rate the software highly
Puppet: 330 stars per year of life (8 years, 2653 stars)
Ansible: 4033 stars per year of life (2 years, 8066 stars)

39. A GOOD IDEA IS ALWAYS A GOOD IDEA

40. THANKS
Michael: @laserllama
Greg: @gregdek
Questions?