fix bullets
[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 - Make your users awesome, feel their pain
42 - You should be making people better at their jobs, that they are better researchers or archivers
43 - Badass: Making Users Awesome by Kathy Sierra
44 - Sense & Respond by Jeff Gothelf & Josh Seiden
45 - Social Architecture: Building On-line Communities by Pieter Hintjens
46
47 Project Website
48
49 - Everyone is going to have a project website
50 - Everyone will want to know "what does your product do?"
51 - There may be multiple audiences
52 - Users may want to see a roadmap as to where the project is going
53  - What's in the next release or the current sprint
54 - Can they have influence? Will bugs I report be fixed?
55 - Who is using the product?
56
57 "I'm not dead": You want to make it clear that things are happening
58
59 Producing Open Source Software: How to run a successful free software project
60
61 - Talks a lot about the issue tracker
62 - Somewhat controversial quote:
63   - "The higher the number of bugs in the database, the better the software looks"
64 - Look at the bug tracker first when evaluating a project. The question is how they manage and organize incoming bug reports
65 - Commit history is also relevant. Another quote: less about meeting deadlines, more about active community.
66
67 GitHub survey: What is important to people?
68
69 - Security: Stability and Security are super important
70 - User experience is somewhat important
71 - Support is dead last
72
73 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.
74
75 Documentation
76
77 - 93% of people reported being frustrated with incomplete documentation. "Free Software is Suffering because Coders don't know how to write documentation"
78 - We have 6 different guides for Dataverse. You should find someone who does know how to write documentation.
79
80 Q: Did the survey indicate what type of documentation people were missing?
81
82 A: I don't know, I'll check
83
84 - Executable Documentation
85   - Scripts to do the installation that sys admins can translate into Puppet or Chef or whatever
86
87 Design the community you want
88
89 - Matthew Turk "How to scale code in a human dimension"
90   1: Listening
91   2: Transparency
92
93 Listening
94
95 - 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.
96
97 Usability testing
98
99 - Evangelism: We have group members who go to conferences. We're in the business of scholarly publishing.
100 - Nuggets: key ideas from a conversation that we add to the database.
101
102 Transparency:
103
104 - Ned Batchelder: EdX It can be scary to have your work on display, but for some it is exciting
105 - We post our strategic goals on the web site
106 - Multiple public communication channels
107   - IRC channel that is logged publicly
108   - bi-weekly community call
109   - GitHub Issues: GitHub is fairly low friction, since many people already have an account
110
111 "Maximize the value of your keystrokes"
112
113 - Think of all the emails you write: If you instead wrote a blog post, it would go to a broader audience.
114
115 Hope vs Reality
116
117 - We are trying to communicate with very busy people
118
119 Transparency in the dev process
120
121 - Travis CI shows which branches are passing or failing
122   - 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.
123 - Encouraging Contribution
124   - Tweet: When you're excited to contribute to an open source project, but then you start looking at the code
125
126 Attention, not just code
127
128 - The true currency of OS projects is attention. When users contribute,they benefit from attention even if their submission is not accepted.
129 - 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.
130 - Use pull requests for everyone, internal or external.  Everything goes through code review.
131 - Can invite contributors as read only members of our GitHub Org and then assign issues to them.
132
133 The hard stuff
134
135 - 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. 
136 - Hackathons are hard, so you need to be ready.
137
138 Q: I come from the waterfall world: do you have formal sprints?
139 A: Yes
140
141 Q: How do you decide what goes into sprints?
142 A: Backlog grooming. Waffle (tied into GitHub Issues), KanBan board
143
144 Q: Are external contributions tied into your sprints?
145 A: Not directly, it's mostly for the internal teams, but we do try to reserve time for dealing with pull requests.