So you’ve released an open source project to the world, people are using it …the hard part is done, right? No, far from it. Open sourcing a project is only a fraction of the effort that will go into it over time. Come to this talk to earn how to triage and determine levels of support for issues that come into your projects (open source users are customers!). Also learn how to handle when something goes wrong – whether it is with your own project or an upstream project two levels up from yours. Walk away knowing how to handle the hardest (and most rewarding) parts of open source governance.

1. Open Source Governance:
The Hard Parts
DevOpsDays Vancouver 2017
Nell Shamrell-Harrington
@nellshamrell

2. What do you think of when
you hear
Open Source?

3. What makes a project
Open Source?

4. Open Source Governance - The Hard Parts @nellshamrell

5. Uploading a project to
Github is easy…

6. Successfully governing
a project is much harder

7. Technical and
communication skills are
intertwined

8. Parts of open source that
touch both technology and
humanity are the hardest…

9. …but they are also
the most vital

10. Successful Open Source
governance is never
easy, but it is possible

11. @nellshamrellOpen Source Governance - The Hard Parts
• Sr. Software Engineer at Chef Software
• Open Source Contributor and Maintainer
• Supermarket
• Habitat
• @nellshamrell
• nshamrell@chef.io
Nell Shamrell-Harrington

12. Duties of
Open Source Governance

13. @nellshamrellOpen Source Governance - The Hard Parts
• Make it easy to contribute
Duties of Open Source Governance

14. @nellshamrellOpen Source Governance - The Hard Parts
• Make it easy to contribute
• Assist users of the project
Duties of Open Source Governance

15. @nellshamrellOpen Source Governance - The Hard Parts
• Make it easy to contribute
• Assist users of the project
• Manage contributions to the project
Duties of Open Source Governance

16. First Duty:
Make it easy to
contribute

17. Open Source Governance - The Hard Parts @nellshamrell

18. Open Source Governance - The Hard Parts @nellshamrell

19. But what happens
between these two steps?
(Hint: a lot)

20. @nellshamrellOpen Source Governance - The Hard Parts
• Setting up a development environment
Hard parts

21. @nellshamrellOpen Source Governance - The Hard Parts
• Setting up a development environment
• Testing changes
Hard parts

22. “Just don’t use x”
is the wrong answer

23. Use a virtual
workstation

24. Open Source Governance - The Hard Parts @nellshamrell

25. Open Source Governance - The Hard Parts @nellshamrell

26. Open Source Governance - The Hard Parts @nellshamrell
User Workstation
Vagrant
Development
Environment
$ vagrant ssh

27. Open Source Governance - The Hard Parts @nellshamrell

28. Open Source Governance - The Hard Parts @nellshamrell

29. Open Source Governance - The Hard Parts @nellshamrell
User Workstation
Docker
Container
Development
Environment
$ docker run

30. You must support
the development
environment

31. After making
a change…

32. Comes testing
that change…

33. Use a continuous
integration environment
for testing

34. Open Source Governance - The Hard Parts @nellshamrell

35. Open Source Governance - The Hard Parts @nellshamrell

36. Consistent development
and testing environments
are hard, but possible

37. Second Duty:
Assist users of the
project

38. Open Source Governance - The Hard Parts @nellshamrell

39. @nellshamrellOpen Source Governance - The Hard Parts
• Replicating an issue
Hard parts

40. @nellshamrellOpen Source Governance - The Hard Parts
• Replicating an issue
• Dealing with an upstream issue
Hard parts

41. How do you replicate
an issue in a different
environment?

42. Open Source Governance - The Hard Parts @nellshamrell

43. Open Source Governance - The Hard Parts @nellshamrell

44. What might be obvious to
a maintainer is not
always obvious to a user

45. What if the issue is
actually with an
upstream project?

46. If it manifests in
your project, it is
your problem

47. @nellshamrellOpen Source Governance - The Hard Parts
• Communicate it to the maintainers of
the upstream project
Dealing with an upstream issue

48. @nellshamrellOpen Source Governance - The Hard Parts
• Communicate it to the maintainers of the
upstream project
• Communicate it to the person(s) who
filed the issue
Dealing with an upstream issue

49. @nellshamrellOpen Source Governance - The Hard Parts
• Communicate it to the maintainers of the
upstream project
• Communicate it to the person(s) who
filed the issue
• Update the issue in your project
regularly with progress
Dealing with an upstream issue

50. If the upstream maintainer
does not fix the issue,
change the dependency

51. Replicating bugs and
upstream issues are
hard, but possible

52. Third Duty:
Managing contributions
to the project

53. @nellshamrellOpen Source Governance - The Hard Parts
• Determining whether a contribution
adds value
Hard parts

54. @nellshamrellOpen Source Governance - The Hard Parts
• Determining whether a contribution adds
value
• Saying no when it does not
Hard parts

55. What adds value?

56. @nellshamrellOpen Source Governance - The Hard Parts
• Documentation (please!)
Add Value

57. @nellshamrellOpen Source Governance - The Hard Parts
• Documentation (please!)
• Typo fixes
Add Value

58. @nellshamrellOpen Source Governance - The Hard Parts
• Documentation (please!)
• Typo fixes
• Small bug fixes
Add Value

59. What does not
add value?

60. @nellshamrellOpen Source Governance - The Hard Parts
• Whitespace changes
Does Not Add Value

61. @nellshamrellOpen Source Governance - The Hard Parts
• Whitespace changes
• Large features (without talking to the
maintainer first)
Does Not Add Value

62. What sometimes
adds value?

63. @nellshamrellOpen Source Governance - The Hard Parts
• Small features (less than100 lines non-
test code)
Sometimes Add Value

64. @nellshamrellOpen Source Governance - The Hard Parts
• Small features (less than100 lines non-
test code)
• Large features (if you talk to the
maintainer first)
Sometimes Add Value

65. How do you tell whether
something adds value?

66. @nellshamrellOpen Source Governance - The Hard Parts
• Does it fix an existing issue?
How do you tell if it adds value?

67. @nellshamrellOpen Source Governance - The Hard Parts
• Does it fix an existing issue?
• Does it replicate work done
elsewhere?
How do you tell if it adds value?

68. @nellshamrellOpen Source Governance - The Hard Parts
• Does it fix an existing issue?
• Does it replicate work done elsewhere?
• Does it affect in progress work?
How do you tell if it adds value?

69. A contribution returns
negative value when it makes
other contributions harder.

70. When it does not
add value, communicate
and be supportive

71. Open source projects
live and die by
community engagement

72. Always, always,
always say thank you

73. Always, always,
always say why

74. Determining value and
communicating is hard,
but it is possible

75. Parts of open source that
touch both technology and
humanity are the hardest…

76. …but they are also
the most vital

77. Successful Open Source
governance is never
easy, but it is possible

78. Thank You

79. @nellshamrellOpen Source Governance - The Hard Parts
• Sr. Software Engineer at Chef Software
• Open Source Contributor and Maintainer
• Supermarket
• Habitat
• @nellshamrell
• nshamrell@chef.io
Nell Shamrell-Harrington