-
Notifications
You must be signed in to change notification settings - Fork 0
/
index.html
670 lines (571 loc) · 48.1 KB
/
index.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Running OSS Projects: From Zero to Sixty</title>
<meta name="description" content="Glimpse, an open source web application diagnostics tool, went from a rough back-of-a-napkin idea to a project with tens of thousands of users and developer media attention within a period of eight weeks.Join Glimpse�s co-founder, Nik Molnar, for an honestly raw tale of the pains and lessons learned that arose managing an open source project. Along the way, Nik will cover the tools and techniques that have proven successful over the past two years developing Glimpse, focusing on technical challenges and best practices for community management, communications and open source/life balance.This session is suitable for founders, maintainers, contributors and all users of open source software and aims to spark conversation around the best way to foster open source and open source etiquette.">
<meta name="author" content="Nik Molnar">
<meta name="apple-mobile-web-app-capable" content="yes" />
<meta name="apple-mobile-web-app-status-bar-style" content="black-translucent" />
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no">
<link rel="stylesheet" href="css/reveal.min.css">
<link rel="stylesheet" href="css/theme/speedy.css" id="theme">
<!-- For syntax highlighting -->
<link rel="stylesheet" href="lib/css/zenburn.css">
<!-- If the query includes 'print-pdf', use the PDF print sheet -->
<script>
document.write( '<link rel="stylesheet" href="css/print/' + ( window.location.search.match( /print-pdf/gi ) ? 'pdf' : 'paper' ) + '.css" type="text/css" media="print">' );
</script>
<!--[if lt IE 9]>
<script src="lib/js/html5shiv.js"></script>
<![endif]-->
<style>
.license{
display: block;
bottom: 10px;
display: none;
position: fixed;
left: 10px;
z-index: 30;
}
.checklist{
list-style-image:url('img/tick.png');
list-style-position: inside;
}
.checklist li{
padding:0.8em;
}
</style>
</head>
<body>
<div class="reveal">
<aside class="license">
<a rel="license" href="http://creativecommons.org/licenses/by-nc-sa/3.0/deed.en_US">
<img alt="Creative Commons License" src="img/cclic.png" />
</a>
</aside>
<!-- Any section element inside of this container is displayed as a slide -->
<div class="slides">
<section>
<h1>Running OSS Projects</h1>
<img src="img/logo.png" class="plain"/>
<h3>From Zero to Sixty</h3>
<p>
<small><a href="http://nikcodes.com">Nik Molnar</a> / <a href="http://twitter.com/nikmd23">@nikmd23</a> / <a href="http://osszerotosixty.com">osszerotosixty.com</a></small>
</p>
<aside class="notes">
Open up:
<ul>
<li><a href="http://www.tldrlegal.com/license/apache-license-2.0-%28apache-2.0%29">http://www.tldrlegal.com/license/apache-license-2.0-%28apache-2.0%29</a></li>
<li><a href="http://bikeshed.com/">http://bikeshed.com/</a></li>
<li><a href="http://ossperks.com/">http://ossperks.com/</a></li>
</ul>
<p><strong>Thank you for attending</strong> the last talk!</p>
<hr />
<p>
<strong>Calibrate the room:</strong>
<ul>How many people maintain an OSS project?</ul>
<ul>How many people contribute to OSS projects on a a monthly basis?</ul>
<ul>How many people are intrested in getting involved in an OSS project?</ul>
</p>
<h4>Keyboard shortcuts:</h4>
<ul>
<li><strong>F</strong> - Full screen</li>
<li><strong>.</strong> - Toggle Blank Screen</li>
<li><strong>Alt + Click</strong> - Zoom on element</li>
<li><strong>S</strong> - Presenter mode</li>
<li><strong>Esc</strong> - Overview mode</li>
</ul>
</aside>
</section>
<section>
<h2>Who Am I?</h2>
<img src="img/mix.jpg" />
<aside class="notes">
<p><strong>My name is Nik Molnar</strong>. I live in NYC. I've been a web dev for a little over 16 years. I cofounded Glimpse</p>
<hr />
<p>
<stong>What is the Glimpse project?</stong>
<ul>
<li>Started to scratch an itch</li>
<li>Gained popularity very quickly with a little help from a Hanselbump</li>
<li>100K downloads and counting, a little over 40 contributors</li>
<li>Full time sponsorship from Redgate software to continue with its development</li>
</ul>
</p>
<hr />
<p>So yes, <strong>I work with the community on OSS for a living, but</strong> that does not mean I have all the answers. I'm trying to find my way like everyone else.</p>
<p>That's the reason that I created this presentation. This is what I wish I had two years ago when we were starting Glimpse. Once again, I'm trying to scratch an itch</p>
<p>A lot of the content has been learned the hard way, by first hand experience. Other parts of the content we were lucky enough to learn from those that came before us, and I've captured the best of that I've learned from others in the past two years as well.</p>
<hr/>
<p><strong>That learning starts with Bruce Wayne Tuckman.</strong></p>
</aside>
</section>
<section>
<h2>Tuckman's Stages</h2>
<img id="tuckmanImg" src="img/btuckman.jpg" style="vertical-align: middle; margin-right:1em; position:relative; left:3em;"/>
<ol id="tuckmanOl">
<li class="fragment">Forming</li>
<li class="fragment">Storming</li>
<li class="fragment">Norming</li>
<li class="fragment">Performing</li>
</ol>
<aside class="notes">
<p><strong>Bruce Wayne Tuckman is a researcher in the theory of group dynamics</strong> and Professor Emeritus at Ohio State University</p>
<hr />
<p>In 1965 he published a theory called "Tuckman's Stages"</p>
<p>Tuckman proposed that <strong>there are four necessary and inevitable phases</strong> in order for a team to grow, to face up to challenges, to tackle problems, to find solutions, to plan work, and to deliver results</p>
<p>
Those phases are:
<ul>
<li>Forming - the period in which a team comes together</li>
<li>Storming - the phase when a team runs into inevitable challenges</li>
<li>Norming - the phase when a team understands the plan and can execute on it</li>
<li>Performing - the phase when individuals on the can begin to anticipate each other</li>
</ul>
</p>
<p><strong>OSS is special</strong> because the team is constantly churning - so there are always people in each of these stages.</p>
<hr />
<p>Let's explore each of these in more detail...</p>
</aside>
</section>
<section>
<section>
<h1>Forming</h1>
<img src="img/forming.png" class="plain"/>
<aside class="notes">
<p>The first phase, is forming</p>
<p>While Forming, serious issues are avoided, and people focus on being busy with meta work, such as organizing the team, deciding who does what, where the code lives, etc.</p>
<p>I've pulled together three points to consider while forming, and perhaps the most important one for an OSS project is the thing that makes a project OSS in the first place: it's license</p>
<h3 style="background-color: red;">GO DOWN!</h3>
</aside>
</section>
<section>
<h2>Select a License</h2>
<img src="img/licenses.png" class="plain" />
<h4><a href="http://www.tldrlegal.com/">tl;dr Legal</a> to the rescue!</h4>
<aside class="notes">
<p>Selecting a license can be daunting. (Probably best not to create your own!) But it is important to set the tone for how the project can be distributed ASAP.</p>
<p>Contributors and users may be attracted (or repeled) to a project based on it's license. So choose carefully based on your target audience</p>
<p><strong>Story Time</strong> For the 1st release of Glimpse we chose a Creative Commons license - simply because we didn't know any better and they had a nice license landing page.</p>
<p>Unfortunately, as Phil Haack pointed out to us, CC licenses are better suited for content, and he suggested we take a look at the Apache 2 license.</p>
<p>To figure out which license is right for you, be sure to select one from <a href="http://opensource.org/">OpenSouce.org</a> since their licenses all comply with the <a href="http://opensource.org/osd">Open Source Definition</a>, which defines 10 tenants of a truly open source license.</p>
<p>tldrlegal.com really comes in handy for gaining a quick overview of a licenses and for comparing a license</p>
<p><strong>Demo Apache 2 on tldrlegal</strong></p>
<hr/>
<p>Contributors License Agreements are another type of license you may want to consider for your project.</p>
<p>CLA's are agreements that contributors to a project sign turning over their copy write to the project</p>
<p>If you are asked to sign one, do not be alarmed - they are fairly common</p>
<p>Glimpse has one, also at the suggestion of Phil Haack and it has served as well since Redgate asked about copy write when they sponsored the project</p>
<p>CLA's are less organized/categorized than standard licenses, but typically come in flavors for individuals and corporations</p>
<p>Try to use a CLA template like the one available from the Apache Foundation to simplify the process for contributors.</p>
<hr/>
<p>Once licensing has been figured out, there are some fairly standard tasks that need to be completed</p>
</aside>
</section>
<section>
<h2>Project Setup</h2>
<ul class="checklist">
<li class="fragment">Website</li>
<li class="fragment">Mission Statement</li>
<li class="fragment">Contributor Guidelines</li>
<li class="fragment">Screenshot/Demo</li>
<li class="fragment">Consider Forkability</li>
</ul>
<aside class="notes">
<p>OSS projects need a website. Websites provide a lot more info than just what your repository or package feed can cover.</p>
<p><strong>Story time</strong> We learned this lesson the hard way from Scott Hanselman, who demanded that we have a website for Glimpse before he would blog about it. I stayed up until 4:00 AM cranking out the 1st Glimpse website on Tumblr.</p>
<p>The website is often the first impression that a user has of the project, so take some care to get a decent template. It can be simple, but should be pleasant to use.</p>
<p>As a user should feel free provide feedback on the website as well. Often the website is open source itself so it can be contributed to.</p>
<hr />
<p>Mission statement/readme.md that expresses the goals of the project and what it will/won't do</p>
<p>scriptcs has a nice simple mission statement: <q>scriptcs makes it easy to write and execute C# with a simple text editor</q>. It's concise and to the point.</p>
<hr />
<p>Contributor guidelines should be available to to inform developers how to get the source, build the source and submit pull requests. Be sure to cover any conventions or standards used within the project.</p>
<p>If your looking to contribute to a project - be sure to look for this!</p>
<p>Contributor guidelines are so important to open source that GitHub has <a href="https://github.com/blog/1184-contributing-guidelines">built in support for them</a> via the contributing.md file</p>
<hr />
<p>Demo/screenshots have always been a recommended best practice for commercial projects, and the same holds true for OSS</p>
<p><strong>Story time</strong> The 4:00 AM YouTube video of Glimpse had 50K views and dramatically helped people grok the concept behind glimpse</p>
<hr />
<p>Forkability, a term coined by Karl Fogel of the SVN project, is the ease of which a developer <em>could</em> fork the project. Forkability also makes it easy for them to grab the code, build it and get started.</p>
<p>Some companies wearing the fact that they can get a new hire to deploy to production on their first day on the job as a badge of honor. How long does it take to get a new contributor up and running in a OSS project is a measure of its forkability.</p>
<p>To make a codebase forkable:</p>
<ul>
<li>Keep as many dependencies in source control/package restore as possible</li>
<li>Single command build process</li>
<li>Built in samples</li>
<li>Developer documentation</li>
<li>Forkability helps to ensure distributed leadership</li>
</ul>
<hr />
<p>Because a fork could produce a pull request or a competitor - forkability keeps maintainers honest and working for the good of the project</p>
<p>Honesty and transparency are also fundamental tenants of governance models</p>
</aside>
</section>
<section>
<h2>Selecting a Governance Model</h2>
<div class="fragment fade">
<img src="img/man_brown.png" class="fragment fade plain" style="margin-top:100px;"/>
<img src="img/arrow.png" class="fragment fade plain" style="vertical-align: super;"/>
<img src="img/man_red.png" class="fragment fade plain"/>
<img src="img/arrow.png" class="fragment fade plain" style="vertical-align: super;"/>
<img src="img/man_blue.png" class="fragment fade plain"/>
<img src="img/arrow.png" class="fragment fade plain" style="vertical-align: super;"/>
<img src="img/man_grey.png" class="fragment fade plain"/>
<h3 style="margin-top:100px;">Meritocratic Model @ <a href="http://www.oss-watch.ac.uk/resources/meritocraticGovernanceModel">OSS Watch</a></h3>
</div>
<aside class="notes">
<p>Defining a governance models for a project is important to help orient users with the way to interact with given project's community</p>
<p>There are many different governance models, mostly ad hoc, and two particularly famous ones: benevolent dictator and meritocratic method</p>
<p>Benevolent dictator is the model that Linus Torvolds and the Linux team leverage. I personally am not a huge fan of this model, but it clearly does work</p>
<p>For today I am going to focus on the meritocratic method, because that's the one I have experience with</p>
<p>I though I knew what the meritocratic method was since so many project claim that they work in tht model - but I was shocked to find that there is well written governance documents by OSS-Watch which explains all the ins and outs in full details</p>
<p>I'm going to quickly recap by covering the Roles and decision making process</p>
<hr />
<p><strong>Users</strong> are people who actually need the project. They are the most important members of the community and without them the project would have no purpose. Obviously anyone can be a user; there are no special requirements. Users provide feedback, word of mouth evangelism, moral and sometimes financial support.</p>
<p><strong>Contributors</strong> are community members who contribute in concrete ways to the project. Anyone can become a contributor, and contributions can take many forms such as support, reporting bugs, identifying requirements, providing graphics and web design, writing documentation, fixing bugs, adding features</p>
<p><strong>Committers</strong> are community members who have shown that they are committed to the continued development of the project through ongoing engagement with the community. Committership allows contributors to more easily carry on with their project related activities by giving them direct access to the project's resources. That is, they can make changes directly to project outputs, without having to submit changes via patches. A committer seeks approval after the contribution is made, rather than before. They must be nominated.</p>
<p><strong>Reviewers</strong> consists of those individuals identified as "project owners". The reviewers have additional responsibilities over and above those of a committer. These responsibilities ensure the smooth running of the project. Reviewers are expected to review code contributions, participate in strategic planning, approve changes to the governance model and manage the copyrights within the project outputs. They must be nominated.</p>
<hr />
<p>A meritocracy is not a democracy; that is, not everyone has a binding vote. Only those who have earned it through positive contribution to the project have a binding vote.</p>
<p>There are a full set of rules for which decisions require which type of vote when a concensus can't be naturally achieved - check them out on OSS Watch</p>
<p>Contributors should get acquainted with the governance model and try to act accordingly</p>
<hr />
<p>Once a project is setup and relatively well formed, it will begin to enter into the 2nd of Tuckman's stages.</p>
</aside>
</section>
</section>
<section>
<section>
<h1>Storming</h1>
<img src="img/storming.png" class="plain" />
<aside class="notes">
<p>OSS is built by humans, and as humans we will have conflicts. Ideas begin to compete with each other. Personalities (and egos!) begin to battle. Architectural challenges and bugs begin to crop up</p>
<p>The storming stage is necessary for the growth of the project. It can be contentious, unpleasant and painful, but projects that make it past this stage come out stronger.</p>
<p>Here's a list of common challenges facing OSS projects and some tips for avoiding them.</p>
<h3 style="background-color: red;">GO DOWN!</h3>
</aside>
</section>
<section>
<h2>Communication</h2>
<div id="comms" style="height:550px;">
<div class="fragment fade">
<div class="fragment fade-out" data-replace="#comms div[data-fragment-index='1']">
<img src="img/incoming.png" class="plain" />
<h3>Incoming</h3>
</div>
</div>
<div class="fragment fade">
<div class="fragment fade-out" data-replace="#comms div[data-fragment-index='3']">
<img src="img/outgoing.png" class="plain" />
<h3>Outgoing</h3>
</div>
</div>
<div class="fragment fade">
<div class="fragment fade-out" data-replace="#comms div[data-fragment-index='5']">
<img src="img/internal.png" class="plain" />
<h3>Internal</h3>
</div>
</div>
</div>
<aside class="notes">
<p>It should be no surprise to see the communications is the first challenge to discuss within OSS projects.</p>
<p>Good and proper communication is the most important part of managing an OSS project. Lack of good communication can cause a project to break down and lose contributors. Communications can be broken into three channels.</p>
<hr/>
<p><strong>Incoming</strong> from Forums, Mailing Lists, Issue Trackers, etc. Receiving and processing feedback and viewpoints for the purpose of improvement. An
example of this could include surveys to determine how well a part of your community
is working.</p>
<p><strong>Outgoing</strong> to blogs and social media. Sharing news, stories, and achievements from the community with the rest of the world.
An example of this could be showing off something your community has created.</p>
<p><strong>Internal</strong> with HipChat, Trello and Skype should be used sparingly. Internal discussions and meetings in the community to discuss objectives, goals, conflict,
and other issues. An example of this could include meetings that are designed to decide
how your community will work together toward its goals.</p>
<p>In general, it's best to avoid private/internal communications - save your breath and keystrokes for more productive purposes</p>
<hr />
<p>Once you have settled on <em>where</em> to communicate it's important to understand <em>how</em> to communicate.</p>
</aside>
</section>
<section>
<h2>Nom de plume</h2>
<img src="img/dog.jpg" />
<aside class="notes">
<p>the only thing anyone knows about you on the Internet comes from what you write, or what others write about you. You are your nom de plume, you are your pen - or keyboard in this case.</p>
<p>You may be brilliant, perceptive, and charismatic in person�but if your emails are rambling and unstructured, people will assume that's the real you. You could be a dog - and know one will know as long as your eloquent, thoughtful and well spoken</p>
<p>So here's just a few quick tips for users, contributors reviewers and the like. They <em>shouldn't</em> need repeating, but in my experience, they do</p>
<hr />
<p>Your avatar and handle are your face - try to be consistent</p>
<p>User proper grammar, spelling and punctuation</p>
<p>Consider subject/title lines carefully</p>
<p>Use a diagram if it will help! (<a href="http://www.asciiflow.com/">AsciiFlow</a> & <a href="http://www.websequencediagrams.com/">WebSequenceDiagrams</a> & <a href="http://www.memofon.com/">Memofon</a>)</p>
<p>Provide context! Use a link to another thread or an issue . Make it easy for the reader</p>
<p>Watch your tone</p>
<hr />
<p>Even well meaning, properly placed communications do no good if they aren't actually helping the project to progress forward. It is important to keep progress in mind while communicating, and one common enemy of progress it a technique called bikeshedding.</p>
</aside>
</section>
<section>
<h2>Avoid Bikeshedding</h2>
<video data-autoplay src="img/bikeshed.mp4" autoplay="autoplay" loop="true"></video>
<h3>Fwd <a href="http://bikeshed.com">bikeshed.com</a></h3>
<aside class="notes">
<p>In his 1957 book <em>Parkinson's Law, and Other Studies in Administration</em>, Cyril Northcote Parkinson introduced "Parkinson's law of triviality" which states:</p>
<p><strong>the amount of noise generated by a change is inversely proportional to the complexity of the change</strong></p>
<p><strong>Story Time</strong>Parkinson dramatizes this law with the example of a committee's deliberations on building an atomic power plant, contrasting it to deliberations on building a bicycle shed.</p>
<p>The reason this happens is because people want to prove that they are involved and to "put their fingerprints on something" so that one day they can walk by and say "I built that".</p>
<p>Unfortunately whats really happening is that the community is toiling in minor issues while there are larger, higher priority problems to tackle</p>
<hr />
<p>In 1999 Poul-Henning Kamp applied Parkinson's law to the OSS FreeBSD project in an email to the projects mailing list. He said:</p>
<p>"Why Should I Care What Color the Bikeshed Is? The really, really short answer is that you should not. The somewhat longer answer is that just because you are capable of building a bikeshed does not mean you should stop others from building one just because you do not like the color they plan to paint it. This is a metaphor indicating that you need not argue about every little feature just because you know enough to do so. Some people have commented that the amount of noise generated by a change is inversely proportional to the complexity of the change."</p>
<p>Kamp's email is available at bikeshed.com - send it to the member of your community and make them aware of the concept and your desire to avoid it. Encourage them to point out the behavior when they see it as well.</p>
<hr />
<p>Besides communication challenges OSS projects face many of the same challenges as marriages and other relationships. We all know that finances can put huge stress on a marriage - the same goes for OSS projects.</p>
</aside>
</section>
<section>
<h2>Dealing w/ $$$</h2>
<img src="img/money.jpg" />
<aside class="notes">
<p>Finances can be the biggest cause of strain on any relationship, including the relationship between an open source team.</p>
<p>We were lucky with Glimpse because we were tested with money very early on.</p>
<p><strong>Story Time</strong>At Mix we were offered 10K to close and sell the source, which forced us to evaluate why we really did Glimpse.</p>
<p>We decided to back pay our bills first, and spend anything left over on thank you swag for contributors</p>
<hr />
<p>On the other side of the spectrum, some projects can't stay afloat because their maintainers can't afford to pay any bills that may be associated with the project. If you enjoy using an OSS product, and don't have the time to get involved in the effort, consider donating $$.</p>
<p>Check to make sure they have a plan for the cash first, to avoid the situation that Jeff Atwood had with his 5K donation to screwturn wiki</p>
<hr />
<p>And finally, for the last challenge I've personally experienced, I wanted to talk about OSS/Life Balance</p>
</aside>
</section>
<section>
<h2>OSS/Life Balance</h2>
<img src="img/hope.jpg" />
<aside class="notes">
<p>Congrats - you have a new baby boy for a project. You're so proud, people are using it and it's going to be awesome. Light a cigar and celebrate</p>
<p>People use this analogy of the "parents" of a project. And children can be a real joy and sense of pride in a parents life.</p>
<p>But along with that pride and joy comes dirty diapers and a lot of work.</p>
<p>With OSS there is a lot of pressure to fix bugs, support users, grow community, make it better, etc</p>
<p>What makes it worse is that the number of issues in a project's bug tracker grows in proportion to the number of people using the software. Therefore, even as you fix bugs and ship an increasingly robust program, you should still expect the number of open issues to grow essentially without bound.</p>
<p>I wrestled mightily with this. Working all weekend to ensure I didn't miss a "deadline". Making sure there was a plan to fix everybug. Answering every support question that came in. Crying myself to sleep.</p>
<p>I don't have a clever well thought out approach or tip here. I'm just being honest and wanted to leave you with encouragement.</p>
<p>I just want to remind you that OSS isn't life. There are more important things out there. Don't take yourself so seriously. Remember why you started OSS in the first place.</p>
<hr />
<p>The good news is, if you can make it out of the storming phase, things really start to get fun during Tuckman's 3rd stage: Norming</p>
</aside>
</section>
</section>
<section>
<section>
<h1>Norming</h1>
<img src="img/norming.png" class="plain" />
<aside class="notes">
<p>When teams are norming the have a clear goal and a mutual agreement for the plan of execution.</p>
<hr />
<p>Once the plan of execution is in place, it's fairly normal to begin to see a shift from development work to community management work.</p>
<h3 style="background-color: red;">GO DOWN!</h3>
</aside>
</section>
<section>
<h2>Community Management</h2>
<img src="img/cats.jpg" />
<aside class="notes">
<p>Once the project has gotten setup and gone through its first round of problems, the software will be the easy part, getting people aligned and "herding cats" is the challenge</p>
<p>First, you'll want to treat every user as a potential volunteer. String them along the process building an on ramp for them if possible.</p>
<hr />
<p>To manage the community, you want to keep in mind two things: focus and attention</p>
<p>Focus the community to be working on the task at hand. Defining milestones helps with this.</p>
<p>Bring attention to the focused efforts of the community. We like to do this with town hall meetings on Google Hangouts where we ask contributors to show off their recent work</p>
<p>One way to really help yourself with support is to try to not pull the team off their goals too much. Be mindful of support requests. Give back the help you receive.</p>
<hr />
<p>Meeting in person, or less so on Skype, also really strengthens a community. There is something about breaking bread together and sharing a few drinks that really helps the bonding process</p>
<p><strong>Story Time</strong> We met a user in Brussels recently - he had never contributed to an OSS project before. But after a few hours and lots of laughs we had built up a repore that continues virtually over the internet now. He's quickly becoming one of our top contributors within a short time span.</p>
<hr />
<p>Another nice thing about the norming phase is that once a project is decently established, it can usually begin to enjoy some of the perks that are provided by vendors in the industry</p>
</aside>
</section>
<section>
<h2>Perks</h2>
<img src="img/vendors.png" class="plain" />
<h3>Find more <a href="http://ossperks.com">OSSPerks.com</a></h3>
<aside class="notes">
<p>So we are very lucky to have Redgate sponsoring our salaries as we do development</p>
<p>While you may not have a company sponsoring all the costs to develop a project, there are plenty that are willing to help.</p>
<p><strong>Story Time</strong> Leveraging the sponsorships that are out there feels a bit like being Tony Hawk coding around with these companies helping you to do what you do best.</p>
<p>The Glimpse team leverages generous donations from these companies, but there are many more available with a listing on ossperks.com - a site which I launched this past weekend</p>
<hr />
<p>Once the community is humming along and tooling is in place, you'll find that your project team can really start performing</p>
</aside>
</section>
</section>
<section>
<section>
<h1>Performing</h1>
<img src="img/performing.png" class="plain" />
<aside class="notes">
<p>When a team is performing, the individuals function as a unit without the need for heavy management oversight.</p>
<hr />
<p>Now, there are a few things that can be done to reduce management oversight and to begin performing earlier. The first of which is to automate everything.</p>
<h3 style="background-color: red;">GO DOWN!</h3>
</aside>
</section>
<section>
<h2>Automate Everything</h2>
<img src="img/automation.png" />
<aside class="notes">
<p>Managing your project and the project's community takes time. Lot's of time. Simplify your life and let the robots help you</p>
<p>This is where perks really start to shine: enforce build and test procedures with a CI server</p>
<p>Enforce style and naming conventions automatically instead of with a document via tools like StyleCop</p>
<p>Auto test pull requests and leverage <a href="https://github.com/blog/1227-commit-status-api">GitHub's commit status API</a> - built into TeamCity and TravisCI</p>
<p><strong>Story Time</strong> Story of how user's automatically fix pull requests now without our involvement</p>
<p>Automation can also be as simple as opening up your documentation contribution process. We leverage Glimpse's GitHub wiki repo as a subrepo on the website to allow users to directly contribute docs without the need for a pull request. Documentation contributions have tripled since we've done this.</p>
<hr />
<p>Automation is great, but thinking about contributions and new contributors can also really increase performance.</p>
</aside>
</section>
<section>
<h2>Create Opportunity</h2>
<img src="img/jumpin.jpg" />
<h3><a href="http://nikcodes.com/2013/05/10/new-contributor-jump-in/">Jump In</a> Issues</h3>
<aside class="notes">
<p><strong>Story Time</strong> Story of users saying that they didn't have enough breath to add a new feature or enough depth to fix a bug, which is how this was inspired</p>
<p>
Help new contributors by setting up Jump In tags on issues that typically:
<ul>
<li>Take no longer than a few nights worth of work to implement.</li>
<li>Be relatively standalone, not requiring tight integration with other in development backlog items.</li>
<li>Be well described with pointers to help the implementer.</li>
<li>They are not:</li>
<li>Items that the �core team� does not want to implement themselves.</li>
<li>Items that are specifically set aside for junior/novice developers.</li>
<li>Used as a hazing activity for �rookies�.</li>
<li>Designed to be fizzbuzz tests.</li>
</ul>
</p>
<p>If you are new to a project and looking for ways to contribute, ask if they have any Jump In tasks for you</p>
<hr />
<p>Thank contributors as loudly as possible</p>
<p>In the same vein to make things easier for new contributors, thanks those who have completed work as loudly as possible</p>
<p><strong>Story Time</strong> Story of thanking guys on podcasts</p>
<hr />
<p>So this is what I've learned after two years of day in day out experience, and by reading as much about and talking to as many people about these issues as I could.</p>
<p>In closing, I wanted to leave you with this inspiring picture of Henry Ford and Thomas Edison together, with Ford's words:</p>
</aside>
</section>
</section>
<section>
<h2>Questions? Answers?</h2>
<img src="img/ford.jpg" />
<blockquote cite="http://en.wikipedia.org/wiki/Henry_Ford">Coming together is a beginning; keeping together is progress; working together is success.</blockquote>
<aside class="notes">
<p>Any questions? Any answers? This is really meant to be the beginning of a conversation - I'm hear to learn just as much as you are.</p>
<hr />
<p>I'd love for you to get involved...</p>
</aside>
</section>
<section>
<h1>Thank You!</h1>
<img src="img/logo.png" class="plain" style="vertical-align: middle;"/>
<ul class="plain" style="position: relative; top: 100px;">
<li>
<small>
<img src="img/cclicsmall.png" class="plain" style="vertical-align: baseline;"/>
Logo/Design by <a href="https://twitter.com/headloose">@headloose</a>
</small>
</li>
<li>
<small>
<img src="img/ccby-nc.png" class="plain" style="vertical-align: baseline;"/>
<a href="http://www.flickr.com/photos/marine_corps/6922186029/sizes/l/">Jump In</a> by
<a xmlns:cc="http://creativecommons.org/ns#" rel="cc:attributionURL" property="cc:attributionName" href="http://www.flickr.com/people/marine_corps/">US Marine Corps</a>
</small>
</li>
<li>
<small>
<img src="img/ccby-sa.png" class="plain" style="vertical-align: baseline;"/>
<a href="http://www.flickr.com/photos/68751915@N05/6355345927/sizes/l/">Money</a> by
<a xmlns:cc="http://creativecommons.org/ns#" rel="cc:attributionURL" property="cc:attributionName" href="http://www.flickr.com/people/68751915@N05/">401(K) 2013</a>
</small>
</li>
<li>
<small>
<img src="img/ccby-nc-sa.png" class="plain" style="vertical-align: baseline;">
<a href="http://www.flickr.com/photos/traftery/3986446967/sizes/l/">Ford & Edison</a> by
<a xmlns:cc="http://creativecommons.org/ns#" rel="cc:attributionURL" property="cc:attributionName" href="http://www.flickr.com/people/traftery/">Tom Raftery</a>
</small>
</li>
<li>
<small>
<img src="img/ccby-nc.png" class="plain" style="vertical-align: baseline;"/>
Office Men Icons by
<a xmlns:cc="http://creativecommons.org/ns#" rel="cc:attributionURL" property="cc:attributionName" href="http://www.dapino-colada.nl/">DaPino Colada</a>
</small>
</li>
<li>
<small>
<img src="img/ccby.png" class="plain" style="vertical-align: baseline;"/>
<a href="http://www.flickr.com/photos/ceardach/4549876293/sizes/l/">Cats</a> by
<a xmlns:cc="http://creativecommons.org/ns#" rel="cc:attributionURL" property="cc:attributionName" href="http://www.flickr.com/people/ceardach/">muir.ceardach</a>
</small>
</li>
</ul>
<h3>resources & contribute @ <a href="http://osszerotosixty.com">osszerotosixty.com</a></h3>
<p>
<small><a href="http://nikcodes.com">Nik Molnar</a> / <a href="http://twitter.com/nikmd23">@nikmd23</a></small>
</p>
<aside class="notes">
<p>This presentation can be found at ossZeroToSixty.com, feel free to re-present it to the developers in your life</p>
<p>More information and resources are available on the website</p>
<p>It is open source in and of itself, so please contribute and lets get a quick start guide for all developers</p>
</aside>
</section>
</div>
</div>
<script src="lib/js/head.min.js"></script>
<script src="js/reveal.min.js"></script>
<script>
// Full list of configuration options available here:
// https://github.com/hakimel/reveal.js#configuration
Reveal.initialize({
controls: true,
progress: true,
history: true,
center: true,
rollingLinks: false,
theme: Reveal.getQueryHash().theme || 'speedy', // available themes are in /css/theme
transition: Reveal.getQueryHash().transition || 'concave', // default/cube/page/concave/zoom/linear/fade/none
// Optional libraries used to extend on reveal.js
dependencies: [
{ src: 'lib/js/classList.js', condition: function() { return !document.body.classList; } },
{ src: 'plugin/markdown/marked.js', condition: function() { return !!document.querySelector( '[data-markdown]' ); } },
{ src: 'plugin/markdown/markdown.js', condition: function() { return !!document.querySelector( '[data-markdown]' ); } },
{ src: 'plugin/highlight/highlight.js', async: true, callback: function() { hljs.initHighlightingOnLoad(); } },
{ src: 'plugin/zoom-js/zoom.js', async: true, condition: function() { return !!document.body.classList; } },
{ src: 'plugin/notes/notes.js', async: true, condition: function() { return !!document.body.classList; } }
// { src: 'plugin/search/search.js', async: true, condition: function() { return !!document.body.classList; } }
// { src: 'plugin/remotes/remotes.js', async: true, condition: function() { return !!document.body.classList; } }
]
});
Reveal.addEventListener('ready', function () {
Reveal.addEventListener('fragmentshown', function (event) {
// console.log('Added', event.fragment);
if (event.fragment.style.display === 'none')
event.fragment.style.display = 'block';
// Handle Tuckman Animation
if (event.fragment.parentNode.id === 'tuckmanOl')
document.getElementById('tuckmanImg').style.left = '0em';
// Handle "overwritting" fragments
var toHide = event.fragment.getAttribute('data-replace');
if (toHide)
document.querySelector(toHide).style.display = 'none';
});
Reveal.addEventListener('fragmenthidden', function (event) {
// console.log('Removed', event.fragment);
// Undo "overwritting" fragments
var toHide = event.fragment.getAttribute('data-replace');
if (toHide)
document.querySelector(toHide).style.display = 'block';
});
});
</script>
</body>
</html>