summaryrefslogtreecommitdiff
path: root/talermerchantdemos/blog/articles/en/when-free-software-isnt-practically-superior.html
blob: fc14ed1a86568918925f8babbcd308d134583865 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
<!--#include virtual="/server/header.html" -->
<!-- Parent-Version: 1.96 -->
<!-- This page is derived from /server/standards/boilerplate.html -->
<!--#set var="TAGS" value="essays aboutfs practice" -->
<!--#set var="DISABLE_TOP_ADDENDUM" value="yes" -->
<title> When Free Software Isn't (Practically) Superior - GNU Project - Free Software Foundation</title>
 <!--#include virtual="/philosophy/po/when-free-software-isnt-practically-superior.translist" -->
<!--#include virtual="/server/banner.html" -->
<!--#include virtual="/philosophy/ph-breadcrumb.html" -->
<!--GNUN: OUT-OF-DATE NOTICE-->
<!--#include virtual="/server/top-addendum.html" -->
<div class="article reduced-width">
<h2> When Free Software Isn't (Practically) Superior</h2>

<address class="byline">
by <a href="https://mako.cc/writing/">Benjamin Mako Hill</a></address>

<p>The Open Source Initiative's mission statement reads, &ldquo;Open source
is a development method for software that harnesses the power of
distributed peer review and transparency of process. The promise of
open source is better quality, higher reliability, more flexibility,
lower cost, and an end to predatory vendor lock-in.&rdquo;</p>

<p>For more than a decade now, the Free Software Foundation has argued
against this &ldquo;open source&rdquo; characterization of the free software
movement. Free software advocates have primarily argued against this
framing because &ldquo;open source&rdquo; is an explicit effort to deemphasize
our core message of freedom and obscure our movement's role in the
success of the software we have built. We have argued that &ldquo;open
source&rdquo; is bad, fundamentally, because it attempts to keep people from
talking about software freedom. But there is another reason we should
be wary of the open source framing. The fundamental open source
argument, as quoted in the mission statement above, is often
incorrect.</p>

<p>Although the Open Source Initiative suggests &ldquo;the promise of open
source is better quality, higher reliability, more flexibility,&rdquo; this
promise is not always realized. Although we do not often advertise the
fact, any user of an early-stage free software project can explain
that free software is not always as convenient, in purely practical
terms, as its proprietary competitors. Free software is sometimes low
quality. It is sometimes unreliable. It is sometimes inflexible. If
people take the arguments in favor of open source seriously, they must
explain why open source has not lived up to its &ldquo;promise&rdquo; and conclude
that proprietary tools would be a better choice. There is no reason we
should have to do either.</p>

<p>Richard Stallman speaks to this in his article on <a
href="/philosophy/open-source-misses-the-point.html">Why
Open Source Misses the Point</a> when he explains, &ldquo;The idea of open
source is that allowing users to change and redistribute the software
will make it more powerful and reliable. But this is not
guaranteed. Developers of proprietary software are not necessarily
incompetent. Sometimes they produce a program that is powerful and
reliable, even though it does not respect the users' freedom.&rdquo;</p>

<p>For open source, poor-quality software is a problem to be explained
away or a reason to eschew the software altogether. For free software,
it is a problem to be worked through. For free software advocates,
glitches and missing features are never a source of shame.
Any piece of free software that respects users' freedom has a strong
inherent advantage over a proprietary competitor that does not. Even
if it has other issues, free software always has freedom.</p>

<p>Of course, every piece of free software must start somewhere. A brand-new
piece of software, for example, is unlikely to be more featureful
than an established proprietary tool. Projects
begin with many bugs and improve over time. While open
source advocates might argue that a project will grow into usefulness
over time and with luck, free software projects represent important
contributions on day one to a free software advocate. Every piece of
software that gives users control over their technology is a step
forward. Improved quality as a project matures is the icing on the
cake.</p>

<p>A second, perhaps even more damning, fact is that the collaborative,
distributed, peer-review development process at the heart of the
definition of open source bears little resemblance to the practice of
software development in the vast majority of projects under free (or
&ldquo;open source&rdquo;) licenses.</p>

<p>Several academic studies of <a href="/software/repo-criteria.html">
free software hosting sites</a> SourceForge and <a
href="https://sv.gnu.org">Savannah</a> have shown what many free
software developers who have put a codebase online already know
first-hand. The vast majority of free software projects are not
particularly collaborative. The median number of contributors to a
free software project on SourceForge?  One. A lone
developer. SourceForge projects at the ninety-fifth percentile by
participant size have only five contributors. More than half of these
free software projects&mdash;and even most projects that have made several
successful releases and been downloaded frequently, are the work of a
single developer with little outside help.</p>

