El documento habla sobre la responsabilidad en el desarrollo de software libre. Explica que los desarrolladores deben asegurarse de que los usuarios no se enojen por cambios inesperados o falta de soporte. Recomienda tener una buena documentación, lista de correo, canal IRC y facilitar las contribuciones para mantener contentos a los usuarios y la comunidad.

1. Open source
responsibly
It takes less time than you think
sábado, 28 de septiembre de 13

2. About me
sábado, 28 de septiembre de 13

3. About me
@michaelklishin
sábado, 28 de septiembre de 13

4. About me
sábado, 28 de septiembre de 13

5. About me
clojurewerkz.org
sábado, 28 de septiembre de 13

6. About me
Ex-Travis CI
core
sábado, 28 de septiembre de 13

7. About me
sábado, 28 de septiembre de 13

8. About me
data processing
and analytics
sábado, 28 de septiembre de 13

9. About me
dozen of programming
languages, <3 ƛ
sábado, 28 de septiembre de 13

10. About me
recognized animated
gifs expert
sábado, 28 de septiembre de 13

11. About this talk
sábado, 28 de septiembre de 13

12. sábado, 28 de septiembre de 13

13. sábado, 28 de septiembre de 13

14. sábado, 28 de septiembre de 13

15. More open source producers
sábado, 28 de septiembre de 13

16. Many more open source
consumers
sábado, 28 de septiembre de 13

17. Responsibility
sábado, 28 de septiembre de 13

18. 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
sábado, 28 de septiembre de 13

19. You develop a library…
sábado, 28 de septiembre de 13

20. Someone starts using it…
sábado, 28 de septiembre de 13

21. sábado, 28 de septiembre de 13

22. It changes over time…
sábado, 28 de septiembre de 13

23. Responsible maintainer
makes sure the users
aren’t angry
sábado, 28 de septiembre de 13

24. sábado, 28 de septiembre de 13

25. sábado, 28 de septiembre de 13

26. Why can they be angry?
sábado, 28 de septiembre de 13

27. •Incorrect expectations/
assumptions
sábado, 28 de septiembre de 13

28. •Incorrect expectations/
assumptions
•Unexpected changes
sábado, 28 de septiembre de 13

29. •Unexpected changes
•Nobody to help
sábado, 28 de septiembre de 13

30. •Unexpected changes
•Nobody to help
•Too hard to contribute
sábado, 28 de septiembre de 13

31. •Unexpected changes
•Nobody to help
•Too hard to contribute
•Maintainer is an a-hole
sábado, 28 de septiembre de 13

32. Free as in “Fuck you,
I don’t owe you anything!”
sábado, 28 de septiembre de 13

33. Solvable?
sábado, 28 de septiembre de 13

34. Have a helpful README
sábado, 28 de septiembre de 13

35. sábado, 28 de septiembre de 13

36. What does this thing do?
sábado, 28 de septiembre de 13

37. How mature is it?
sábado, 28 de septiembre de 13

38. How do I install it?
sábado, 28 de septiembre de 13

39. What runtimes and/or
versions are supported?
sábado, 28 de septiembre de 13

40. What license does it use?
sábado, 28 de septiembre de 13

41. Where can I get help?
sábado, 28 de septiembre de 13

42. Have a mailing list
sábado, 28 de septiembre de 13

43. Let community members
help you help your users
sábado, 28 de septiembre de 13

44. Have an IRC channel
sábado, 28 de septiembre de 13

45. Helping others earns
their respect
sábado, 28 de septiembre de 13

46. Keep a change log
sábado, 28 de septiembre de 13

47. Keep a useful change log
sábado, 28 de septiembre de 13

48. No, git log is not a change log
sábado, 28 de septiembre de 13

49. sábado, 28 de septiembre de 13

50. Do you write brilliantly
detailed commit messages?
sábado, 28 de septiembre de 13

51. Do you have incredible
discipline?
sábado, 28 de septiembre de 13

52. git log is often hard to interpret
for project outsiders
sábado, 28 de septiembre de 13

53. Provide details for humans
sábado, 28 de septiembre de 13

54. Developer vs. Ops
sábado, 28 de septiembre de 13

55. What’s new?
Developer
sábado, 28 de septiembre de 13

56. How do I use it?
Developer
sábado, 28 de septiembre de 13

57. Will my code break?
Developer
sábado, 28 de septiembre de 13

58. Why was it added?
Developer
sábado, 28 de septiembre de 13

