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.
Scalable* Way of Doing Open Source * for humans
About me
About me @michaelklishi n
About me
About me clojurewerkz.or g
About me
About me recognised animated gif connoisseur
About this talk
More open source producers
Exponentially more open source consumers
Responsibility
ClojureWerkz
In 2011 • 4 projects
In 2011 • 4 projects • 2 people
In 2011 • 4 projects • 2 people • Single digit external users (tiny startups)
In 2011 • 4 projects • 2 people • Single digit external users (tiny startups) • Little documentation
In 2015 • Over 30 projects
In 2015 • Over 30 projects • 5 people, ~70 contributors
In 2015 • Over 30 projects • 5 people, ~70 contributors • SMEs, Fortune 100, governments, tiny startups, academics
In 2015 • Over 30 projects • 5 people, ~70 contributors • SMEs, Fortune 100, governments, tiny startups, academics • Well ...
Responsibility
responsibility |riˌspänsəˈbilətē| noun ( pl. responsibilities ) the state or fact of having a duty to deal with something ...
A responsible maintainer makes sure the users aren’t angry
Why can they be angry?
• Incorrect expectations/assumpti ons
• Incorrect expectations/assumpti ons • Unexpected changes
• Unexpected changes • Nobody to help
• Unexpected changes • Nobody to help • Too hard to contribute
• Unexpected changes • Nobody to help • Too hard to contribute • Maintainer is an a- hole
Solvable?
Have a helpful README
What does this thing do?
How mature is it?
How do I install it?
What runtimes and/or versions are supported?
What license does it use?
Where can I get help?
Have a mailing list
Let community members help you help your users
Helping others earns their respect
Keep a change log
Keep a useful change log
No, git log is not a change log
Do you write brilliantly detailed commit messages?
git log is often hard to interpret for project outsiders
Provide details for humans
Developer vs. Ops
Post release announcements
Have a project blog
Have a Twitter account
Care about backwards compatibility
Document well
My favourite part about ClojureWerkz is documentation…”
Documentation breeds trust
Make it easy to contribute
Explain the basics of development process
Explain how to install & run dependencies
travis-ci.org
Help beginners help you
Don’t be an a-hole
“It sounds too fucking hard”
Does anyone have the time for that?
Standardise
Standardise • README
Standardise • README • Change log format
Standardise • README • Change log format • Announcement format
Standardise • README • Change log format • Announcement format • Project layout (Leiningen templates)
Standardise • README • Change log format • Announcement format • Project layout (Leiningen templates) • Same process and p...
Automate
Automate • Clojure projects typically have a highly regular structure
Automate • Clojure projects typically have a highly regular structure • Release process
Automate • Clojure projects typically have a highly regular structure • Release process • Documentation deployment
Automate • Clojure projects typically have a highly regular structure • Release process • Documentation deployment • Some ...
Engage contributors
Engage contributors• Respond quickly
Engage contributors• Respond quickly • Be respectful
Engage contributors• Respond quickly • Be respectful • Provide context
Engage contributors• Respond quickly • Be respectful • Provide context • Encourage them to help
Engage contributors• Respond quickly • Be respectful • Provide context • Encourage them to help • Give them credits (in th...
Engage contributors• Respond quickly • Be respectful • Provide context • Encourage them to help • Give them credits (in th...
Use data
Use data • Common questions
Use data • Common questions • Bug reports
Use data • Common questions • Bug reports • Your time
Use data • Common questions • Bug reports • Your time • Who contributes most
Writing documentation
Writing documentation • Don't put it off till release time
Writing documentation • Don't put it off till release time • Write guide structure first
Writing documentation • Don't put it off till release time • Write guide structure first • Ask others to edit
Writing documentation • Don't put it off till release time • Write guide structure first • Ask others to edit • A complete...
Writing documentation • Don't put it off till release time • Write guide structure first • Ask others to edit • A complete...
Writing documentation • Don't put it off till release time • Write guide structure first • Ask others to edit • A complete...
“But what if I’m no longer interested in maintaining X?”
Pass it on
No matter what you do, don’t release abandonware
”But who cares, it’s not my problem what the users will do”
Fair enough
But it’s your reputation
Open source is one of the best ways to market yourself as an engineer
Thank you
@michaelklishi nclojurewerkz.or g
Scalable Open Source
Scalable Open Source
Scalable Open Source
Scalable Open Source
Scalable Open Source
Scalable Open Source
Scalable Open Source
Scalable Open Source
Scalable Open Source
Scalable Open Source
Scalable Open Source
Scalable Open Source
Scalable Open Source
Scalable Open Source
Scalable Open Source
Scalable Open Source
Scalable Open Source
Scalable Open Source
Upcoming SlideShare
Loading in …5
×

Scalable Open Source

1,857 views

Published on

Many companies and individuals these days release parts of their work as open source software. This benefits the entire software development community and brings are new set of challenges. Maintaining open source well takes time and effort. Abandoning a project can be very problematic for your users. How does one find a balance?

In this talk we’ll discuss how we did the impossible: make the users of more than 30 ClojureWerkz projects happy and still have a life.

Published in: Software
no profile picture user

  • Be the first to comment

Scalable Open Source

  1. 1. Scalable* Way of Doing Open Source * for humans
  2. 2. About me
  3. 3. About me @michaelklishi n
  4. 4. About me
  5. 5. About me clojurewerkz.or g
  6. 6. About me
  7. 7. About me recognised animated gif connoisseur
  8. 8. About this talk
  9. 9. More open source producers
  10. 10. Exponentially more open source consumers
  11. 11. Responsibility
  12. 12. ClojureWerkz
  13. 13. In 2011 • 4 projects
  14. 14. In 2011 • 4 projects • 2 people
  15. 15. In 2011 • 4 projects • 2 people • Single digit external users (tiny startups)
  16. 16. In 2011 • 4 projects • 2 people • Single digit external users (tiny startups) • Little documentation
  17. 17. In 2015 • Over 30 projects
  18. 18. In 2015 • Over 30 projects • 5 people, ~70 contributors
  19. 19. In 2015 • Over 30 projects • 5 people, ~70 contributors • SMEs, Fortune 100, governments, tiny startups, academics
  20. 20. In 2015 • Over 30 projects • 5 people, ~70 contributors • SMEs, Fortune 100, governments, tiny startups, academics • Well over 1000 hours spent writing and editing doc guides
  21. 21. Responsibility
  22. 22. responsibility |riˌspänsəˈbilətē| noun ( pl. responsibilities ) the state or fact of having a duty to deal with something or of having control over someone
  23. 23. A responsible maintainer makes sure the users aren’t angry
  24. 24. Why can they be angry?
  25. 25. • Incorrect expectations/assumpti ons
  26. 26. • Incorrect expectations/assumpti ons • Unexpected changes
  27. 27. • Unexpected changes • Nobody to help
  28. 28. • Unexpected changes • Nobody to help • Too hard to contribute
  29. 29. • Unexpected changes • Nobody to help • Too hard to contribute • Maintainer is an a- hole
  30. 30. Solvable?
  31. 31. Have a helpful README
  32. 32. What does this thing do?
  33. 33. How mature is it?
  34. 34. How do I install it?
  35. 35. What runtimes and/or versions are supported?
  36. 36. What license does it use?
  37. 37. Where can I get help?
  38. 38. Have a mailing list
  39. 39. Let community members help you help your users
  40. 40. Helping others earns their respect
  41. 41. Keep a change log
  42. 42. Keep a useful change log
  43. 43. No, git log is not a change log
  44. 44. Do you write brilliantly detailed commit messages?
  45. 45. git log is often hard to interpret for project outsiders
  46. 46. Provide details for humans
  47. 47. Developer vs. Ops
  48. 48. Post release announcements
  49. 49. Have a project blog
  50. 50. Have a Twitter account
  51. 51. Care about backwards compatibility
  52. 52. Document well
  53. 53. My favourite part about ClojureWerkz is documentation…”
  54. 54. Documentation breeds trust
  55. 55. Make it easy to contribute
  56. 56. Explain the basics of development process
  57. 57. Explain how to install & run dependencies
  58. 58. travis-ci.org
  59. 59. Help beginners help you
  60. 60. Don’t be an a-hole
  61. 61. “It sounds too fucking hard”
  62. 62. Does anyone have the time for that?
  63. 63. Standardise
  64. 64. Standardise • README
  65. 65. Standardise • README • Change log format
  66. 66. Standardise • README • Change log format • Announcement format
  67. 67. Standardise • README • Change log format • Announcement format • Project layout (Leiningen templates)
  68. 68. Standardise • README • Change log format • Announcement format • Project layout (Leiningen templates) • Same process and practices across the board
  69. 69. Automate
  70. 70. Automate • Clojure projects typically have a highly regular structure
  71. 71. Automate • Clojure projects typically have a highly regular structure • Release process
  72. 72. Automate • Clojure projects typically have a highly regular structure • Release process • Documentation deployment
  73. 73. Automate • Clojure projects typically have a highly regular structure • Release process • Documentation deployment • Some things (e.g. announcements) are still better done by hand (our experience)
  74. 74. Engage contributors
  75. 75. Engage contributors• Respond quickly
  76. 76. Engage contributors• Respond quickly • Be respectful
  77. 77. Engage contributors• Respond quickly • Be respectful • Provide context
  78. 78. Engage contributors• Respond quickly • Be respectful • Provide context • Encourage them to help
  79. 79. Engage contributors• Respond quickly • Be respectful • Provide context • Encourage them to help • Give them credits (in the change log, on Twitter, etc)
  80. 80. Engage contributors• Respond quickly • Be respectful • Provide context • Encourage them to help • Give them credits (in the change log, on Twitter, etc) • Add frequent contributors as collaborators
  81. 81. Use data
  82. 82. Use data • Common questions
  83. 83. Use data • Common questions • Bug reports
  84. 84. Use data • Common questions • Bug reports • Your time
  85. 85. Use data • Common questions • Bug reports • Your time • Who contributes most
  86. 86. Writing documentation
  87. 87. Writing documentation • Don't put it off till release time
  88. 88. Writing documentation • Don't put it off till release time • Write guide structure first
  89. 89. Writing documentation • Don't put it off till release time • Write guide structure first • Ask others to edit
  90. 90. Writing documentation • Don't put it off till release time • Write guide structure first • Ask others to edit • A complete Getting Started guide is better than 4 unfinished ones
  91. 91. Writing documentation • Don't put it off till release time • Write guide structure first • Ask others to edit • A complete Getting Started guide is better than 4 unfinished ones • Guides reduce amount of time spent doing support
  92. 92. Writing documentation • Don't put it off till release time • Write guide structure first • Ask others to edit • A complete Getting Started guide is better than 4 unfinished ones • Guides reduce amount of time spent doing support • Guides encourage people to contribute by giving them confidence
  93. 93. “But what if I’m no longer interested in maintaining X?”
  94. 94. Pass it on
  95. 95. No matter what you do, don’t release abandonware
  96. 96. ”But who cares, it’s not my problem what the users will do”
  97. 97. Fair enough
  98. 98. But it’s your reputation
  99. 99. Open source is one of the best ways to market yourself as an engineer
  100. 100. Thank you
  101. 101. @michaelklishi nclojurewerkz.or g

×