<p>By emphasizing the power of collaborative development and &ldquo;distributed
peer review,&rdquo; open source approaches seem to have very little to say
about why one should use, or contribute to, the vast majority of free
software projects. Because the purported benefits of collaboration
cannot be realized when there is no collaboration, the vast majority
of free development projects are at no technical advantage with respect to a
proprietary competitor.</p>

<p>For free software advocates, these same projects are each seen as
important successes. Because every piece of free software respects its
users' freedom, advocates of software freedom argue that each piece of
free software begins with an inherent ethical advantage over
proprietary competitors&mdash;even a more featureful one. By emphasizing
freedom over practical advantages, free software's advocacy is rooted
in a technical reality in a way that open source is often not. When
free software is better, we can celebrate this fact. When it is not,
we need not treat it as a damning critique of free software advocacy
or even as a compelling argument against the use of the software in
question.</p>

<p>Open source advocates must defend their thesis that freely developed
software should, or will with time, be better than proprietary
software. Free software supporters can instead ask, &ldquo;How can we make
free software better?&rdquo; In a free software framing, high quality software
exists as a means to an end rather than an end itself. Free software
developers should strive to create functional, flexible software that
serves its users well. But doing so is not the only way to make steps
toward solving what is both an easier and a much more profoundly
important goal: respecting and protecting their freedom.</p>

<p>Of course, we do not need to reject arguments that collaboration can
play an important role in creating high-quality software. In many of
the most successful free software projects, it clearly has done
exactly that. The benefits of collaboration become something to
understand, support, and work towards, rather than something to take
for granted in the face of evidence that refuses to conform to
ideology.</p>
</div>

</div><!-- for id="content", starts in the include above -->
<!--#include virtual="/server/footer.html" -->
<div id="footer" role="contentinfo">
<div class="unprintable">

<p>Please send general FSF &amp; GNU inquiries to
<a href="mailto:gnu@gnu.org">&lt;gnu@gnu.org&gt;</a>.
There are also <a href="/contact/">other ways to contact</a>
the FSF.  Broken links and other corrections or suggestions can be sent
to <a href="mailto:webmasters@gnu.org">&lt;webmasters@gnu.org&gt;</a>.</p>

<p><!-- TRANSLATORS: Ignore the original text in this paragraph,
        replace it with the translation of these two:

        We work hard and do our best to provide accurate, good quality
        translations.  However, we are not exempt from imperfection.
        Please send your comments and general suggestions in this regard
        to <a href="mailto:web-translators@gnu.org">
        &lt;web-translators@gnu.org&gt;</a>.</p>

        <p>For information on coordinating and contributing translations of
        our web pages, see <a
        href="/server/standards/README.translations.html">Translations
        README</a>. -->
Please see the <a
href="/server/standards/README.translations.html">Translations
README</a> for information on coordinating and contributing translations
of this article.</p>
</div>

<!-- Regarding copyright, in general, standalone pages (as opposed to
     files generated as part of manuals) on the GNU web server should
     be under CC BY-ND 4.0.  Please do NOT change or remove this
     without talking with the webmasters or licensing team first.
     Please make sure the copyright date is consistent with the
     document.  For web pages, it is ok to list just the latest year the
     document was modified, or published.
     
     If you wish to list earlier years, that is ok too.
     Either "2001, 2002, 2003" or "2001-2003" are ok for specifying
     years, as long as each year in the range is in fact a copyrightable
     year, i.e., a year in which the document was published (including
     being publicly visible on the web or in a revision control system).
     
     There is more detail about copyright years in the GNU Maintainers
     Information document, www.gnu.org/prep/maintain. -->

<p>Copyright &copy; 1999-2011 Benjamin Mako Hill</p>

<p>This page is licensed under a <a rel="license"
href="http://creativecommons.org/licenses/by-sa/3.0/us/">Creative
Commons Attribution-Share Alike 3.0 United States License</a>.</p>

<!--#include virtual="/server/bottom-notes.html" -->

<p class="unprintable">Updated:
<!-- timestamp start -->
$Date: 2021/09/05 10:10:11 $
<!-- timestamp end -->
</p>
</div>
</div><!-- for class="inner", starts in the banner include -->
</body>
</html>