{"id":1945,"date":"2012-04-01T07:57:37","date_gmt":"2012-04-01T11:57:37","guid":{"rendered":"http:\/\/2d823b65bb.nxcli.io\/?p=1945"},"modified":"2012-04-01T09:48:26","modified_gmt":"2012-04-01T13:48:26","slug":"free-software-marketing-community-metrics","status":"publish","type":"post","link":"https:\/\/www.robweir.com\/blog\/2012\/04\/free-software-marketing-community-metrics.html","title":{"rendered":"Gorilla Free Software Marketing, Chapter 8: Community Metrics"},"content":{"rendered":"<h2>The Importance of Metrics<\/h2>\n<p>Revolutionary movements require revolutionary progress.\u00a0 However, at the start of a Movement, such progress may not be immediately evident to those whose views of progress have been tainted by commercial software, where progress is measured by feature enhancements, quality improvements and user satisfaction.\u00a0 These are false idols and the shallow view of progress they support are irrelevant for true free software.<\/p>\n<p>Rejecting the repressive capitalist view of progress-as-production and production-as-consumption, and the doctrinaire emphasis on results-oriented metrics, we instead adopt the dialectic of progress-as-being and being-as-becoming, with metrics illustrating not what is produced, but what is willed.\u00a0 Rather than galley slaves, prodded by whip lashes to &#8220;row harder!&#8221;, our motto\u00a0 shall be: &#8220;row louder!&#8221;<\/p>\n<p>As Mark Twain famously wrote,\u00a0 &#8220;There are three kinds of lies: lies, damned lies, and statistics.&#8221;\u00a0\u00a0 Our aim in developing metrics is to avoid the taint of this condemnation by avoiding the statistical sciences entirely.<\/p>\n<p>Two metrics that any free software marketeer must be able to produce are:<\/p>\n<ul>\n<li>A measure of the <strong>size of the community<\/strong>, in order to demonstrate the overwhelming strength and vigorous growth of our Movement.<\/li>\n<li>A measure of the <strong>diversity of the community<\/strong>, in order to demonstrate that it is a true People&#8217;s Movement with a broad base of support.<\/li>\n<\/ul>\n<h2>Community Size<\/h2>\n<p>A metric that can never disappoint is\u00a0 &#8220;cumulative number of developers&#8221; on the project.\u00a0 Calculating this metric is simple:\u00a0 count the total number of individuals who have contributed to the project since it started.\u00a0 You are not concerned with the number of contributions, the quality of contributions, whether the person did one patch and then was never seen again, or any other extraneous detail. You&#8217;re just counting names.\u00a0 Any project can use this metric to show month-after-month steady improvements.<\/p>\n<p>The genius of this metric is that it can never decrease. It is mathematically impossible!\u00a0 Once a name is added to your list, it is never removed.\u00a0 One a contributor, always a contributor, at least on paper.\u00a0 Worst case, even if an asteroid should hit your next project conference and kill every one of your developers, you could still report that your numbers were flat.\u00a0 Unfortunately, your developers would be as well.<\/p>\n<p>Advanced marketeers should also note the following additional techniques, which can be used to generate even more impressive numbers without additional effort:<\/p>\n<ul>\n<li>Don&#8217;t just count those who are writing code.\u00a0\u00a0 Almost anyone can be called a &#8220;developer&#8221; these days.\u00a0 Translators (&#8220;Localization Engineers&#8221;), build lab guys (&#8220;Configuration Management Engineers&#8221;), testers (Software Quality Engineers),\u00a0 etc.\u00a0 Include all of their contributions.<\/li>\n<li>Don&#8217;t limit yourself to those who actively contributed code to your project.\u00a0 You can also include developers who contributed to precursor versions of your code, or who contributed to 3rd party modules. They might not even know that their code is in your product, but that doesn&#8217;t matter.\u00a0 We appreciate their &#8220;contribution&#8221;\u00a0 nonetheless and should acknowledge them as an integral part of our thriving community, in spirit at least.<\/li>\n<li>One you have made the novel step of\u00a0 counting non-project members as developers, there is nothing in principle against extending this even further to the developers of the tool set and libraries you are using.\u00a0\u00a0 Credit them all, living, dead and legendary.\u00a0 Larry Wall, Dennis Ritchie,\u00a0 Alan Turing, and St. Hubertus, patron saint of mathematicians, can all be listed as developers on your project.<\/li>\n<li>With some advance planning your project&#8217;s development team can help increase these numbers even more.\u00a0 Have them think of some simple text manipulation tasks that can be done by volunteers with little knowledge or understanding of the code.\u00a0 For example, have them do things like reformat code,\u00a0 spell check comments, alphabetize include directives, ensure that every C\/C++ file ends with a newline character, etc.\u00a0 Although this will not improve the product for your users, it will enable a much larger group of contributors to get involved so we can add their name to our list.\u00a0 And once on the list, it stays on the list forever.\u00a0 I am told on reliable authority that such code changes are perfectly safe and cannot have a negative impact on product quality.<\/li>\n<\/ul>\n<p>But be warned: use of these advanced techniques might open you up to criticism of promoting numbers that are meaningless, that they saying nothing about the actual size or composition of your development community.\u00a0\u00a0 Such criticism can easily be dismissed by feigning to be insulted and responding along the lines, &#8220;How could you possibly suggest that we not recognize the hard-working {translators | build lab guys | testers | dead mathematicians |\u00a0 patron saints} who {contributed to|had stuff we took without their knowledge for} our project?&#8221;.\u00a0\u00a0 This argument will almost win, since no one will want to appear ungenerous, especially when intercessory saints are involved.<\/p>\n<h2>Community Diversity<\/h2>\n<p>Another metric that you might be asked for is a metric to illustrate how much of the project is dependent on any one company, such as the project&#8217;s main sponsor.\u00a0\u00a0\u00a0 A common error is to look at the contributions made to the project and report how much was apportioned to which individuals and companies, based on recognized software metrics, like # of commits, lines of code, function points, etc.\u00a0 You must not fall into that trap!<\/p>\n<p>A much better metric, if you want to be seen as diverse, is to count the number of developers in each company. Do this without regard to whether the person made a one line change 2 years ago and was never heard of again, or whether the person works 14 hours a day on the project every day. Just look at the number of developers. \u00a0 If you have already followed the advice outlined above, and increased your &#8220;cumulative number of developers&#8221; metric, then you are perfectly positioned to also demonstrate your diversity.<\/p>\n<p>For example, suppose you have 400 developers, and 10 of them do 90% of the work, and they are employed by a single company.\u00a0 Avoid the naive mistake of saying that one company was responsible for 90% of the contributions.\u00a0 Instead say that the company&#8217;s developers (note we&#8217;re emphasizing people not work) represent 10\/400 or only 4% of the project.\u00a0\u00a0 That is the genius of this metric.\u00a0 You can have almost all the work done by a single company and still claim that your community is diverse.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>The Importance of Metrics Revolutionary movements require revolutionary progress.\u00a0 However, at the start of a Movement, such progress may not be immediately evident to those whose views of progress have been tainted by commercial software, where progress is measured by feature enhancements, quality improvements and user satisfaction.\u00a0 These are false idols and the shallow view [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_genesis_hide_title":false,"_genesis_hide_breadcrumbs":false,"_genesis_hide_singular_image":false,"_genesis_hide_footer_widgets":false,"_genesis_custom_body_class":"","_genesis_custom_post_class":"","_genesis_layout":"","footnotes":""},"categories":[212,64],"tags":[],"class_list":{"0":"post-1945","1":"post","2":"type-post","3":"status-publish","4":"format-standard","6":"category-humor","7":"category-open-source","8":"entry"},"_links":{"self":[{"href":"https:\/\/www.robweir.com\/blog\/wp-json\/wp\/v2\/posts\/1945","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.robweir.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.robweir.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.robweir.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.robweir.com\/blog\/wp-json\/wp\/v2\/comments?post=1945"}],"version-history":[{"count":21,"href":"https:\/\/www.robweir.com\/blog\/wp-json\/wp\/v2\/posts\/1945\/revisions"}],"predecessor-version":[{"id":1966,"href":"https:\/\/www.robweir.com\/blog\/wp-json\/wp\/v2\/posts\/1945\/revisions\/1966"}],"wp:attachment":[{"href":"https:\/\/www.robweir.com\/blog\/wp-json\/wp\/v2\/media?parent=1945"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.robweir.com\/blog\/wp-json\/wp\/v2\/categories?post=1945"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.robweir.com\/blog\/wp-json\/wp\/v2\/tags?post=1945"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}