Running OSS Projects: From Zero to Sixty
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 150 | |
| Author | ||
| License | CC Attribution - NonCommercial - ShareAlike 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
| Identifiers | 10.5446/51482 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
Web-DesignerSoftwareOpen sourceProjective planeBitCapability Maturity ModelArmSystem callProcess (computing)1 (number)Mixed realityWeightLevel (video gaming)Group action10 (number)Reading (process)Presentation of a groupMultiplication sign40 (number)Metropolitan area networkFamilyMereologyExpert systemTheoryState of matterRow (database)Universe (mathematics)Design by contractData managementDynamical systemElectronic program guideSoftware frameworkVideoconferencingPhase transitionSpacetimeJava appletApplication service providerSoftware maintenanceGroup theoryRight angleXMLUMLComputer animation
05:38
Open sourceDrum memoryLattice (order)Embedded systemOpen sourceCovering spaceBitUniform resource locatorFitness functionMetadataWebsiteSelf-organizationPoint (geometry)Phase transitionMeta elementNP-hardSoftwareOrder (biology)TheoryProjective planeHyperlinkVulnerability (computing)Multiplication signBuildingLevel (video gaming)Software frameworkFrequencyData managementWeb pageSet (mathematics)Decision theoryType theorySchmelze <Betrieb>Virtual machineComputer fileProduct (business)Execution unitApplication service providerOpen setProcess (computing)Operator (mathematics)Video gameSoftware industryDisk read-and-write headSolid geometryComputer iconRight angleMortality rateCodeHacker (term)Propositional formulaComputer animation
11:12
WebsiteStatement (computer science)Demo (music)Capability Maturity ModelProjective planeEndliche ModelltheorieCodeData conversionElectronic mailing listRepository (publishing)Application service providerTemplate (C++)Fraction (mathematics)Standard deviationLibrary (computing)Torvalds, LinusPhysical systemWeb pageOpen sourceHierarchyComputer fileArithmetic meanDatabaseWebsiteSoftware repositoryMobile appC sharpVideoconferencingOnlinecommunityUniversal product codeStatement (computer science)WeightUniform resource locatorYouTubeView (database)SoftwareContext awarenessHome pageVisualization (computer graphics)Term (mathematics)Point (geometry)Multiplication signDifferent (Kate Ryan album)MathematicsDesign by contractDemo (music)Software developerProduct (business)Data managementRight angleRow (database)Sign (mathematics)Chemical equationBitPower (physics)Software maintenanceData storage deviceText editorProcess (computing)BuildingRevision controlSingle-precision floating-point formatBoom (sailing)Source codeFreewareSubsetScripting languageDirection (geometry)Logic gateGraphical user interfaceLine (geometry)TouchscreenComputer animation
20:04
TelecommunicationStack (abstract data type)Dependent and independent variablesBuffer overflowCodeRandom matrixSoftwareProjective planeWeightEndliche ModelltheorieCASE <Informatik>Decision theoryVotingDifferent (Kate Ryan album)MathematicsElectronic mailing listWordDirection (geometry)Flow separationProcess (computing)Self-organizationTelecommunicationLevel (video gaming)Touch typingMultiplication signOpen sourcePoint (geometry)Software bugKey (cryptography)MereologySoftware maintenanceSelectivity (electronic)Computer iconMikroblogLink (knot theory)Slide ruleSystem callBitType theory1 (number)Forcing (mathematics)Service (economics)Rule of inferenceInformationTwitterEmailData managementCountingNeighbourhood (graph theory)Product (business)File viewerCommutatorRight angleMoving averageGoogolGoodness of fitComputer architectureForm (programming)Group actionComputer animation
28:57
NumberTwitterEmailService (economics)Group actionInternetworkingStack (abstract data type)Slide ruleWebsiteCodePlanningWhiteboardDiagramBuffer overflowTable (information)FlowchartCoefficient of determinationReading (process)Proper mapMultiplication signPower (physics)Semantics (computer science)Thread (computing)Avatar (2009 film)Physical lawMessage passingSoftwareFiber bundleNoise (electronics)Software bugGraph coloringTelecommunicationDecision theoryOpen sourceVideoconferencingTouchscreenMathematicsProjective planeData conversionGradientBookmark (World Wide Web)ConsistencyNumberLine (geometry)Complex (psychology)Constructor (object-oriented programming)BitElectronic mailing listFormal grammarColor confinementSerial portElement (mathematics)Right angleACIDWeb pageComa BerenicesDataflowSubject indexingBuildingContext awarenessComputer animation
37:49
Kolmogorov complexityInverse elementVideo gameChemical equationGraph coloringMultiplication signMathematicsWeb pageAsynchronous Transfer ModePoint (geometry)Right angleChemical equationOpen sourceProjective planeFrequencySource codeTelecommunicationWordDecision theoryInheritance (object-oriented programming)Software developerArithmetic meanPosition operatorDifferent (Kate Ryan album)BitDirect numerical simulationContext awarenessTouchscreenBusiness modelOpen setVideo gameBlogAnalogyGoodness of fitDomain nameSoftware maintenanceData managementSoftwareFocus (optics)Imperative programmingTable (information)CommutatorComputer animation
43:40
Chemical equationVideo gameData managementProjective planeOpen sourcePhase transitionProcess (computing)Percolation theoryFocus (optics)Video gameTwitterSoftwareString (computer science)Level (video gaming)CollaborationismFood energyFreewareSoftware developerData managementConnectivity (graph theory)MehrplatzsystemService (economics)Slide ruleExtension (kinesiology)Revision controlPoint (geometry)Web pageComputer-assisted translationPower (physics)Data conversionLattice (order)AuthorizationWebsiteCodeGoogolDifferent (Kate Ryan album)LaptopRight angleLogic gateVector potentialPlanningElectronic mailing listComa BerenicesSoftware bugMetropolitan area networkTouch typingMultiplication signShared memoryMereologyInsertion lossNormal (geometry)Online helpComputer animation
49:23
WeightKey (cryptography)Ultimatum gameRankingChemical equationSet (mathematics)AutomationElectronic mailing listDifferent (Kate Ryan album)Projective planeService (economics)Repository (publishing)Coma BerenicesOpen sourceCASE <Informatik>Sinc functionProcess (computing)Software bugRule of inferenceMultiplication signMathematicsData conversionWeb pageWikiCodeLink (knot theory)Software repositoryCuboidVideo gameWebsiteLevel (video gaming)BuildingWindowMessage passingLengthUnit testingData managementSoftware developerMikroblogEntire functionSpacetime2 (number)Standard deviationElectronic program guideEndliche ModelltheorieArithmetic meanComputer-assisted translationOverhead (computing)HyperlinkExecution unitCycle (graph theory)Computer architectureSoftware40 (number)Shared memoryTouchscreenReduction of orderBlogHydraulic jumpEquivalence relationPoint (geometry)Percolation theorySoftware frameworkComputer animation
55:07
Hydraulic jumpPresentation of a groupInteractive televisionArithmetic meanOpen sourceStandard deviationEndliche ModelltheorieGreatest elementSoftware maintenanceMultiplication signCapability Maturity ModelEmailProper mapFeedbackData conversionSoftware developerComputer architectureGroup actionArithmetic progressionLevel (video gaming)CodeProjective planeWeightSoftware testingMereologyPatch (Unix)MathematicsSystem callBlogLink (knot theory)1 (number)Coma BerenicesHand fanComputer animation
01:00:29
XMLUML
Transcript: English(auto-generated)
00:06
Can we start now? Okay, cool. Alright, before I'm on, can you guys do me a favor? This is like a community discussion. I want us to feel like a community. I know this is awkward. Can we like, come right down front? I can't see anybody in the back.
00:23
This isn't this isn't just a presentation. This is a conversation. Like, right down here. Anywhere is good. So I can see you guys a little bit.
00:43
Yeah, nice. Alright, cool. Well guys, thanks for coming out. You get the achievement badge for making it all the way to the end of NDC and actually coming to a session. If you're confused, because I don't have a British accent, I'm not John Skeet. He's in that room. You can just head over there real quick.
01:02
So I just want to kind of do a quick calibration. How many of you guys are maintainers of an open source project? Okay, the whole front row. You guys are very eager. How many people kind of regularly contribute to an open source project, like once a month? Okay, cool.
01:20
And so I guess I'm assuming the rest of you guys are interested in being involved in open source. And that's why you chose this talk? Maybe? Yeah? Okay. Cool. I'm going to go under that assumption. So let me start real quick by talking about who I am. So my name is Nick Molnar. I'm a web developer from New York City. I've been doing web development for about 16 years.
01:41
I started off doing startup work down in Florida, where I'm originally from. Lost a lot of money for a lot of years. I've done government contracting. I've been consulting in New York City, where I worked at big banks. I did work with major retailers and some kind of fun projects all around the world with that. And
02:01
I started a project called Glyphs with my co-founder Anthony. He was here in the front row, and the guy all the way there on the left in that picture. So if you haven't heard of Glyphs, Anthony actually just gave a talk about Glyphs, the session beforehand. So that's a really good way to get acquainted. Maybe when the videos come out from NDC, if you weren't in the room then, you can take a look at that.
02:22
But essentially it's a diagnostics tool for web developers. And we released that tool a little over two years ago at the Mix11 conference. And we had never shown it to anybody until that day. We had worked on it for about five weeks before that day had arrived.
02:41
And when we were there, we kind of got really lucky. I like to say that we got the Hansel bump. Because Scott Hanselman, Phil Hack, and David Fowler, the other people there in that picture, they're all members of the ASP.NET team, or they were at that time. They all just kind of really loved Glyphs. And so they had us on podcasts, and they blogged about us, and they put us on Channel 9. And we went from
03:01
never really having done any open source to having tens of thousands of users within a couple of weeks. needless to say, we were a little inundated. So that kind of continued on for quite a while, until about eleven months ago, Anthony and I got a phone call from a company in England
03:20
named Redgate Software. And they kind of said, hey listen, we really like Glyphs, but we don't think enough is happening with it. Why is that? And so we explained, hey listen, this is open source, we do this on nights and weekends, we have real jobs to feed our families. And they said, okay, well we would like to be involved and what we're thinking is maybe we can sponsor you guys. We'll give you the 40 hours a week that you need
03:42
to really make Glyphs sing. And so that's awesome. And so for almost a year now, I've been working full-time on open source, and with the community, and getting to come to things like this and talk to people like you, which is awesome. But that's not to say that I'm an expert in open source.
04:03
I'm just trying to figure out how to work with communities and to build good software the same way all of the rest of you guys are, and gals. And so I decided that I needed to put something together for past Nick.
04:21
The Nick of two years ago who had no clue what he was doing when he started up an open source project, had no clue that it was going to be successful, how to manage that. So what this presentation is is me scratching an old itch of problems that I've had over the last two years, all the research that I've done, all of the other open source maintainers
04:41
and contributors that I've talked to in the last two years, I kind of pulled that all together into what I like to think of as a quick start guide to understand how to manage open source projects. I feel like the .net community in particular kind of needs this since we traditionally are a little bit behind some of our competitor frameworks like maybe
05:00
the Java space or the Ruby space and our maturity of .net. I was hoping that this is going to help a little bit. So while I was doing all the research over the last two years, one of the things that I came across one of the people that I came across was this guy named Bruce Wayne Tuchman.
05:21
My first and middle name were Bruce Wayne. I just kind of stopped there and I wouldn't tell anybody the Tuchman part. But he decides to go with Tuchman. He's a pretty scholarly fellow. He's a researcher in the theory of group dynamics and he's a professor at Ohio State University back in the States, where I'm from.
05:40
And so back in 1965 he published this theory that he calls Tuchman's stages. And so Tuchman proposes that there's four necessary and inevitable phases in order for a team to grow, to face up to challenges, to find solutions, and basically get their work done.
06:02
So those four phases are forming. That's the period of time in which a bunch of individuals come together as a team. Storming. That's the inevitable time when those people find out that they have some challenges and problems that they need to solve. Then they move on to norming. This is the time
06:20
when kind of that whole team has got over some of their issues, they understand what they're trying to build, and they all agree on how they're going to execute building it. And then finally, the last stage is performing. And when a team is performing, kind of all of the individuals that make up the team kind of melt away. And you just see the team as a solid unit. And so individuals can begin to
06:40
kind of cover each other's weaknesses and anticipate the moves of the rest of the organism. So we're going to use Tuxmin stages as the lens in which we analyze some of the challenges and opportunities that are available in open source management. So obviously that first stage
07:02
is forming. Forming is actually kind of a lot of fun and really easy, because when a project is forming, there's not really a lot of challenges. You kind of avoid those, and you end up doing a lot of meta work. So I'm thinking of things like where are we going to put the code? Who's going to be on the team?
07:20
It's a lot of defining what we're actually going to build. All of this kind of meta work. You just kind of avoid the hard stuff because you're setting that up. So I've identified three big things that you want to think about when you're forming an open source project. And the first is probably the most important, because it's actually the thing that makes an open source project open source, and that's
07:40
its license. So selecting a license can be a little bit daunting. I'm not a lawyer, so reading through all those legalese and not understanding really how it's going to affect the decision I make on my project is a scary proposition, and you don't want to make your own. Trust me, that's
08:00
even worse, unless you are a lawyer. The other thing is depending on what type of license you choose, you you may kind of gain more of a following or less of a following. Some communities particularly like certain types of licenses and others do not. So it's kind of important to understand who you're targeting with the framework that you're trying to build or the product that you're
08:21
trying to build. So let me tell you how we went through this with Glimpse. So two years ago when we were releasing Glimpse, Nougat had just come out. Nougat was about a month old. And so I'm sitting there on my machine building up my first ever Nougat spec file, which is the XML manifest file that makes
08:42
up a Nougat package. And there's all this metadata that you have to fill out in a Nougat spec. And one of those pieces of metadata is a license URL, where I put in a URL to what the license for our project is. So I kind of scratched my head and I said, okay, well, I guess I have to pick one now, and I need a hyperlink. So I knew that Creative Commons,
09:02
which is a website for making licenses, had this kind of wizard where I could go and click through what things people would and wouldn't be allowed to do with my project, and when all of a sudden done, it spit it out on this page with nice icons, and I had the URL that I needed. So Glimpse 0.75,
09:20
you can still go look at it on Nougat, Creative Commons license. So hey, I was happy with that. I had my URL and I moved on. So we released Glimpse, and the very next day we were talking to Phil Hack, who at the time was the product manager of ASP.net. So we're just kind of shooting the breeze, and he looks over and asks, oh, what is the license for Glimpse?
09:40
I said, oh, it's Creative Commons. We've got a great website to go with it. And he just kind of does one of these like made me feel like the scum of the earth. I'm a moron. Why am I doing open source software? He's like, no, no, no, no. Creative Commons is about content. That's not really an appropriate license for software and distributing software. And so it kind of coached us through
10:01
the process. We've ended up selecting the Apache 2 license, which was his recommendation. We did a little bit more looking into it. And a lot of the other ASP.net-based open source projects are also Apache 2, so we felt like that fit our community. So we picked that. So that's kind of my story about how I got kind of slapped around a little bit and humbled and learned a lot.
10:24
Perhaps you don't have that opportunity. There's a website that I've found recently this too long, didn't read legal, which is specifically made for finding licenses for open source. And so I'm going to come here and I'm going to do a search for Apache 2 licenses.
10:43
And basically here's the Apache 2 distilled down into a couple of bullet points that you can understand as a mere mortal, right? So people who use our project with Commercial 2 can use it for commercial use. They can modify it, distribute it. They can sub-license it and they can put warranties on top of it. I cannot be held liable for anything that GLEMS does because of the Apache 2 license.
11:02
You cannot use our trademark and there's a couple of things that you must do as the user of the project. So this is great. You can compare and contrast licenses very easily with this website and it will help you figure out which license you should use. I also want to make another quick point about another kind of license that you might hear people talk about commonly in the open source world,
11:22
which is a contributor license agreement. Completely different kind of license. To be honest, you kind of need to be pragmatic. You may or may not need a contributor license agreement. I had never heard what it was. In that same conversation with Phil, he kind of told us we might want to think about putting one in place. What a contributor license agreement does is it puts a
11:42
contract between the OSS project and the contributor who's giving code. So let's say Miguel in the first row here decides that he wants to contribute some code to Glimpse. That's great, but Miguel has the copyright of his code, which could potentially pose a problem for a user who then installs Glimpse.
12:02
And Miguel calls us up two weeks later and says, Hey, you know what? Actually, I stole that code from the US government and I need it back now. And that can cause us real legal problems. So a contributor license agreement allows the contributor to sign the code over to the project that he's donating it to so that he can't ask for it back.
12:22
It protects the project and makes sure that we can move forward. And it's funny because when we had our initial conversations with Redgate, I don't really know what would have happened if we answered the other way, but they had asked who all has claims over the code. And Anthony and I were actually able to say, well, just us because here's the list of signed contributor license agreements we have from every contributor
12:41
who's given us something. So you may or may not need that, but it's something to think about. We just used the template that Apache Foundation gives us and so you can go and find the template for contributor license agreement. So that is selecting a license. So next, this is kind of the quick stuff that you're going to want to go through
13:02
which is your project setup. So the first thing you're going to want to do is set up a website. Now it's very common in today's world to point people right to your GitHub page or to your NuGet page and that's kind of what we thought we were going to get away with. And we were almost held hostage by Scott Hanselman that first night because he was real excited about Glimpse, he was giving us the Hansel bump and said
13:21
but I'm not going to blog it until I have a real URL. I'm not going to send people to GitHub because the GitHub page doesn't explain what the project is, it doesn't say that it's free, it doesn't show a demo, it's missing a lot of the context that an end user would care about. So the contributors or the people who are riffing on top of the library,
13:41
if it's a library, might care about it at GitHub but nobody else. So kind of going along with that website, you're going to want to set up a mission statement. A mission statement clearly defines, and we'll talk a little later about why this is important, what the project is trying to do and what it's not going to do. It's a good idea to put this in your readme.md
14:01
file, your readme markdown that GitHub will show if you're using GitHub. Otherwise get it right on your homepage. It should be really simple and concise. There's an open source project in the .NET community right now called ScriptCS and I really like their mission statement. ScriptCS makes it easy to write and execute C Sharp with a simple text editor.
14:22
That's it. Simple, concise, I know exactly what that project is going to do and I'm not going to show up there trying to convince them to build something else or to build and support into Visual Studio because they're all about simple text editors. The next thing that you're going to want to think about doing is setting up contributor guidelines when you're setting up your project if you want people to be helping you out.
14:42
Contributor guidelines are going to explain to the user community how you want to interact with them, how you're looking to get code, what's acceptable and unacceptable. Things like naming conventions or any standards that you have in place, you actually want to send that in. The hierarchy in which they can help you out, so submitting
15:01
an issue on GitHub or where to go to ask a question, etc. It's actually so important that it's now built into the Chrome of GitHub. If you create a file in your repo called contributing.md they will automatically suck that file out and stick it into their website when somebody's going to create an issue or something like that, it'll pop up
15:21
and be like, have you read this contributor guidelines? That's another important little thing to do. Real quick, this has always been true for proprietary software as well as open source software. You've got to have a screenshot or a demo of your app or your library. We put a video up that first night on YouTube
15:42
it had 50,000 views and we are pretty confident, or at least we like to think we're confident, that that's one of the reasons why Glimpse really took off, because within two minutes people can understand the big idea of Glimpse and see it with their own eyes. The last one I'm going to mention is this term called forkability.
16:03
Forkability is a term that was coined by Carl Fogle who ran the SVN, the Subversion Source Control Project for a long time. Forkability is all about making your code base very easy for somebody to get,
16:20
execute, and change as quickly as possible. If you pay attention to the community at large right now, there's a lot of companies that are proudly wearing a badge on their sleeve that says, we can hire a developer and on day one they can ship production code. That's how good our code base is, right? They can check it out, they have everything that they need, they can do one step build process,
16:42
make a change, and then boom, it's in production. People are very proud about that, and it's a sign of maturity of the company. The same thing goes for open source, it's a sign of maturity. So to keep your code forkable you want to keep as many dependencies as possible in source control, or use a package management system that will automatically pull those in like NuGet. You want a single step
17:02
build process, and you want to have samples, if possible, built right into your repository. So on Glimpse, if you download our source code, you open up the solution and hit F5, we actually launch a website for you, we copy over a quick little database so the website has some data, and we put up Glimpse. So literally in one keystroke you can actually start seeing the code
17:22
that you're executing and changing if you're trying to make a contribution. But forkability is interesting because if it's really easy for somebody to grab the code and get started, and then potentially make a contribution back, that means it's also very easy for them to fork the code and become a competitor.
17:41
And so, that sounds maybe like it's scary, like oh, I don't want somebody to fork my code base and take it off somewhere else, but it actually kind of puts in a system of checks and balances into the open source project that removes a bit of the power from the maintainer, which basically means that the maintainer
18:00
or the lead contributors can't just take the project off in their own direction, for their own profit, for their own reasons. They still have to keep the good of the community in mind. And so, actually one of the things that we said when we started working with Redgate is Scott Hanselman had us on his podcast and asked us all these really hard-nosed questions like, well, what's
18:20
going to happen if Redgate wants to do something evil, blah, blah, blah? And we said, look, it doesn't matter. We're forkable. Just take the code and people can do something else with it. Redgate wants to be in the community with us. If they didn't want to be, they wouldn't choose an open source project that somebody could just fork. So, honesty and transparency with the community are really important. And so, that leads
18:40
to my last point of forming a project, which is selecting a governance model. I feel like this is the thing that's talked about the least, and this is maybe the thing that I learned the most while putting together this talk, is governance models. So, you may remember a couple of years ago, there was this kind of brouhaha when the ASP.NET team came out
19:00
and said, hey, we're open source now. And they released NVC and an MSPL, a Microsoft Permissive License license, right? And technically, they were right. They were open source because the MSPL was a library that was on opensource.org which maintains the open source
19:20
definition, which has ten tenants that says if your license is all these ten things, it is officially opensource. And it had all of those things. But that just means you're sharing the code. It doesn't mean you're running a community project or, some people will say, it doesn't mean that you accept takebacks, right? And so, that's where your governance model starts to come in. And so, there's a couple of famous
19:40
governance models, right? So, there's one that you may have heard of before called Benevolent Dictator. That's the model that Linus Torvalds uses for Linux. Obviously, it works very well. That's a very successful project. It's not the model that I prefer. I prefer one called a meritocracy. So, that's the one that I'm going to focus on. And now, you may have heard of that term as well, the
20:00
meritocratic model, right? People use this on their projects all the time. But what I've found is it's a little bit like kids' basketball. So, back in the States, right, there's all these neighborhoods and schools that have these black tops where kids play basketball. And every basketball court has slightly different rules. They're all like loosely based on the real professional NBA
20:20
rules, right? But like where I played, it was no blood, no foul, right? Which means I got beat up all the time. But those were the house rules. It was slightly different. And that's kind of how I find people using their governance models. They kind of say that they're meritocratic, but they have all these house rules that you have to get to know, and they're not documented. So, that has always made me to believe that the
20:40
meritocratic method was just something that was kind of made up, and people just did. So, it's not. It's a well-defined kind of ratified thing that you can use. There's an organization called OSS Watch in the UK that actually has an entire document that says, this is the meritocratic model, and they give that document away to you as a creative commons license
21:02
so you can just put it in your open source project and you can tweak it if you'd like to. They have the same from benevolent dictatorship. But let me walk you through a couple of the highlights of what is contained in this model in case you haven't heard. So, the most important things I thought that came out of that are the roles and responsibilities of people in a meritocratic project, and some of the
21:22
decision making process and how that works. So, the first type of user or role, the first role of the project is a user. And the users are the most important people in the community. They're the ones that have the need for the project being built. If those people go away, so does the project.
21:40
They can do things besides just use the project. They have other ways that they collaborate with the community. So they can do a huge thing and just pat the guys who create it on the back and say thank you. They can do word of mouth evangelism and tell their friends about it to help spread the project if they think that it's good. And they can even make
22:00
financial donations. They can use flatter or a service like that to chip back a little bit of money. But they're users. And some users will begin to want to make concrete contributions to make the community better. They want to do something very specific. And so when they do that, they move into the next role, which is a contributor. And so there's
22:21
lots of definitions of contributors. The definition that we most frequently hear is somebody who actually gives code to a project. And by that definition, Glimpse in the last two years has about 40 or 50 contributors. But the contributor, going back to the meritocratic model, is somebody who's doing positive things for the
22:42
community. It doesn't just mean code. So if we start looking at the people who submit documentation, that makes the community better. Our count is now up to 70 or something like that. People who go to Stack Overflow and answer questions about the project, they're doing support. People who are
23:01
triaging issues that are coming in and making sure that they're well described. Looking for new features. All that kind of stuff is what a contributor does. And so we're very used to contributors. In the GitHub model, we see contributors do pull requests. So they submit some code and you take it in. Now if you contribute to a community enough,
23:21
the people who run that community will begin to trust you. And they might nominate you to become a committer. A committer really isn't a whole lot different than a contributor. They just kind of flip things around. So
23:41
if I'm a contributor, I might write some code and do a pull request. And what a pull request is, is me saying to that project, do I have permission to make this change? And when they say yes, that change is applied to the code base. When I'm a committer, I make the change to the code base, but there's still implicit permission that
24:01
needs to be there. The reviewers, the people who run that project, could still say, you know what, yeah, you have direct access to change that code, but we really don't want that. We don't want to move in that direction. You don't have permission. We're going to move in a different direction. We're going to back out your change. So it's still there. The point is to kind of grease the wheels for the committers, because they constantly are doing good things for the community.
24:21
They've grown trust in the community. So we might as well, if we're going to accept 9 out of their 10 pull requests, we might as well just let them automatically put those other 9 in and we'll deal with the 10th one in a special case scenario. So, the next step, and this is the one that I don't hear most people in the .NET community ever talk about, is reviewers. So we say maintainers a lot of the time.
24:41
The Merocratic model calls it a reviewer. A reviewer is a committer who has been nominated to move up to a higher level of the project. And that higher level does all the exact same things. They usually have the keys to do a deployment, and they also will do things like select licenses or vote on changes to the governance model, or who gets
25:01
to be in each of these groups. So those are things that reviewers do. So, that's the roles and responsibilities. The decision making process is also very interesting. And I don't think that this is followed really at all, and it's something that we're now striving to put into glimpse. So there's this idea of a lazy consensus.
25:22
Which means that if you want to propose a change to the project, the first step you do is you propose it and you put it up on the mailing list or on GitHub issues or wherever that kind of stuff goes. And if there's discussion and everybody kind of agrees, you just move on. The decision's been made. If there's a problem, then we need to think about voting. And we're going to ask the community to vote.
25:41
Now, a meritocracy is not like a democracy. I'm American. We're very proud of democracy. I'm not that political, so I don't really care. But what's different between the two is that as just an ordinary US citizen, I have equal say as the
26:00
senator of New York State who should be president. We are equals because it's a democracy. A meritocracy, that is not true. Everybody has a say, but users and usually contributors don't have as much of a say as committers and reviewers. Committers and reviewers have what are called binding votes. So when something has to go
26:20
to a vote, those are the votes that count. But just like politics back stateside, that senator usually should be voting in the same direction as the rest of the community. Otherwise, he's not doing a very good job staying in touch with his community and understanding the needs of the project and where the project wants to move. So there's a whole lot more there. I highly
26:40
recommend, it's a 15 minute read, to click on this link later all the slides are available online already and read through that document and start thinking about how you would apply it. If you're not a guy who's running a project, that's okay. Understanding how this stuff works is equally as important because you're going to know how to interact with the community when you show up to it for the first time. Alright, so
27:00
once a project is relatively well formed, we're going to start to have some issues. Open source software is built by people and people have pride and they have egos and software has bugs and it has architectural challenges and we're going to start storming and
27:20
the storming part sucks. But if you get through it, the project will be much stronger. So here's a list of the common challenges facing open source projects and some ways that I recommend that you avoid them. So communication, the first word that pops up, surprise, surprise. The most common problem that you see anywhere in any organization in any kind of team is communication.
27:40
So I've broken down communication into three separate thought processes and the first is channels. And so there's three different channels of communication and using the right channel at the right time I think is very important. So the first is incoming communication. So for our so incoming communication is how the users and contributors are going to
28:01
communicate back into the project. And so for our project we use a Google dev list which is that icon on the left where people can go and ask questions and make suggestions that we're going to have a longer discussion on. We use GitHub issues where somebody will report a bug or something like that. And we use Stack Overflow which is where people go to ask quick questions
28:21
that aren't kind of about the future. It's not an architectural discussion. It's X doesn't work. How do I get it to work? And we respond. And so you want to kind of force people into those channels. The opposite of that is outgoing communication and this is where the project itself is pushing out information to its community. And so the most common
28:41
way and the way that we use is blogging to do that. We also use kind of Twitter for kind of day by day, week by week status updates of kind of what the people in the project are doing so everybody can follow along. And of course we use something like NuGet or whatever package manager we're using to ship our product and that's a feed. That's a news feed. Something I want to point out that's kind of interesting is that Twitter
29:01
I consider to be outgoing but I get tons of people asking me questions on Twitter and that seems like it's incoming. And sometimes I get lazy and I just quickly respond to them on Twitter and say, hey, here's how you can you know, do this. What I should be doing is forcing that communication through the proper channels. I should tell that user, hey, that's a great question.
29:22
Please go ask it on Stack Overflow. I'll answer it for you there. And the reason for that is all of these incoming communication channels are highly indexable. So the next guy who goes on Google and does a search for that, he'll find it on Stack Overflow I can save my breath and my keystrokes just by using the proper communication channels and the next time that I would have spent answering
29:41
that question, I now can be contributing code or doing something a little bit more concrete. The last channel of communication is internal. I almost don't want to have this on the slides because this is one of the biggest lessons that we learned is internal communication and an open source project will kill the project. If you want to be open, you should be doing your communication publicly.
30:02
There are some things that a project needs to do though that should be done in private. Like if you're having a conversation about bringing on a new committer or maybe you're talking about what your licensing is going to be or you're making some strategic decisions, then you can have some internal non-public communication but try to keep it light. And so we use
30:22
Trello to do some strategic planning. We use HipChat to do some chatting amongst the team every once in a while and we're kind of friendly people who like to chit chat with each other so we'll get on Skype and do video conferencing. So once you've kind of figured out where to communicate, the next important thing is how to communicate.
30:42
And so this is interesting because on the internet, nobody really knows who you are. You are just your non de plume. You are your pen name. People only know about you what you write or what others write about you. That's it. So it's really important to represent yourself well. You could be a complete genius, a charismatic
31:01
leader, but if everything that you write is just kind of like bumbling with horrible spelling and grammar, people are going to think that you're a bumbling moron. So think about the things that you're writing. That's what they see. The opposite is true too. You can be a complete dog as this famous comic illustrates, but if you're eloquent and well-spoken and kind, people
31:21
will think that you're the best thing ever and you end up with 12 year olds making great contributions because they can do these things. So I'm going to go through a couple of quick tips. I wish I didn't have to say these, but the reality is after two years of experience, they still need to be said. So punctuation, grammar, spelling, check them. If you're doing anything over two paragraphs, reread it.
31:41
That's going to go a long way for you. Try to keep your avatars and your handles consistent across the different networks that you're using. So when I was 12 years old, I got on the internet for the first time. My uncle bought me an AOL account and so the only screen name that was available with my name was NIK, the name of the high school that I went to which was in Miami-Dade, MD
32:01
and my favorite number from Florida Marlins catcher Charles Johnson, 23. That's my Twitter handle, NIKMD23. That's horrible. People make fun of me all the time because of this. But, because it's horrible, it's consistent. I'm that on GitHub, I'm that on Twitter, I'm that on Skype, I'm that on Gmail, I'm that on AOL, I'm that on Yahoo, I'm that on every service that ever
32:21
existed in the last 15 years of the internet. And that consistency really matters. People can find me and I keep my avatar the same so people can find me and know that they're talking with the same guy. When you're writing, consider the subject lines of the emails or the titles of the issues. I'll get like 30 things come through my inbox in a given day
32:41
and I'm going to pick and choose sometimes. I don't have time for all of them all of the time. So that one little sentence that you get to show me as a reviewer of a project, that's important. Make it count. When you are discussing these technical issues, sometimes it's difficult to get a point across. Don't be afraid to use
33:00
a diagram if that's what's needed and put it right into the issue or the email. I like to use these two tools. One is called AsciiFlow.com. It's actually kind of like a little tiny drawing tool online that lets you draw something and then export it to Ascii and then I just drop it into a code pen on GitHub and I'll draw tables and flowchart diagrams and stuff like this. I had a good conversation going once on another open source
33:21
project I'm involved in called Semantic Release Notes where we were going back and forth about how a particular feature would work. We probably had 15 messages and then I just drew the diagram and everybody said oh, I get it and the conversation was over just because it was too tough to explain in English. And that kind of goes in general
33:41
what I'm saying there is provide context. Make it clear what you're talking about. If you start referencing some other bug where we fix something before or some other decision that was made on the mailing list, just link right to that thing. Don't just reference it because somebody new later will be reading that and won't have any way of finding what you're talking about. Okay, so you're communicating in the right channels. You kind of know how
34:01
to communicate, which is fairly basic grade school stuff. That still doesn't mean communication on a project goes well because well-meaning, well-placed communication still might not move a project forward. And so one of the biggest enemies of a project moving forward is a technique known as bike shedding. So
34:22
bike shedding was introduced by this guy named Cyril Northcott Parkinson in a book that he wrote in the late 50s. And in this book he defined what he called Parkinson's law of triviality. And Parkinson's law of triviality says that the amount of noise generated by a
34:42
change is inversely proportional to the complexity of that change. And so in this book, Parkinson kind of dramatizes his law by taking a look at a board of directors at this big company and they're building a major power plant.
35:01
And so the board of directors, the engineers come in and they hand them binders this big with all the blueprints of how they're going to build this huge power plant, how much it's going to cost, how long it's going to take to build, etc. etc. And the board of directors deliberates on it and they spend some time and ultimately the power plant gets approved. And so a few months into the construction of the power
35:20
plant, a group of the construction workers that ride their bikes to the site say, hey, you know, it would be really great if we could just have a little bike shed over there in the corner to keep our bikes out of the elements while we're here working all day. So they put together a two sheet plan of what they're asking for, how much it's going to cost, and they submit it to the same board of directors. Now Parkinson goes on to say
35:42
that this board of directors will take much longer to approve the bike shed than they will the power plant. And the reason is the bike shed is simple enough for anybody on the board to understand exactly how they would build it, exactly what color they would paint it, how the roof would be sloped, where they would place it. They could build the whole thing in a weekend and still have
36:01
time for a barbecue Sunday night. Alright? With the power plant, it's too complex. They don't want to get involved in it, so they just assume that somebody else has combed through the details and it's probably okay. And so the bike shed is their way of proving that they're paying attention to what's happening in the project, but by picking and
36:21
choosing the easy things. So that was written in the 50s by Parkinson. So in 1999, a guy named Paul Henning Camp, who was influential in the FreeBSD open source project, saw a bunch of people on a thread all kind of bickering about a very
36:40
minor feature. And this thread was going on for a long time, and he had kind of had enough. He's like, this is not the most important thing. So he's the first guy to apply Parkinson's law of triviality to open source. And so he wrote this amazing email on that thread, and I've only pulled out a portion of the email, where he said, why should I care what color the bike shed
37:01
is? The really, really short answer is that you should not. The somewhat longer answer is that just because you're capable of building a bike shed does not mean that you should stop others from building one just because you do not like the color they painted. This is a metaphor indicating that you need not argue about every little feature just because you know
37:21
enough to do so. Some people have commented that the amount of noise generated, and then he goes and reads off Parkinson's law. So that's just an excerpt of the email. The email went on to change FreeBSD, and he encouraged the people that he sent it to, that if they see the behavior again, to resend the email. And this is in the late 90s, in 1999,
37:41
and it turned into a meme before there were really memes. And that email to this day is still available at Bikeshed.com. And one little feature that I think is funny at Bikeshed.com is a horrible website, is every time that you refresh it, the color of the webpage changes. So I thought that was pretty funny. So if you see that, I want to encourage you to remember this URL, take this
38:01
text, or send out the link, and make your community aware of Bikeshedding and that it's more important to focus on the important issues rather than on the small little ones. Okay, so we talked about communication quite a bit. That's a very common problem. I've been married for eight years now to my lovely wife, and still
38:21
every once in a while we have communication problems. We're friends with a lot of other married couples, and one of the most common problems that comes up in a marriage or any relationship is finances. And the same is true with open source projects. Oh, look at that. I hit F12. You guys should have helped me out there.
38:41
Goodbye firebug. Hello full screen. So, there we go. Dealing with money. So Anthony and I were very lucky. So that second day, the same day that Phil Hack told us that we were morons for choosing the wrong license, we had two developers at that conference pull Anthony
39:02
aside. So we're in Vegas. They pull us aside. We're standing next to Blackjack tables, and they say, hey, listen, we really think glimpse is something. I don't think you understand what you have. We're going to give you ten grand right now to hand us the source code and walk away. We're going to close it up, and we're going to turn it into a product. ATMs in Vegas will spit
39:21
out ten grand like it's nothing. Like, we could have walked away with cash right there. And so we said we needed some time to think about this. Anthony and I had been working on it for five weeks. It would have been five grand apiece, a thousand dollars a week. Not too bad. It's a nice little pocket change. And I could have probably blown it all on Blackjack. So we go to this little diner, and we kind of talked for a long time into the wee hours of the night about
39:41
why did we start glimpse? What was it for? Do we want to make money on it? Do we want to turn it into a career? Basically what it came down to is we wanted it to scratch a niche, and we wanted to give back to the community. The ten grand didn't mean anything to us if it didn't mean that we can contribute something to the community. So ultimately, after thinking about different business models
40:01
and all that kind of stuff, we declined their offer. But while we were there on the subject of money, we decided to just get everything out on the table and make sure we were on the same page. Because what if it was a hundred grand tomorrow, what would we do, right? Or at what point would we no longer agree? So what we decided is that we were going to always keep it free and open source, and that
40:21
it was always going to be a community project. And if we ever did receive a donation, the first thing that would happen is we would back pay our bills. Anthony pays for all the hosting for our website, I paid for the domains and the DNS. So we don't have a lot of bills. If we had any money left over after that, the decision was made that we would buy swag, t-shirts and stickers, and we'd make sure that our contributors felt the love. So I
40:41
think it's important, if you can, to deal with money. If you're just a user, and you're not in that position to think about this stuff, there's a lot of open source projects on the other side of the coin that need money, or that are dying because they can't host their website somewhere like they need to, or they need a little bit here or there. So think about making a donation.
41:02
But do it carefully. Hold the people that you're donating to up to their end of the bargain. There's a quasi-famous story of Jeff Atwood, who's coding horror, I'm sure most of you guys know who that is. He put aside five grand a few years ago, and he was going to give it to some deserving open source project.
41:20
So he ended up giving that money to Screwturn Wiki, which is a great project. A few months later, he comes back to his blog after announcing that they won this money and everything, and he kind of wrote a really disappointing, sad article that said, hey listen, this project has been sitting on five grand in the bank for months on end now, because they have no freaking clue what to do with money.
41:40
There was never a discussion in that community about how would we handle this situation. So Jeff was kind of upset about that. I don't actually know how it ever resolved itself, but make sure that if you're going to contribute some money that they understand what it's going to do, and it's just sit there and go to waste, because you don't want to do that with your cash for sure. So I have one more thing that I want to talk about with Storming.
42:01
This is probably the one that's the most personal to me, and that is the balance between open source and life. So this is a guy smoking a cigar. Very common picture in the States. You get, you find out that you're going to have a baby, you're smoking
42:22
the cigar, you're really excited, right? And having a baby is a great thing. You have pride and joy, and you want to make sure the baby is healthy, and you want to bring that baby up to do great things. And we hear this analogy all the time in open source, that the maintainers are the parents of the project.
42:40
And we use that word parent, and I actually don't even really like that word parent, because being a parent is a very serious thing. Being a parent of an open source, we just flippantly throw out so much weight onto that. And so just like having a baby, or having an open source project that gives you the pride and the joy,
43:00
diapers still need to be changed. You're still up in the middle of the night. There's a lot of crying, mostly from me. I got a half of a laugh, that's good, by Anthony. So, you know, I went through a good period of time where my life sucked because of Glimpse.
43:22
I would stay up all weekend. I would not hang out with my friends. My wife would go out without me. It would be 3 in the morning, and my phone would buzz, and I'd have to wake up and check Twitter and make sure I was supporting the users. And I was taking myself way too seriously. So this is probably the one slide in my entire deck where I can't point
43:42
back to some management luminary. I can't tell a story about some bigwig in the open source community who helped me along. I just wanted to stop and say, you need to evaluate why you're doing open source software in the first place. We did it to give back and have fun. And when it's not that anymore, don't take yourself so seriously.
44:02
There are more important things in life. I've learned that now, so I'm pretty happy. So I just covered a whole bunch of crappy stuff. Ended on a somber note. The good news is, the next of Tuxedo stages is norming, and that's when things really begin to be fun.
44:22
So like I said earlier, when a team is norming, they're all kind of on the same page. They know what they're trying to build. They know how they're going to build it. They're executing and they're moving forward. Here's some things that are going to start to happen to your project when you begin norming. The first is going to be, as the community arrives, your
44:42
work of being an actual software developer will begin to decline. And you'll have to start doing a lot of community management. And there's a lot of herding cats involved with community management. So a couple of quick tips that we've learned for community management. The first is that you want to treat every single user that uses your project as a potential volunteer.
45:00
So what we like to do with that is we treat every person as a potential volunteer, and we kind of string them along through the process. We want to make a very easy on-ramp for them to be active members of our community. So if they submit a bug, an issue on GitHub, we will try to coach them through how to fix it themselves.
45:21
If they're already fixing things themselves, we're going to try to coach them along to make sure they know how to start adding features. And every single time, we try to tease them in, make little tiny baby steps so they feel more and more comfortable in the community. So that's kind of the first thing. When you're managing a community, there's two things that are really important to keep in mind all the time, and that's focus and attention.
45:43
So it's very, very easy for a community, especially a dispersed, not very well-connected community that makes up open-source projects, to lose focus. Somebody will show up and start asking kind of irrelevant questions, talking about how you should add some off-the-wall feature that doesn't really apply. People are spending their energy discussing this issue with
46:02
this guy, trying to support him or whatever. So as a manager of the community, you need to try to keep the developers and people who are working on it focused on what you're doing. One small thing that we do to keep focus is we use milestones and GitHub to say, these are all the things that we're working on right now. It doesn't mean that anything else isn't important, but this is where our focus is.
46:22
If this is what you want to talk about, please join us here and take care of this. The other thing is attention. Like I said, open-source communities are very dispersed, and so people don't necessarily know what's going on from one side of the world to the other. So you want to draw attention to that kind of stuff. The Glimpse Project does a couple of different
46:42
things to draw attention to our community. We host about a monthly Google Hangout, where we have extension authors come and show off the things that they're doing so that others in the community can see it, and we kind of try to cheer their efforts. We talk about them on Twitter. We have a gallery on our website where we talk about what our contributors are doing,
47:01
just basically making everybody more aware. The last thing is interesting, because I think as geeks we kind of have this culture or this tendency to go into some dark corner somewhere, we open up our laptop, and we just want to code. I think open-source has a very big component of code, and
47:21
that's why we all like it, but open-source is about people and community and collaboration. My point is, and I think that you I'm probably preaching to the choir here, because you are at a conference right now meeting and interacting with developers, but the power of meeting somebody face to face is huge.
47:41
We were traveling, Anthony and I were traveling in Belgium, and we actually knew a guy there, and so we were going to go out to dinner, and he brought a co-worker that we had never met before. The four of us are sitting there having dinner with this guy, and we tell him that we work on open-source and he happened to be a developer, and he wanted to explain how he had never ever once contributed to an open-source project.
48:01
We broke bread together, we had some drinks, we laughed a lot, we got a little lost, and the next day he submitted his first ever pull request to Glimpse. That was about six weeks ago, and he's quickly becoming one of the best contributors we've ever had. Actually, just last night I met a contributor face to face, and we had some really great conversation. I had no clue that he was going to be here.
48:23
We met, and now it's great, and I actually feel like our relationship is that much better than now we can communicate and help each other out. That's community management. Another nice thing about the norming phase is that your project is basically fairly well established, so you can start taking advantage of some of the perks
48:40
of the open-source community. There's lots of perks available. Anthony and I have a huge perk because our salaries are paid. That's what Redgate does. Redgate will give perks to any open-source project that qualifies. They'll give out free copies of Deployment Manager or other tools. There's a few companies that do that around. We use GitHub, which gives us all the source control
49:01
hosting for free. Microsoft, JetBrains, Atlassian, MyGet is a great service for open-source projects. What I realized, though, is that these perks are great. They give you the tools that you need to run your project efficiently, but there's not actually a listing anywhere. This weekend, I threw together a quick little website. It's also
49:21
open-source, called OSSPerks.com, where we're keeping a list of all the different tools and services that are available for open-source projects. If you see one missing, go to OSSPerks.com, contribute, you can fill it in. We're still working on the design. This is in beta, but hopefully
49:41
this will be a nice community repository. You're norming now. You're managing your community alright. You have some tools in place. Now we can start thinking about performing, and we're getting to the end of the life cycle here. This is the last of Tuckman's stages.
50:00
Performing, like I said, the individuals go away. We're dealing with one unit, which is a team. They anticipate each other's moves. What's really important about that is that when we're talking about team, it fundamentally means that the management overhead goes down. There's less of it because we're not dealing with a bunch of crazy cats everywhere. They're kind of all together.
50:22
Reducing management overhead is a really easy way to get to the performing stage sooner. A couple of ways to reduce management overhead is by automating everything. Once you have some of those perks in place, this is really easy. I'll share a couple of stories of things that we've done to automate. We use TeamCity
50:41
that was donated to us at CodeBetter.com, which means that when contributors who don't take the time to read our contributor's guidelines and make sure that their unit tests pass and all that kind of stuff submit code, TeamCity automatically grabs their pull request and builds it. We are positive now that they're building
51:01
and following some of those practices. We also have in our style guide naming conventions and the standards that we use for punctuation and braces and tabs versus spaces and all that kind of stuff. People still don't follow that even if they've read the document. We've automated that, and we use StyleCop now. If you go to build
51:21
your project after you've made some changes to it, you'll get warnings. We've merged together GitHub and TeamCity to use status updates for pull requests. That's what you're looking at here. This is a picture from GitHub that says that a pull request was good. It passed all of our rules. This is pretty
51:41
amazing, because we've had this happen about two times in the last month or so. Somebody will submit a pull request to us that doesn't follow one of our rules. The entire page goes red on them. They're like, crap. It's not going to work. It's basically the equivalent of breaking the build. Here's what's amazing. About 10, 15 minutes later, we saw another
52:01
commit go into that pull request, and it went green. We never had to talk to the contributor. We never had to say, hey, can you make this change? It's not the way that we want to do it, point out the documentation. The documentation has no teeth. The automated process does, and it ran them through the process the right way. One last example of how we
52:21
automated everything. This one is one that I particularly like, because it's worked very well. We have a lot of documentation. Glimpse, at the end of the day, is used by a lot of end users, people who are not interested in necessarily contributing back and making changes. They just want the value that comes out of the box. That's great, but those people need to understand how to use the software.
52:41
The software is geared in some aspects towards people who are learning the framework that Glimpse is sitting on top of. Documentation is key for us. We used to have documentation in our repo, and so just like any other code, you could go and make a pull request and change that documentation. That has a lot of overhead. That means people have to understand
53:01
Git, or they have to have a GitHub account, and all of these kinds of things. What we've done is we've moved to a wiki model where all you need to do is make a change. You do have to be authenticated, but you can just make the change. That wiki is our GitHub wiki, which is its own Git repository. Our website, which we deployed to Windows Azure
53:22
websites, that repository has our wiki repository as a sub-repository. We have hyperlinks on all of our websites, which is get-glimpse.com's documentation, where you can click on a link. It will take you right to the edit screen of that page in GitHub. You make some changes in the markdown, you save it,
53:41
and we can get that thing live with one command. Since we've made it that easy to contribute the documentation, you can go experiment with the process yourself if you'd like to, we get about three or four documentation contributions a week, which is a four or five time increase than what we were doing before. That's automating everything, we're talking about tooling. The last thing you're going to want to think about when
54:01
you're performing is how to help your community along. I wrote a blog article, that's what this link is here in this jump in, about a month ago. Over the last two years, I've had the exact same conversation a million times. I sit down with people at conferences and I ask them what they do, and when I tell them I do open source,
54:22
they start talking about, they start telling me about how they've tried to get involved with open source and why it hasn't worked. I hear the same reasons of why developers haven't been involved in open source in the past. They say, I find a project I want to help, but I need to read the entire code base, and I need to understand everything, and then I feel like I can contribute.
54:42
Which means, it's going to take you three months to catch up on two years worth of work from 40 different people, and you're never going to contribute in our case. Or I hear, yeah, I'm looking through the bug list, because I want to try to fix a bug, but the depth of knowledge that I need to understand to fix that bug, I need to understand the expected behavior, why this behavior is wrong, and how to fix it. It's just really deep,
55:02
so I'm having problems finding a good bug for me. Or they'll say, yeah, I could add a feature, but the breadth of the architecture that I need to understand to add that feature, and it feels like a big change, and I don't know if all that, my pull request will be accepted, blah, blah, blah, blah, right? I just hear this over and over and over again, and it's trying to get me really frustrated, because there needs to be a better way to get people into your projects. So what I
55:22
proposed is tagging issues specially with a tag called jump in. I think that this should just be a standard that all open source projects use, so I wrote about this on my blog, and what a jump in issue is, is it's not an issue for a junior developer, it's not for somebody who doesn't know how to program, it's specifically made,
55:40
it's an issue that can be solved within two or three nights worth of development, that doesn't depend on another piece of development that's currently in work, it's fairly standalone, it's not a fizz buzz test, it's not a hazing activity to make sure that developers who join your project are good, it's honestly just, this is an issue
56:01
that should be fairly easy for somebody to understand, you still need to know how to program well, you might need to know the technology that we're talking about, it's not about learning technology, it's just about getting involved. So, jump in I think is helpful, so we put up a bunch of jump in issues on our repository, within a week
56:20
all but one of them were completed, there's about four or five other open source projects who joined me in this effort, and I was actually just catching up with the maintainer of one of them last night, and all but one of his had been closed as well. So it seemed to really click with the community, we had a lot of people who had never contributed before show up and said yes, this is what I needed, so now we just need to kind of see this perpetuate so people start to expect it.
56:42
The last thing when it comes to creating opportunity is making sure that the people who have already done work for you know that you appreciate it. So the very first time Anthony and I ever got to do a podcast we wrote down all of the names of anybody who had ever contributed, both of them.
57:02
And we read their names on that podcast and we thanked them verbally by name, and we got a very nice email a few days later by the developer who we had mentioned and said, oh my gosh, my name was on Handsome Minutes, he was super excited and we totally get it, we're fans. And that guy we've gone on to have a two year relationship with
57:22
continues to this day to work with us to give us feedback and to contribute and it's just because we've been thankful we took the time to give him a pat on the back. So that's kind of most of it. This is everything that I've learned in the last two years. A lot of it was personal experience, a lot of it was me
57:40
standing on the shoulders of giants. I wanted to leave you with something that's kind of inspiring. So this is a picture of Thomas Edison and Henry Ford having a conversation and the quote there at the bottom is actually by Henry Ford and it says that coming together is a beginning keeping together is progress
58:02
but working together is success. So what I'm hoping that we're going to do is we're all going to start working together as Ford has said here. Does anybody have any questions or any answers because I'm trying to learn here as well.
58:22
I don't want this to be a presentation, I want this to be a conversation that starts here at NDC and builds out where we start to understand the maturity level at which we could have within the open source community particularly in .net but I'm not limiting it to that. So with that in mind actually this entire presentation is available
58:41
online at oss0to60.com the presentation in and of itself is open source. Creative Commons not because of the nice URL because that's the proper license as I've learned. Please contribute to it, re-present it at user groups that you might be a part of or in your developer community and let's just make this thing better
59:01
and a great resource for everyone. So that's what I got. Do we have any questions? We have one minute left. Yes. I actually do think it's right to start thinking about these issues as early
59:22
as possible. We did not start that way and I don't think most open source projects these days start that way because we there's this mantra of show us the code, put out the code, the code is what matters. I think that might be very true for getting something quick up there but if you actually want to build a lasting project that has
59:40
community, defining the interactions of the community is just as important as the architecture. So maybe it's not one before the other, maybe it's both of them in step but I think that it should come as early as possible. It doesn't mean that you can't change your governance model as you go but I think that that's something important for the community to understand and know exactly how to interact. I wish that we
01:00:00
had done it much earlier. When I read through the meritocratic model that I linked to for you guys I look at it and I'm like oh my gosh if we had done this we would have avoided that problem and that problem and that problem. So I'd say it's pretty important and should be thought about fairly early. And we are out of time. Guys thank you very much for staying all the way to the end
01:00:21
of NDC. Slave flights home everybody. I appreciate you being here. Thanks.