new file: abcd-how-to-run-an-open-source-project.mdwn
[wiki.git] / talks / 2017 / abcd-how-to-run-an-open-source-project.mdwn
1 On September 8th, 2017 I gave a talk called "How to Run a Successful Open Source Project" at the main meeting of ABCD, the "383rd Consecutive (One After The Othereth) Meeting of the ABCD Committee."
2
3 This was a practice talk for a talk I was giving the next month at JavaOne 2017.
4
5 Norton Allen took the following minutes, which I edited slightly.
6
7 ---
8
9 Unfortunately, Steve could not make it.
10
11 This will be a practice talk for a conference talk I'll be giving
12 next month
13
14 Part I of this series was great, because there was a new project
15 and lots of ideas about how to open source it. This is a project
16 that is 10 years in, so a completely different perspective.
17
18 I want to dig into the title: "How to Run a Successful Open Source
19 Project." We are actually developers, so we're not exactly running
20 it. We participate. As for successful, here's an image showing our
21 26 installations around the world.
22
23 Q: What is the Dataverse?
24
25 A: I'm glad you asked that. It's a tool for hosting data. 3 of the dots on the map, including Harvard, offer an open invitation for people to post data. Others are private. We've had dataverse.nl and dataverse.no. It would be great if every country had a dataverse installation. You can also think of it as a Java EE Project using GlassFish.
26
27 Agenda:
28
29 - build the right thing
30 - presenting your project to the world
31 - culture
32 - encouraging contribution
33 - challenges
34
35 Build the right thing
36
37 - User experience (UX) is key
38 - "The Design of Everyday Things" by Don Norman is a great book.
39 - "Open Source Design" is a great group with an active forum
40 - Also wanted to plug an IT Academy class on UX, Dorian Freeman and Mike Lawrence
41
42 - Make your users awesome, feel their pain
43 - You should be making people better at their jobs, that they are better researchers or archivers
44 - Badass: Making Users Awesome by Kathy Sierra
45 - Sense & Respond by Jeff Gothelf & Josh Seiden
46 - Social Architecture: Building On-line Communities by Pieter Hintjens
47
48 Project Website
49
50 - Everyone is going to have a project website
51 - Everyone will want to know "what does your product do?"
52 - There may be multiple audiences
53 - Users may want to see a roadmap as to where the project is going
54  - What's in the next release or the current sprint
55 - Can they have influence? Will bugs I report be fixed?
56 - Who is using the product?
57
58 "I'm not dead": You want to make it clear that things are happening
59
60 Producing Open Source Software: How to run a successful free software project
61
62 - Talks a lot about the issue tracker
63 - Somewhat controversial quote:
64   - "The higher the number of bugs in the database, the better the software looks"
65 - Look at the bug tracker first when evaluating a project. The question is how they manage and organize incoming bug reports
66
67 - Commit history is also relevant. Another quote: less about meeting deadlines, more about active community.
68
69 GitHub survey: What is important to people?
70
71 - Security: Stability and Security are super important
72 - User experience is somewhat important
73 - Support is dead last
74
75 I find this curious, because users need support. I think it's important to let people know the level of support you offer. Also let them know what you are not supporting. We have community supported code.
76
77 Documentation
78
79 - 93% of people reported being frustrated with incomplete documentation. "Free Software is Suffering because Coders don't know how to write documentation"
80
81 - We have 6 different guides for Dataverse. You should find someone who does know how to write documentation.
82
83 Q: Did the survey indicate what type of documentation people were missing?
84
85 A: I don't know, I'll check
86
87 - Executable Documentation
88   - Scripts to do the installation that sys admins can translate into Puppet or Chef or whatever
89
90 Design the community you want
91
92 - Matthew Turk "How to scale code in a human dimension"
93   1: Listening
94   2: Transparency
95
96 Listening
97
98 - We have periodic community meetings. It's a great high-bandwidth way to exchange information. For a year and a half we have been having community calls. We give a brief update and then open the floor. I make a point to take notes.
99
100 Usability testing
101
102 - Evangelism: We have group members who go to conferences. We're in the business of scholarly publishing.
103 - Nuggets: key ideas from a conversation that we add to the database.
104
105 Transparency:
106
107 - Ned Batchelder: EdX It can be scary to have your work on display, but for some it is exciting
108 - We post our strategic goals on the web site
109 - Multiple public communication channels
110   - IRC channel that is logged publicly
111   - bi-weekly community call
112   - GitHub Issues: GitHub is fairly low friction, since many people already have an account
113
114 "Maximize the value of your keystrokes"
115
116 - Think of all the emails you write: If you instead wrote a blog post, it would go to a broader audience.
117
118 Hope vs Reality
119
120 - We are trying to communicate with very busy people
121
122 Transparency in the dev process
123
124 - Travis CI shows which branches are passing or failing
125   - We also have a code coverage button on our readme, and it's red because our coverage isn't high enough, but I think that encourages us to improve.
126
127 - Encouraging Contribution
128   - Tweet: When you're excited to contribute to an open source project, but then you start looking at the code
129
130 Attention, not just code
131
132 - The true currency of OS projects is attention. When users contribute,they benefit from attention even if their submission is not accepted.
133 - Feedback from our community meeting was that the community wants to help. We have a long list of issues, but need to organize them. We organize by roles.
134 - Use pull requests for everyone, internal or external.  Everything goes through code review.
135 - Can invite contributors as read only members of our GitHub Org and then assign issues to them.
136
137 The hard stuff
138
139 - Money, grant funding. Work on the grant has to take some priority over random feature requests. We had a user suggest a feature, and I said "sure, send us a pull request," and he did, and it was huge. It's over a year old, and I doubt we'll get to it soon, because we weren't ready. 
140 - Hackathons are hard, so you need to be ready.
141
142 Q: I come from the waterfall world: do you have formal sprints?
143 A: Yes
144
145 Q: How do you decide what goes into sprints?
146 A: Backlog grooming. Waffle (tied into GitHub Issues), KanBan board
147
148 Q: Are external contributions tied into your sprints?
149 A: Not directly, it's mostly for the internal teams, but we do try to reserve time for dealing with pull requests.