taler-merchant-demos

Python-based Frontends for the Demonstration Web site
Log | Files | Refs | Submodules | README | LICENSE

when-free-software-isnt-practically-superior.html (10272B)


      1 <!--#include virtual="/server/header.html" -->
      2 <!-- Parent-Version: 1.96 -->
      3 <!-- This page is derived from /server/standards/boilerplate.html -->
      4 <!--#set var="TAGS" value="essays aboutfs practice" -->
      5 <!--#set var="DISABLE_TOP_ADDENDUM" value="yes" -->
      6 <title> When Free Software Isn't (Practically) Superior - GNU Project - Free Software Foundation</title>
      7  <!--#include virtual="/philosophy/po/when-free-software-isnt-practically-superior.translist" -->
      8 <!--#include virtual="/server/banner.html" -->
      9 <!--#include virtual="/philosophy/ph-breadcrumb.html" -->
     10 <!--GNUN: OUT-OF-DATE NOTICE-->
     11 <!--#include virtual="/server/top-addendum.html" -->
     12 <div class="article reduced-width">
     13 <h2> When Free Software Isn't (Practically) Superior</h2>
     14 
     15 <address class="byline">
     16 by <a href="https://mako.cc/writing/">Benjamin Mako Hill</a></address>
     17 
     18 <p>The Open Source Initiative's mission statement reads, &ldquo;Open source
     19 is a development method for software that harnesses the power of
     20 distributed peer review and transparency of process. The promise of
     21 open source is better quality, higher reliability, more flexibility,
     22 lower cost, and an end to predatory vendor lock-in.&rdquo;</p>
     23 
     24 <p>For more than a decade now, the Free Software Foundation has argued
     25 against this &ldquo;open source&rdquo; characterization of the free software
     26 movement. Free software advocates have primarily argued against this
     27 framing because &ldquo;open source&rdquo; is an explicit effort to deemphasize
     28 our core message of freedom and obscure our movement's role in the
     29 success of the software we have built. We have argued that &ldquo;open
     30 source&rdquo; is bad, fundamentally, because it attempts to keep people from
     31 talking about software freedom. But there is another reason we should
     32 be wary of the open source framing. The fundamental open source
     33 argument, as quoted in the mission statement above, is often
     34 incorrect.</p>
     35 
     36 <p>Although the Open Source Initiative suggests &ldquo;the promise of open
     37 source is better quality, higher reliability, more flexibility,&rdquo; this
     38 promise is not always realized. Although we do not often advertise the
     39 fact, any user of an early-stage free software project can explain
     40 that free software is not always as convenient, in purely practical
     41 terms, as its proprietary competitors. Free software is sometimes low
     42 quality. It is sometimes unreliable. It is sometimes inflexible. If
     43 people take the arguments in favor of open source seriously, they must
     44 explain why open source has not lived up to its &ldquo;promise&rdquo; and conclude
     45 that proprietary tools would be a better choice. There is no reason we
     46 should have to do either.</p>
     47 
     48 <p>Richard Stallman speaks to this in his article on <a
     49 href="/philosophy/open-source-misses-the-point.html">Why
     50 Open Source Misses the Point</a> when he explains, &ldquo;The idea of open
     51 source is that allowing users to change and redistribute the software
     52 will make it more powerful and reliable. But this is not
     53 guaranteed. Developers of proprietary software are not necessarily
     54 incompetent. Sometimes they produce a program that is powerful and
     55 reliable, even though it does not respect the users' freedom.&rdquo;</p>
     56 
     57 <p>For open source, poor-quality software is a problem to be explained
     58 away or a reason to eschew the software altogether. For free software,
     59 it is a problem to be worked through. For free software advocates,
     60 glitches and missing features are never a source of shame.
     61 Any piece of free software that respects users' freedom has a strong
     62 inherent advantage over a proprietary competitor that does not. Even
     63 if it has other issues, free software always has freedom.</p>
     64 
     65 <p>Of course, every piece of free software must start somewhere. A brand-new
     66 piece of software, for example, is unlikely to be more featureful
     67 than an established proprietary tool. Projects
     68 begin with many bugs and improve over time. While open
     69 source advocates might argue that a project will grow into usefulness
     70 over time and with luck, free software projects represent important
     71 contributions on day one to a free software advocate. Every piece of
     72 software that gives users control over their technology is a step
     73 forward. Improved quality as a project matures is the icing on the
     74 cake.</p>
     75 
     76 <p>A second, perhaps even more damning, fact is that the collaborative,
     77 distributed, peer-review development process at the heart of the
     78 definition of open source bears little resemblance to the practice of
     79 software development in the vast majority of projects under free (or
     80 &ldquo;open source&rdquo;) licenses.</p>
     81 
     82 <p>Several academic studies of <a href="/software/repo-criteria.html">
     83 free software hosting sites</a> SourceForge and <a
     84 href="https://sv.gnu.org">Savannah</a> have shown what many free
     85 software developers who have put a codebase online already know
     86 first-hand. The vast majority of free software projects are not
     87 particularly collaborative. The median number of contributors to a
     88 free software project on SourceForge?  One. A lone
     89 developer. SourceForge projects at the ninety-fifth percentile by
     90 participant size have only five contributors. More than half of these
     91 free software projects&mdash;and even most projects that have made several
     92 successful releases and been downloaded frequently, are the work of a
     93 single developer with little outside help.</p>
     94 
     95 <p>By emphasizing the power of collaborative development and &ldquo;distributed
     96 peer review,&rdquo; open source approaches seem to have very little to say
     97 about why one should use, or contribute to, the vast majority of free
     98 software projects. Because the purported benefits of collaboration
     99 cannot be realized when there is no collaboration, the vast majority
    100 of free development projects are at no technical advantage with respect to a
    101 proprietary competitor.</p>
    102 
    103 <p>For free software advocates, these same projects are each seen as
    104 important successes. Because every piece of free software respects its
    105 users' freedom, advocates of software freedom argue that each piece of
    106 free software begins with an inherent ethical advantage over
    107 proprietary competitors&mdash;even a more featureful one. By emphasizing
    108 freedom over practical advantages, free software's advocacy is rooted
    109 in a technical reality in a way that open source is often not. When
    110 free software is better, we can celebrate this fact. When it is not,
    111 we need not treat it as a damning critique of free software advocacy
    112 or even as a compelling argument against the use of the software in
    113 question.</p>
    114 
    115 <p>Open source advocates must defend their thesis that freely developed
    116 software should, or will with time, be better than proprietary
    117 software. Free software supporters can instead ask, &ldquo;How can we make
    118 free software better?&rdquo; In a free software framing, high quality software
    119 exists as a means to an end rather than an end itself. Free software
    120 developers should strive to create functional, flexible software that
    121 serves its users well. But doing so is not the only way to make steps
    122 toward solving what is both an easier and a much more profoundly
    123 important goal: respecting and protecting their freedom.</p>
    124 
    125 <p>Of course, we do not need to reject arguments that collaboration can
    126 play an important role in creating high-quality software. In many of
    127 the most successful free software projects, it clearly has done
    128 exactly that. The benefits of collaboration become something to
    129 understand, support, and work towards, rather than something to take
    130 for granted in the face of evidence that refuses to conform to
    131 ideology.</p>
    132 </div>
    133 
    134 </div><!-- for id="content", starts in the include above -->
    135 <!--#include virtual="/server/footer.html" -->
    136 <div id="footer" role="contentinfo">
    137 <div class="unprintable">
    138 
    139 <p>Please send general FSF &amp; GNU inquiries to
    140 <a href="mailto:gnu@gnu.org">&lt;gnu@gnu.org&gt;</a>.
    141 There are also <a href="/contact/">other ways to contact</a>
    142 the FSF.  Broken links and other corrections or suggestions can be sent
    143 to <a href="mailto:webmasters@gnu.org">&lt;webmasters@gnu.org&gt;</a>.</p>
    144 
    145 <p><!-- TRANSLATORS: Ignore the original text in this paragraph,
    146         replace it with the translation of these two:
    147 
    148         We work hard and do our best to provide accurate, good quality
    149         translations.  However, we are not exempt from imperfection.
    150         Please send your comments and general suggestions in this regard
    151         to <a href="mailto:web-translators@gnu.org">
    152         &lt;web-translators@gnu.org&gt;</a>.</p>
    153 
    154         <p>For information on coordinating and contributing translations of
    155         our web pages, see <a
    156         href="/server/standards/README.translations.html">Translations
    157         README</a>. -->
    158 Please see the <a
    159 href="/server/standards/README.translations.html">Translations
    160 README</a> for information on coordinating and contributing translations
    161 of this article.</p>
    162 </div>
    163 
    164 <!-- Regarding copyright, in general, standalone pages (as opposed to
    165      files generated as part of manuals) on the GNU web server should
    166      be under CC BY-ND 4.0.  Please do NOT change or remove this
    167      without talking with the webmasters or licensing team first.
    168      Please make sure the copyright date is consistent with the
    169      document.  For web pages, it is ok to list just the latest year the
    170      document was modified, or published.
    171      
    172      If you wish to list earlier years, that is ok too.
    173      Either "2001, 2002, 2003" or "2001-2003" are ok for specifying
    174      years, as long as each year in the range is in fact a copyrightable
    175      year, i.e., a year in which the document was published (including
    176      being publicly visible on the web or in a revision control system).
    177      
    178      There is more detail about copyright years in the GNU Maintainers
    179      Information document, www.gnu.org/prep/maintain. -->
    180 
    181 <p>Copyright &copy; 1999-2011 Benjamin Mako Hill</p>
    182 
    183 <p>This page is licensed under a <a rel="license"
    184 href="http://creativecommons.org/licenses/by-sa/3.0/us/">Creative
    185 Commons Attribution-Share Alike 3.0 United States License</a>.</p>
    186 
    187 <!--#include virtual="/server/bottom-notes.html" -->
    188 
    189 <p class="unprintable">Updated:
    190 <!-- timestamp start -->
    191 $Date: 2021/09/05 10:10:11 $
    192 <!-- timestamp end -->
    193 </p>
    194 </div>
    195 </div><!-- for class="inner", starts in the banner include -->
    196 </body>
    197 </html>