开源软件开发实践：如何运营成功的自由软件项目

需积分: 9 100 浏览量更新于2024-07-29 收藏 1.5MB PDF 举报

" Producing Open Source Software - 如何成功运作自由软件项目，作者 Karl Fogel，根据 Creative Commons Attribution-ShareAlike 3.0 许可证授权" 本书《Producing Open Source Software》深入探讨了开源软件开发的管理与运作策略，旨在帮助项目团队创建并维护一个成功的开源软件项目。作者 Karl Fogel 在书中分享了他的经验和见解，以指导读者如何在开源社区中建立影响力，吸引贡献者，并确保项目的可持续发展。 1. **开源软件的历史与现状** - 开源软件的发展历程：书中提到了从专有软件时代到免费软件（Free Software）运动的兴起，再到后来的开源软件（Open Source Software）概念的诞生。 - 意识上的抵抗与无意识的阻碍：开源运动经历了从对抗专有软件的传统观念到逐渐被接纳的过程。 - “免费”与“开源”的区别：虽然两者在实践中密切相关，但它们代表的理念和重点有所不同。 - 当前情况：开源软件已成为现代软件开发的主流，影响着企业和个人开发者的行为模式。 2. **开始开源项目** - 基于现有资源启动：利用现有的代码库、技能和团队开始开源项目。 - 选择一个好的名字：项目名称应具有代表性且易于记忆。 - 明确的使命声明：清晰地阐述项目的目标和价值。 - 公开自由性质：明确项目是开源的，鼓励贡献和使用。 - 特性与需求列表：列出项目的核心功能和待实现的需求。 - 项目状态：更新项目进度，向社区展示其发展情况。 - 下载和版本控制：提供方便的下载方式，采用版本控制系统管理代码。 - 错误跟踪系统：让问题报告和解决过程透明化。 - 通信渠道：设立论坛、邮件列表或即时通讯工具，促进交流。 - 开发者指南：制定开发规范，引导新成员快速融入团队。 - 文档：提供详尽的用户和开发者文档，包括示例输出和截图。 - 托管服务：考虑使用开源托管平台，如 GitHub 或 GitLab，简化项目管理。通过这些步骤，作者 Karl Fogel 希望帮助读者理解如何有效地启动和运营一个开源项目，同时激发社区参与，推动项目的持续成长。这本书不仅是对开源社区规则的介绍，更是对开源项目管理实践的宝贵指南。

or as dependably as they could.

This book is about avoiding failure. It examines not only how to do things right, but

how to do them wrong, so you can recognize and correct problems early. My hope is

that after reading it, you will have a repertory of techniques not just for avoiding

common pitfalls of open source development, but also for dealing with the growth and

maintenance of a successful project. Success is not a zero-sum game, and this book

is not about winning or getting ahead of the competition. Indeed, an important part of

running an open source project is working smoothly with other, related projects. In the

long run, every successful project contributes to the well-being of the overall,

worldwide body of free software.

It would be tempting to say that free software projects fail for the same sorts of

reasons proprietary software projects do. Certainly, free software has no monopoly

on unrealistic requirements, vague specifications, poor resource management,

insufficient design phases, or any of the other hobgoblins already well known to the

software industry. There is a huge body of writing on these topics, and I will try not to

duplicate it in this book. Instead, I will attempt to describe the problems peculiar to

free software. When a free software project runs aground, it is often because the

developers (or the managers) did not appreciate the unique problems of open source

software development, even though they might have been quite prepared for the

better-known difficulties of closed-source development.

One of the most common mistakes is unrealistic expectations about the benefits of

open source itself. An open license does not guarantee that hordes of active

developers will suddenly volunteer their time to your project, nor does open-sourcing

a troubled project automatically cure its ills. In fact, quite the opposite: opening up a

project can add whole new sets of complexities, and cost more in the short term than

simply keeping it in-house. Opening up means arranging the code to be

comprehensible to complete strangers, setting up a development web site and email

lists, and often writing documentation for the first time. All this is a lot of work. And of

course, if any interested developers do show up, there is the added burden of

answering their questions for a while before seeing any benefit from their presence.

As developer Jamie Zawinski said about the troubled early days of the Mozilla

