{"id":1030,"date":"2012-10-29T14:32:29","date_gmt":"2012-10-29T19:32:29","guid":{"rendered":"http:\/\/redmonk.com\/dberkholz\/?p=1030"},"modified":"2012-10-30T10:48:35","modified_gmt":"2012-10-30T15:48:35","slug":"githubs-success-and-low-barriers-to-entry","status":"publish","type":"post","link":"https:\/\/redmonk.com\/dberkholz\/2012\/10\/29\/githubs-success-and-low-barriers-to-entry\/","title":{"rendered":"On developer success, GitHub, and low barriers to entry"},"content":{"rendered":"<p>I recently came across an intriguing post <a href=\"http:\/\/blog.leif.me\/2012\/09\/github-testing\/\">describing<\/a> academic research on how GitHub has affected developer culture. This is a specific case study of something I spend a lot of time talking and thinking about &#8212; how toolsets strongly influence the cultural norms, governance, and processes of the teams using them.<\/p>\n<p>In this instance, here&#8217;s what the researchers found:<\/p>\n<ul>\n<li><strong>Transparency improves on-ramps to a project.<\/strong> Put simply, it&#8217;s easier to learn how the culture works when it&#8217;s possible to <a href=\"http:\/\/en.wikipedia.org\/wiki\/Lurker\">lurk<\/a>. When you can&#8217;t see how people interact and develop collaboratively either externally or as a new contributor, it lengthens the time it takes to become a productive developer.<\/li>\n<li><strong>Continuous integration, and more broadly testing as a whole, must be easy to use if it&#8217;s going to be used at all.<\/strong> Making it a pain to submit things for testing means developers will skip it. If tools like Jenkins are so cleanly integrated into your ALM toolchain that contributors don&#8217;t even need to think about them unless the build\/tests break, then their adoption will vastly increase.<\/li>\n<li><strong>One-off commits are a frequent occurrence when contributing is trivial.<\/strong> A user who is otherwise uninvolved in the project as a developer might make a one-time contribution because it&#8217;s so easy to do so. When you require users to fill out forms, register for barely usable software, etc., then you lose a lot of these potential contributions.<\/li>\n<li><strong>More negatively, a focus on build- and test-driven development has resulted in fewer tests for bad input.<\/strong> Many newer contributors have never learned to write test suites, but senior developers assume the opposite. Using BDD\/TDD without teaching &#8220;safe testing&#8221; leads to a lack of tests for invalid results and functionality, only tests to confirm that the intended results occur upon the intended input.<\/li>\n<\/ul>\n<p>The changes involving barriers to entry mirror what we&#8217;ve been saying at RedMonk for <a href=\"http:\/\/redmonk.com\/sogrady\/2006\/03\/03\/free-code-no-barriers-to-entry\/\">years<\/a>. I would further add that<strong> the potential for one-off commits dramatically increases the size of the opening of your recruitment <a href=\"http:\/\/redmonk.com\/dberkholz\/2012\/04\/18\/adoption-of-software-is-a-funnel\/\">funnel<\/a><\/strong>, which gives you many more opportunities to grow your developer community. The existence of a whole new class of first-time contributors in what has become the standard model for contribution, GitHub, means this:<\/p>\n<blockquote><p>Some projects that perceived themselves as inevitably shrinking are, in reality, only failing to keep up with the pace of expectations in open-source development.<\/p><\/blockquote>\n<p><em>Disclosure: GitHub and\u00a0<em>CloudBees (which employs Jenkins founder Kohsuke Kawaguchi) are former clients.<\/em><br \/>\n<\/em><\/p>\n<div class=\"acc_license\"><a href=\"http:\/\/creativecommons.org\/licenses\/by-sa\/3.0\/\"><img decoding=\"async\" src=\"http:\/\/i.creativecommons.org\/l\/by-sa\/3.0\/88x31.png\" alt=\"by-sa\" \/><\/a><\/div><!--<rdf:RDF xmlns=\"http:\/\/creativecommons.org\/ns#\" xmlns:dc=\"http:\/\/purl.org\/dc\/elements\/1.1\/\" xmlns:rdf=\"http:\/\/www.w3.org\/1999\/02\/22-rdf-syntax-ns#\"><Work rdf:about=\"\"><license rdf:resource=\"http:\/\/creativecommons.org\/licenses\/by-sa\/3.0\/\" \/><\/Work><License rdf:about=\"http:\/\/creativecommons.org\/licenses\/by-sa\/3.0\/\"><requires rdf:resource=\"http:\/\/creativecommons.org\/ns#Attribution\" \/><permits rdf:resource=\"http:\/\/creativecommons.org\/ns#Reproduction\" \/><permits rdf:resource=\"http:\/\/creativecommons.org\/ns#Distribution\" \/><permits rdf:resource=\"http:\/\/creativecommons.org\/ns#DerivativeWorks\" \/><requires rdf:resource=\"http:\/\/creativecommons.org\/ns#ShareAlike\" \/><requires rdf:resource=\"http:\/\/creativecommons.org\/ns#Notice\" \/><\/License><\/rdf:RDF>-->","protected":false},"excerpt":{"rendered":"<p>I recently came across an intriguing post describing academic research on how GitHub has affected developer culture. This is a specific case study of something I spend a lot of time talking and thinking about &#8212; how toolsets strongly influence the cultural norms, governance, and processes of the teams using them. In this instance, here&#8217;s<\/p>\n","protected":false},"author":6,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"spay_email":"","footnotes":"","jetpack_publicize_message":"","jetpack_is_tweetstorm":false},"categories":[3,18,13,22],"tags":[],"class_list":["post-1030","post","type-post","status-publish","format-standard","hentry","category-adoption","category-community","category-open-source","category-social"],"jetpack_featured_media_url":"","jetpack_publicize_connections":[],"jetpack_sharing_enabled":true,"jetpack_shortlink":"https:\/\/wp.me\/p23Tsn-gC","_links":{"self":[{"href":"https:\/\/redmonk.com\/dberkholz\/wp-json\/wp\/v2\/posts\/1030","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/redmonk.com\/dberkholz\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/redmonk.com\/dberkholz\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/redmonk.com\/dberkholz\/wp-json\/wp\/v2\/users\/6"}],"replies":[{"embeddable":true,"href":"https:\/\/redmonk.com\/dberkholz\/wp-json\/wp\/v2\/comments?post=1030"}],"version-history":[{"count":0,"href":"https:\/\/redmonk.com\/dberkholz\/wp-json\/wp\/v2\/posts\/1030\/revisions"}],"wp:attachment":[{"href":"https:\/\/redmonk.com\/dberkholz\/wp-json\/wp\/v2\/media?parent=1030"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/redmonk.com\/dberkholz\/wp-json\/wp\/v2\/categories?post=1030"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/redmonk.com\/dberkholz\/wp-json\/wp\/v2\/tags?post=1030"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}