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
|
<!--#set var="ENGLISH_PAGE" value="/philosophy/when-free-software-isnt-practically-superior.en.html" -->
<!--#include virtual="/server/header.zh-cn.html" -->
<!-- Parent-Version: 1.79 -->
<!-- This file is automatically generated by GNUnited Nations! -->
<title> 当自由软件（使用起来）并不更好时 - GNU工程 - 自由软件基金会</title>
<!--#include virtual="/philosophy/po/when-free-software-isnt-practically-superior.translist" -->
<!--#include virtual="/server/banner.zh-cn.html" -->
<h2> 当自由软件（使用起来）并不更好时</h2>
<p>
<a href="https://mako.cc/writing/"><strong>Benjamin Mako Hill</strong></a> 著</p>
<p>开源倡议的使命写得是，“开源是一种软件开发的方法，它利用的是分布式同行评议和透明的流程。开源承诺更好的质量、更高的可靠性、更多的灵活性、更低的成本以及消灭压榨式的供应商绑定。”</p>
<p>十多年来，自由软件基金会一直反对这种对自由软件运动的“开源”界定。自由软件倡导者反对“开源”框架的主要原因是，开源明确地淡化我们关于自由的核心理念、模糊我们在成功建立自由软件运动之中的角色。我们认为“开源”从根本上就是不好的，因为它企图阻止人们谈论软件自由。但是，我们还有另外一个原因要小心对待开源架构。就以上所述的使命，开源的基本观点并不正确。</p>
<p>虽然开源倡议说得是“承诺更好的质量、更高的可靠性、更多的灵活性”，但是这承诺并不总能兑现。诚然，我们通常不宣传，使用自由软件早期版本的用户还是可以理解自由软件和专有软件相比，从纯粹的实用观点来看，并不总是很方便好用的。自由软件的质量有时不好、可靠性也不太高、还不太灵活。如果人们用这些作为论据来严肃地为开源辩护，那么他们就必须解释为什么开源不能够兑现其
“承诺” 并得出选择专有软件或许更好的结论。对我们来说，这两个都不是问题。</p>
<p>Richard Stallman 在 <a
href="/philosophy/open-source-misses-the-point.html">为什么开源错失了重点</a>
一文中指出了这一点，他说，“开源认为允许用户修改和再发布软件就会使软件更强大和可靠。但这并没有保证。专有软件的开发者并不差，他们有时也能做出强大和可靠的软件，虽然这些软件无视用户的自由。”</p>
<p>对开源来说，差劲的软件是一个应该被辩解过去的问题或者是一个应该避开该软件的理由。对自由软件来说，这个软件正是我们要努力改进的问题。对自由软件的提倡者来说，软件的毛病和功能缺失从来就不是耻辱。一份尊重用户自由的自由软件内在的优势远远强于相应的专有软件。纵然自由软件有些毛病，但它总是拥有自由。</p>
<p>当然，千里之行，始于足下，自由软件也不例外。比如，有一个全新的自由软件，它很可能不会像一个已经历练了很久的专有软件那样功能丰富。项目总是带着许多问题开始，然后通过时间的考验而改进。虽然开源的倡导者可能会争辩说项目会通过时间和运气走向可用，但是对自由软件的倡导者来说，自由软件项目从第一天开始就代表着重要的贡献。每一个赋予用户对技术的自我掌控的软件都是进步。随着项目的进行，软件质量的提升则是锦上添花。</p>
<p>第二个，也许是更确凿的事实是，合作、分布、同行评议的开发流程作为开源的核心定义与绝大多数使用自由（或
“开源”）许可证的项目的开发实践并无相似之处。</p>
<p>好几个关于<a href="/software/repo-criteria.html">自由软件托管网站</a> SourceForge 和 <a
href="http://sv.gnu.org">Savannah</a>
的学术研究都指出一个众多把软件托管到网络的自由软件开发者早就已经知道的现象。绝大多数自由软件项目并不是合作开发的模式。SourceForge
上自由软件项目贡献者的中位数是多少?是 1。是一个单独的开发者。95% 的 SourceForge
项目的参与者只有5个人。其中超过半数的自由软件项目——甚至大多数成功发布了几版并有不菲下载量的项目都是由一个单一的开发者在没有外界帮助的情况下做出的作品。</p>
<p>除了强调协作式开发和“分布式同行评议”，开源似乎闭口不谈为什么人们应该使用或贡献于绝大多数的自由软件项目。因为他们所标榜的协作带来的好处在没有协作时是无法实现的，所以这些绝大多数自由软件项目和专有软件相比毫无技术优势。</p>
<p>对自由软件倡导者来说，还是这些项目，每个都是重要的成功。因为每个自由软件都尊重用户的自由，所以自由软件的倡导者可以说，每个自由软件一开始就有超越专有软件的天然道德优势—甚至超过那些拥有更多功能的专有软件。通过强调自由的优势超过实用，自由软件倡导者的技术基础往往和开源有所不同。当自由软件更好用时，我们为之喝彩。当自由软件不那么好用时，我们也不必认为这是对倡导自由软件的毁灭性批评，甚至也不会认为这是反对使用自由软件的有力证据。</p>
<p>开源的推动者必须固守他们的观点：自由开发的软件应该，或者随着时间的推移应该比专有软件更好。而自由软件的支持者会问，“我们怎样才能使自由软件更好？”在自由软件的框架里，高质量的软件是达到目标的手段而不是目标本身。自由软件的开发者应该努力开发功能强大、灵活度高的软件来更好地为用户服务。但是这样做并不是解决容易然而意义更为重大的目标的唯一途径，这个目标就是尊重并保护用户的自由。</p>
<p>当然，我们也不必抛弃协作有助于开发高质量软件的观点。在众多最成功的自由软件项目中，协作显然证明了这一点。协作的好处应该成为被理解、支持和共同努力的方向，而不是成为面临与理念不符的证据时的想当然。</p>
<div class="translators-notes">
<!--TRANSLATORS: Use space (SPC) as msgstr if you don't have notes.-->
</div>
</div>
<!-- for id="content", starts in the include above -->
<!--#include virtual="/server/footer.zh-cn.html" -->
<div id="footer">
<div class="unprintable">
<p>请将有关自由软件基金会（FSF）&GNU的一般性问题发送到<a
href="mailto:gnu@gnu.org"><gnu@gnu.org></a>。也可以通过<a
href="/contact/">其他联系方法</a>联系自由软件基金会(FSF)。请将无效链接，其他错误或建议发送给<a
href="mailto:webmasters@gnu.org"><webmasters@gnu.org></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">
<web-translators@gnu.org></a>.</p>
<p>For information on coordinating and submitting translations of
our web pages, see <a
href="/server/standards/README.translations.html">Translations
README</a>. -->
若您想翻译本文，请参看<a href="/server/standards/README.translations.html">翻译须知</a>。</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 © 1999-2011 Benjamin Mako Hill</p>
<p>本页面使用<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.zh-cn.html" -->
<div class="translators-credits">
<!--TRANSLATORS: Use space (SPC) as msgstr if you don't want credits.-->
<b>翻译团队</b>：<a rel="team"
href="https://savannah.gnu.org/projects/www-zh-cn/"><CTT></a>，2019。</div>
<p class="unprintable"><!-- timestamp start -->
最后更新：
$Date: 2019/03/24 13:32:57 $
<!-- timestamp end -->
</p>
</div>
</div>
</body>
</html>
|