Producing Open Source Software http://producingoss.com/en/producingoss.html

16 of 365 2012年04月08日 20:42

project:

Open source does work, but it is most definitely not a panacea. If there's a

cautionary tale here, it is that you can't take a dying project, sprinkle it with

the magic pixie dust of "open source," and have everything magically work

out. Software is hard. The issues aren't that simple.

(from

http://www.jwz.org/gruntle/nomo.html)

A related mistake is that of skimping on presentation and packaging, figuring that

these can always be done later, when the project is well under way. Presentation and

packaging comprise a wide range of tasks, all revolving around the theme of reducing

the barrier to entry. Making the project inviting to the uninitiated means writing user

and developer documentation, setting up a project web site that's informative to

newcomers, automating as much of the software's compilation and installation as

possible, etc. Many programmers unfortunately treat this work as being of secondary

importance to the code itself. There are a couple of reasons for this. First, it can feel

like busywork, because its benefits are most visible to those least familiar with the

project, and vice versa. After all, the people who develop the code don't really need

the packaging. They already know how to install, administer, and use the software,

because they wrote it. Second, the skills required to do presentation and packaging

well are often completely different from those required to write code. People tend to

focus on what they're good at, even if it might serve the project better to spend a little

time on something that suits them less.

Chapter 2, Getting Started discusses

presentation and packaging in detail, and explains why it's crucial that they be a

priority from the very start of the project.

Next comes the fallacy that little or no project management is required in open

source, or conversely, that the same management practices used for in-house

development will work equally well on an open source project. Management in an

open source project isn't always very visible, but in the successful projects, it's

usually happening behind the scenes in some form or another. A small thought

experiment suffices to show why. An open source project consists of a random

collection of programmers—already a notoriously independent-minded

Producing Open Source Software http://producingoss.com/en/producingoss.html

17 of 365 2012年04月08日 20:42

category—who have most likely never met each other, and who may each have

different personal goals in working on the project. The thought experiment is simply to

imagine what would happen to such a group without management. Barring miracles,

it would collapse or drift apart very quickly. Things won't simply run themselves, much

as we might wish otherwise. But the management, though it may be quite active, is

often informal, subtle, and low-key. The only thing keeping a development group

together is their shared belief that they can do more in concert than individually. Thus

the goal of management is mostly to ensure that they continue to believe this, by

setting standards for communications, by making sure useful developers don't get

marginalized due to personal idiosyncracies, and in general by making the project a

place developers want to keep coming back to. Specific techniques for doing this are

discussed throughout the rest of this book.

Finally, there is a general category of problems that may be called "failures of cultural

navigation." Ten years ago, even five, it would have been premature to talk about a

global culture of free software, but not anymore. A recognizable culture has slowly

emerged, and while it is certainly not monolithic—it is at least as prone to internal

dissent and factionalism as any geographically bound culture—it does have a

basically consistent core. Most successful open source projects exhibit some or all of

the characteristics of this core. They reward certain types of behaviors, and punish

others; they create an atmosphere that encourages unplanned participation,

sometimes at the expense of central coordination; they have concepts of rudeness

and politeness that can differ substantially from those prevalent elsewhere. Most

importantly, longtime participants have generally internalized these standards, so that

they share a rough consensus about expected conduct. Unsuccessful projects

usually deviate in significant ways from this core, albeit unintentionally, and often do

not have a consensus about what constitutes reasonable default behavior. This

means that when problems arise, the situation can quickly deteriorate, as the

participants lack an already established stock of cultural reflexes to fall back on for

resolving differences.

This book is a practical guide, not an anthropological study or a history. However, a

working knowledge of the origins of today's free software culture is an essential

foundation for any practical advice. A person who understands the culture can travel

Producing Open Source Software http://producingoss.com/en/producingoss.html

18 of 365 2012年04月08日 20:42

far and wide in the open source world, encountering many local variations in custom

and dialect, yet still be able to participate comfortably and effectively everywhere. In

contrast, a person who does not understand the culture will find the process of

organizing or participating in a project difficult and full of surprises. Since the number

of people developing free software is still growing by leaps and bounds, there are

many people in that latter category—this is largely a culture of recent immigrants, and

will continue to be so for some time. If you think you might be one of them, the next

section provides background for discussions you'll encounter later, both in this book

and on the Internet. (On the other hand, if you've been working with open source for

a while, you may already know a lot of its history, so feel free to skip the next

section.)

History

Software sharing has been around as long as software itself. In the early days of

computers, manufacturers felt that competitive advantages were to be had mainly in

hardware innovation, and therefore didn't pay much attention to software as a

business asset. Many of the customers for these early machines were scientists or

technicians, who were able to modify and extend the software shipped with the

machine themselves. Customers sometimes distributed their patches back not only to

the manufacturer, but to other owners of similar machines. The manufacturers often

tolerated and even encouraged this: in their eyes, improvements to the software, from

whatever source, just made the machine more attractive to other potential customers.

Although this early period resembled today's free software culture in many ways, it

differed in two crucial respects. First, there was as yet little standardization of

hardware—it was a time of flourishing innovation in computer design, but the diversity

of computing architectures meant that everything was incompatible with everything

else. Thus, software written for one machine would generally not work on another.

Programmers tended to acquire expertise in a particular architecture or family of

architectures (whereas today they would be more likely to acquire expertise in a

programming language or family of languages, confident that their expertise will be

transferable to whatever computing hardware they happen to find themselves

Producing Open Source Software http://producingoss.com/en/producingoss.html

19 of 365 2012年04月08日 20:42

working with). Because a person's expertise tended to be specific to one kind of

computer, their accumulation of expertise had the effect of making that computer

more attractive to them and their colleagues. It was therefore in the manufacturer's

interests for machine-specific code and knowledge to spread as widely as possible.

Second, there was no Internet. Though there were fewer legal restrictions on sharing

than today, there were more technical ones: the means of getting data from place to

place were inconvenient and cumbersome, relatively speaking. There were some

small, local networks, good for sharing information among employees at the same

research lab or company. But there remained barriers to overcome if one wanted to

share with everyone, no matter where they were. These barriers were overcome in

many cases. Sometimes different groups made contact with each other

independently, sending disks or tapes through land mail, and sometimes the

manufacturers themselves served as central clearing houses for patches. It also

helped that many of the early computer developers worked at universities, where

publishing one's knowledge was expected. But the physical realities of data

transmission meant there was always an impedance to sharing, an impedance

proportional to the distance (real or organizational) that the software had to travel.

Widespread, frictionless sharing, as we know it today, was not possible.

The Rise of Proprietary Software and Free Software

As the industry matured, several interrelated changes occurred simultaneously. The

wild diversity of hardware designs gradually gave way to a few clear winners

—winners through superior technology, superior marketing, or some combination of

the two. At the same time, and not entirely coincidentally, the development of

so-called "high level" programming languages meant that one could write a program

once, in one language, and have it automatically translated ("compiled") to run on

different kinds of computers. The implications of this were not lost on the hardware

manufacturers: a customer could now undertake a major software engineering effort

without necessarily locking themselves into one particular computer architecture.

When this was combined with the gradual narrowing of performance differences

between various computers, as the less efficient designs were weeded out, a

Producing Open Source Software http://producingoss.com/en/producingoss.html

20 of 365 2012年04月08日 20:42

剩余364页未读，继续阅读

youqika

粉丝: 20
资源: 32

开源软件开发实践：如何运营成功的自由软件项目

Producing_Open_Source_Software_2nd_Edition(中文).epub

Producing Open Source Software

What are the most significant differences among structured, object-oriented, and agile methods? What do they have in common?

用英文回答：在制造型企业里，软件研发部门和产品部门交互流程？

ValueError: object __array__ method not producing an array

do you know the source of 'blueprint'

请用英文写出跟软件需求规格说明书同一题目的完整的软件测试规格说明书

reproducing kernel hilbert spaces in probability and statistics

object __array__ method not producing an array

请基于python3.10或以上的版本回答，queue模块的full()函数的作用？以列表形式写出语法？以列表形式写出所有必传参数及所有可选参数？以列表形式写出返回值？一个简单的案例并在案例的代码中加注释？

最新资源

ValueError: object array method not producing an array

object array method not producing an array