59. Ops
sábado, 28 de septiembre de 13

60. What has changed?
Ops
sábado, 28 de septiembre de 13

61. Will my shit break?
Ops
sábado, 28 de septiembre de 13

62. How do I upgrade?
Ops
sábado, 28 de septiembre de 13

63. Is it urgent to upgrade?
Ops
sábado, 28 de septiembre de 13

64. Post release announcements
sábado, 28 de septiembre de 13

65. Have a project blog
sábado, 28 de septiembre de 13

66. Have a Twitter account
sábado, 28 de septiembre de 13

67. Care about backwards
compatibility
sábado, 28 de septiembre de 13

68. It’s that thing that
Java people do
sábado, 28 de septiembre de 13

69. It prevents…
sábado, 28 de septiembre de 13

70. sábado, 28 de septiembre de 13

71. sábado, 28 de septiembre de 13

72. Document well
sábado, 28 de septiembre de 13

73. sábado, 28 de septiembre de 13

74. sábado, 28 de septiembre de 13

75. “My favorite part about ClojureWerkz
is documentation…”
sábado, 28 de septiembre de 13

76. Documentation breeds trust
sábado, 28 de septiembre de 13

77. sábado, 28 de septiembre de 13

78. sábado, 28 de septiembre de 13

79. Make it easy to contribute
sábado, 28 de septiembre de 13

80. Fuck paper contributor
agreements
sábado, 28 de septiembre de 13

81. Explain the basics of
development process
sábado, 28 de septiembre de 13

82. e.g.“we develop shit on
the develop branch, master
is for stable releases only”
sábado, 28 de septiembre de 13

83. Explain how to install & run
dependencies
sábado, 28 de septiembre de 13

84. travis-ci.org or GTFO
sábado, 28 de septiembre de 13

85. Worst case scenario I can
sniff your .travis.yml
sábado, 28 de septiembre de 13

86. sábado, 28 de septiembre de 13

87. Help beginners help you
sábado, 28 de septiembre de 13

88. sábado, 28 de septiembre de 13

89. sábado, 28 de septiembre de 13

90. sábado, 28 de septiembre de 13

91. sábado, 28 de septiembre de 13

92. Don’t be an asshole
sábado, 28 de septiembre de 13

93. You never know who
the contributor is
sábado, 28 de septiembre de 13

94. sábado, 28 de septiembre de 13

95. sábado, 28 de septiembre de 13

96. “But what if I’m no longer interested
in maintaining X?”
sábado, 28 de septiembre de 13

97. Pass it on
sábado, 28 de septiembre de 13

98. sábado, 28 de septiembre de 13

99. No matter what you do,
don’t release abandonware
sábado, 28 de septiembre de 13

100. ”But who cares, it’s not my
problem what the users will do”
sábado, 28 de septiembre de 13

101. Fair enough
sábado, 28 de septiembre de 13

102. But it’s your reputation
sábado, 28 de septiembre de 13

103. sábado, 28 de septiembre de 13

104. “It sounds too fucking hard”
sábado, 28 de septiembre de 13

105. sábado, 28 de septiembre de 13

106. “Dafuq is open source?”
sábado, 28 de septiembre de 13

107. “You are not getting paid for it?”
sábado, 28 de septiembre de 13

108. sábado, 28 de septiembre de 13

109. sábado, 28 de septiembre de 13

110. Open source is one of the best
ways to market yourself
as an engineer
sábado, 28 de septiembre de 13

111. sábado, 28 de septiembre de 13

112. How do you even find time?
sábado, 28 de septiembre de 13

113. Standardize
sábado, 28 de septiembre de 13

114. sábado, 28 de septiembre de 13

115. • Standard README
sábado, 28 de septiembre de 13

116. • Standard README
• Standard change log format
sábado, 28 de septiembre de 13

117. • Standard README
• Standard change log format
• Standard announcement blog posts
sábado, 28 de septiembre de 13

118. • Standard README
• Standard change log format
• Standard announcement blog posts
• Standard library template (e.g. with
Leiningen)
sábado, 28 de septiembre de 13

119. Automate
sábado, 28 de septiembre de 13

120. Engage contributors
sábado, 28 de septiembre de 13

121. sábado, 28 de septiembre de 13

122. Thank you
sábado, 28 de septiembre de 13

123. @michaelklishin
clojurewerkz.org
sábado, 28 de septiembre de 13