开源软件项目管理指南

需积分: 9 30 浏览量更新于2024-07-21 收藏 830KB PDF 举报

" Producing Open Source Software - Karl Fogel 的著作，探讨如何成功运作开源软件项目，涵盖了项目管理、社区建设、版权与专利、沟通机制等多个方面。" 本书《Producing Open Source Software》深入浅出地阐述了如何运营一个成功的开源软件项目。作者Karl Fogel基于自己的经验和对开源领域的理解，提供了关于项目启动、维护和发展的一系列实用建议。 1. **开源项目的历史和现状**：书中首先介绍了软件发展的历史，从专有软件到自由软件的转变，以及“开源”与“自由”的概念差异。它探讨了当前开源软件在行业中的地位和影响。 2. **项目启动**：开始一个开源项目时，需要考虑现有资源，选择一个有意义的项目名称，并明确项目使命。此外，列出项目特性、需求和开发状态，提供下载链接、版本控制和错误跟踪系统，建立有效的沟通渠道和开发者指南，以及早期的文档和示例，都是项目启动的关键步骤。 3. **选择合适的许可证**：开源项目的许可证选择对于其法律地位和社区参与度至关重要。书中有详细的指导，帮助读者理解和应用不同的开源许可证。 4. **社区建设**：成功的开源项目需要一个活跃的社区。书中讨论了如何吸引并管理志愿者，处理贡献者的贡献，以及如何建立一个健康的项目文化。 5. **项目资金运作**：开源项目通常依赖于捐赠、赞助或服务收入。书中讲述了如何筹集资金，维持项目运营，并确保财务透明。 6. **版权和专利**：开源项目需要处理复杂的版权和专利问题。作者解释了如何处理这些法律问题，保护项目免受潜在的法律纠纷。 7. **沟通问题**：有效的沟通是保持项目健康和活力的核心。书中有章节专门讨论如何通过邮件列表、论坛、会议和其他工具来促进项目内部和外部的沟通。 8. **软件发布和打包**：软件的发布和打包过程也是开源项目的重要环节。作者提供了关于版本控制、测试和构建的建议，确保软件的质量和兼容性。 9. **免责声明**：在开源项目中，理解和遵循免责声明的重要性不言而喻，以免因软件问题导致的法律责任。《Producing Open Source Software》不仅对想要发起开源项目的个人或组织提供了全面的指导，也对已经在运行开源项目的人们提供了宝贵的经验分享，有助于他们在开源世界中取得更大的成功。

Introduction

operating system and body of application software, in which users would never be prevented from

hacking or from sharing their modifications. He was, in essence, setting out to recreate what had been

destroyed at the AI Lab, but on a world-wide scale and without the vulnerabilities that had made the AI

Lab's culture susceptible to disintegration.

In addition to working on the new operating system, Stallman devised a copyright license whose terms

guaranteed that his code would be perpetually free. The GNU General Public License (GPL) is a clever

piece of legal judo: it says that the code may be copied and modified without restriction, and that both

copies and derivative works (i.e., modified versions) must be distributed under the same license as the

original, with no additional restrictions. In effect, it uses copyright law to achieve an effect opposite

to that of traditional copyright: instead of limiting the software's distribution, it prevents anyone, even

the author, from limiting it. For Stallman, this was better than simply putting his code into the public

domain. If it were in the public domain, any particular copy of it could be incorporated into a proprietary

program (as has also been known to happen to code under permissive copyright licenses). While such

incorporation wouldn't in any way diminish the original code's continued availability, it would have

meant that Stallman's efforts could benefit the enemy—proprietary software. The GPL can be thought

of as a form of protectionism for free software, because it prevents non-free software from taking full

advantage of GPLed code. The GPL and its relationship to other free software licenses are discussed in

detail in Chapter 9, Licenses, Copyrights, and Patents.

With the help of many programmers, some of whom shared Stallman's ideology and some of whom

simply wanted to see a lot of free code available, the GNU Project began releasing free replacements

for many of the most critical components of an operating system. Because of the now-widespread

standardization in computer hardware and software, it was possible to use the GNU replacements on

otherwise non-free systems, and many people did. The GNU text editor (Emacs) and C compiler (GCC)

were particularly successful, gaining large and loyal followings not on ideological grounds, but simply

on their technical merits. By about 1990, GNU had produced most of a free operating system, except for

the kernel—the part that the machine actually boots up, and that is responsible for managing memory,

disk, and other system resources.

Unfortunately, the GNU project had chosen a kernel design that turned out to be harder to implement

than expected. The ensuing delay prevented the Free Software Foundation from making the first release

of an entirely free operating system. The final piece was put into place instead by Linus Torvalds, a

Finnish computer science student who, with the help of volunteers around the world, had completed a

free kernel using a more conservative design. He named it Linux, and when it was combined with the

existing GNU programs, the result was a completely free operating system. For the first time, you could

boot up your computer and do work without using any proprietary software.

Much of the software on this new operating system was not produced by the GNU project. In fact, GNU

wasn't even the only group working on producing a free operating system (for example, the code that

eventually became NetBSD and FreeBSD was already under development by this time). The importance

of the Free Software Foundation was not only in the code they wrote, but in their political rhetoric. By

talking about free software as a cause instead of a convenience, they made it difficult for programmers

not to have a political consciousness about it. Even those who disagreed with the FSF had to engage

the issue, if only to stake out a different position. The FSF's effectiveness as propagandists lay in tying

their code to a message, by means of the GPL and other texts. As their code spread widely, that message

spread as well.

Accidental resistance

There were many other things going on in the nascent free software scene, however, and few were as

explictly ideological as Stallman's GNU Project. One of the most important was the Berkeley Software

Technically, Linux was not the first. A free operating system for IBM-compatible computers, called 386BSD, had come out

shortly before Linux. However, it was a lot harder to get 386BSD up and running. Linux made such a splash not only because it

was free, but because it actually had a high chance of booting your computer when you installed it.

Introduction

Distribution (BSD), a gradual re-implementation of the Unix operating system—which up until the late

1970's had been a loosely proprietary research project at AT&T—by programmers at the University

of California at Berkeley. The BSD group did not make any overt political statements about the need

for programmers to band together and share with one another, but they practiced the idea with flair and

enthusiasm, by coordinating a massive distributed development effort in which the Unix command-line

utilities and code libraries, and eventually the operating system kernel itself, were rewritten from scratch

mostly by volunteers. The BSD project became a prime example of non-ideological free software

development, and also served as a training ground for many developers who would go on to remain

active in the open source world.

Another crucible of cooperative development was the X Window System, a free, network-transparent

graphical computing environment, developed at MIT in the mid-1980's in partnership with hardware

vendors who had a common interest in being able to offer their customers a windowing system. Far from

opposing proprietary software, the X license deliberately allowed proprietary extensions on top of the

free core—each member of the consortium wanted the chance to enhance the default X distribution, and

thereby gain a competitive advantage over the other members. X Windows

itself was free software, but

mainly as a way to level the playing field between competing business interests, not out of some desire

to end the dominance of proprietary software. Yet another example, predating the GNU project by a

few years, was TeX, Donald Knuth's free, publishing-quality typesetting system. He released it under a

license that allowed anyone to modify and distribute the code, but not to call the result "TeX" unless it

passed a very strict set of compatibility tests (this is an example of the "trademark-protecting" class of

free licenses, discussed more in Chapter 9, Licenses, Copyrights, and Patents). Knuth wasn't taking a

stand one way or the other on the question of free-versus-proprietary software, he just needed a better

typesetting system in order to complete his real goal—a book on computer programming—and saw no

reason not to release his system to the world when done.

Without listing every project and every license, it's safe to say that by the late 1980's, there was a

lot of free software available under a wide variety of licenses. The diversity of licenses reflected a

corresponding diversity of motivations. Even some of the programmers who chose the GNU GPL were

much less ideologically driven than the GNU project itself. Although they enjoyed working on free

software, many developers did not consider proprietary software a social evil. There were people who

felt a moral impulse to rid the world of "software hoarding" (Stallman's term for non-free software), but

others were motivated more by technical excitement, or by the pleasure of working with like-minded

collaborators, or even by a simple human desire for glory. Yet by and large these disparate motivations

did not interact in destructive ways. This is partly because software, unlike other creative forms like

prose or the visual arts, must pass semi-objective tests in order to be considered successful: it must run,

and be reasonably free of bugs. This gives all participants in a project a kind of automatic common

ground, a reason and a framework for working together without worrying too much about qualifications

beyond the technical.

Developers had another reason to stick together as well: it turned out that the free software world was

producing some very high-quality code. In some cases, it was demonstrably technically superior to

the nearest non-free alternative; in others, it was at least comparable, and of course it always cost less.

While only a few people might have been motivated to run free software on strictly philosophical

grounds, a great many people were happy to run it because it did a better job. And of those who used it,

some percentage were always willing to donate their time and skills to help maintain and improve the

software.

This tendency to produce good code was certainly not universal, but it was happening with increasing

frequency in free software projects around the world. Businesses that depended heavily on software

gradually began to take notice. Many of them discovered that they were already using free software in

day-to-day operations, and simply hadn't known it (upper management isn't always aware of everything

the IT department does). Corporations began to take a more active and public role in free software

They prefer it to be called the "X Window System", but in practice, people usually call it "X Windows", because three words is

just too cumbersome.

Introduction

projects, contributing time and equipment, and sometimes even directly funding the development of

free programs. Such investments could, in the best scenarios, repay themselves many times over. The

sponsor only pays a small number of expert programmers to devote themselves to the project full time,

but reaps the benefits of everyone's contributions, including work from unpaid volunteers and from

programmers being paid by other corporations.

"Free" Versus "Open Source"

As the corporate world gave more and more attention to free software, programmers were faced with

new issues of presentation. One was the word "free" itself. On first hearing the term "free software"

many people mistakenly think it means just "zero-cost software." It's true that all free software is zero-

cost,

but not all zero-cost software is free. For example, during the battle of the browsers in the 1990s,

both Netscape and Microsoft gave away their competing web browsers at no charge, in a scramble to

gain market share. Neither browser was free in the "free software" sense. You couldn't get the source

code, and even if you could, you didn't have the right to modify or redistribute it.

The only thing you

could do was download an executable and run it. The browsers were no more free than shrink-wrapped

software bought in a store; they merely had a lower price.

This confusion over the word "free" is due entirely to an unfortunate ambiguity in the English language.

Most other tongues distinguish low prices from liberty (the distinction between gratis and libre is

immediately clear to speakers of Romance languages, for example). But English's position as the

de facto bridge language of the Internet means that a problem with English is, to some degree, a

problem for everyone. The misunderstanding around the word "free" was so prevalent that free software

programmers eventually evolved a standard formula in response: "It's free as in freedom—think free

speech, not free beer." Still, having to explain it over and over is tiring. Many programmers felt, with

some justification, that the ambiguous word "free" was hampering the public's understanding of this

software.

But the problem went deeper than that. The word "free" carried with it an inescapable moral

connotation: if freedom was an end in itself, it didn't matter whether free software also happened to be

better, or more profitable for certain businesses in certain circumstances. Those were merely pleasant

side effects of a motive that was, at bottom, neither technical nor mercantile, but moral. Furthermore,

the "free as in freedom" position forced a glaring inconsistency on corporations who wanted to support

particular free programs in one aspect of their business, but continue marketing proprietary software in

others.

These dilemmas came to a community that was already poised for an identity crisis. The programmers

who actually write free software have never been of one mind about the overall goal, if any, of the free

software movement. Even to say that opinions run from one extreme to the other would be misleading,

in that it would falsely imply a linear range where there is instead a multidimensional scattering.

However, two broad categories of belief can be distinguished, if we are willing to ignore subtleties

for the moment. One group takes Stallman's view, that the freedom to share and modify is the most

important thing, and that therefore if you stop talking about freedom, you've left out the core issue.

Others feel that the software itself is the most important argument in its favor, and are uncomfortable

with proclaiming proprietary software inherently bad. Some, but not all, free software programmers

believe that the author (or employer, in the case of paid work) should have the right to control the terms

of distribution, and that no moral judgement need be attached to the choice of particular terms.

For a long time, these differences did not need to be carefully examined or articulated, but free

software's burgeoning success in the business world made the issue unavoidable. In 1998, the term

open source was created as an alternative to "free", by a coalition of programmers who eventually

One may charge a fee for giving out copies of free software, but since one cannot stop the recipients from offering it at no charge

afterwards, the price is effectively driven to zero immediately.

The source code to Netscape Navigator was eventually released under an open source license, in 1998, and became the

foundation for the Mozilla web browser. See http://www.mozilla.org/.

Introduction

became The Open Source Initiative (OSI).

The OSI felt not only that "free software" was potentially

confusing, but that the word "free" was just one symptom of a general problem: that the movement

needed a marketing program to pitch it to the corporate world, and that talk of morals and the social

benefits of sharing would never fly in corporate boardrooms. In their own words:

The Open Source Initiative is a marketing program for free software. It's a pitch for

"free software" on solid pragmatic grounds rather than ideological tub-thumping. The

winning substance has not changed, the losing attitude and symbolism have. ...

The case that needs to be made to most techies isn't about the concept of open source,

but the name. Why not call it, as we traditionally have, free software?

One direct reason is that the term "free software" is easily misunderstood in ways that

lead to conflict. ...

But the real reason for the re-labeling is a marketing one. We're trying to pitch our

concept to the corporate world now. We have a winning product, but our positioning,

in the past, has been awful. The term "free software" has been misunderstood by

business persons, who mistake the desire to share with anti-commercialism, or worse,

theft.

Mainstream corporate CEOs and CTOs will never buy "free software." But if we take

the very same tradition, the same people, and the same free-software licenses and

change the label to "open source" ? that, they'll buy.

Some hackers find this hard to believe, but that's because they're techies who think in

concrete, substantial terms and don't understand how important image is when you're

selling something.

In marketing, appearance is reality. The appearance that we're willing to climb down

off the barricades and work with the corporate world counts for as much as the reality

of our behavior, our convictions, and our software.

(from http://www.opensource.org/. Or rather, formerly from that site — the OSI

has apparently taken down the pages since then, although they can still be seen at

http://web.archive.org/web/20021204155057/http://www.opensource.org/advocacy/

faq.php and http://web.archive.org/web/20021204155022/http://www.opensource.org/

advocacy/case_for_hackers.php#marketing.)

The tips of many icebergs of controversy are visible in that text. It refers to "our convictions", but

smartly avoids spelling out exactly what those convictions are. For some, it might be the conviction that

code developed according to an open process will be better code; for others, it might be the conviction

that all information should be shared. There's the use of the word "theft" to refer (presumably) to illegal

copying—a usage that many object to, on the grounds that it's not theft if the original possessor still has

the item afterwards. There's the tantalizing hint that the free software movement might be mistakenly

accused of anti-commercialism, but it leaves carefully unexamined the question of whether such an

accusation would have any basis in fact.

None of which is to say that the OSI's web site is inconsistent or misleading. It's not. Rather, it is an

example of exactly what the OSI claims had been missing from the free software movement: good

marketing, where "good" means "viable in the business world." The Open Source Initiative gave a lot

of people exactly what they had been looking for—a vocabulary for talking about free software as a

development methodology and business strategy, instead of as a moral crusade.

The appearance of the Open Source Initiative changed the landscape of free software. It formalized a

dichotomy that had long been unnamed, and in doing so forced the movement to acknowledge that it had

OSI's web home is http://www.opensource.org/.

Introduction

internal politics as well as external. The effect today is that both sides have had to find common ground,

since most projects include programmers from both camps, as well as participants who don't fit any clear

category. This doesn't mean people never talk about moral motivations—lapses in the traditional "hacker

ethic" are sometimes called out, for example. But it is rare for a free software / open source developer

to openly question the basic motivations of others in a project. The contribution trumps the contributor.

If someone writes good code, you don't ask them whether they do it for moral reasons, or because

their employer paid them to, or because they're building up their resumé, or whatever. You evaluate

the contribution on technical grounds, and respond on technical grounds. Even explicitly political

organizations like the Debian project, whose goal is to offer a 100% free (that is, "free as in freedom")

computing environment, are fairly relaxed about integrating with non-free code and cooperating with

programmers who don't share exactly the same goals.

The Situation Today

When running a free software project, you won't need to talk about such weighty philosophical matters

on a daily basis. Programmers will not insist that everyone else in the project agree with their views

on all things (those who do insist on this quickly find themselves unable to work in any project). But

you do need to be aware that the question of "free" versus "open source" exists, partly to avoid saying

things that might be inimical to some of the participants, and partly because understanding developers'

motivations is the best way—in some sense, the only way—to manage a project.

Free software is a culture by choice. To operate successfully in it, you have to understand why people

choose to be in it in the first place. Coercive techniques don't work. If people are unhappy in one

project, they will just wander off to another one. Free software is remarkable even among volunteer

communities for its lightness of investment. Most of the people involved have never actually met the

other participants face-to-face, and simply donate bits of time whenever they feel like it. The normal

conduits by which humans bond with each other and form lasting groups are narrowed down to a tiny

channel: the written word, carried over electronic wires. Because of this, it can take a long time for

a cohesive and dedicated group to form. Conversely, it's quite easy for a project to lose a potential

volunteer in the first five minutes of acquaintanceship. If a project doesn't make a good first impression,

newcomers rarely give it a second chance.

The transience, or rather the potential transience, of relationships is perhaps the single most daunting

task facing a new project. What will persuade all these people to stick together long enough to produce

something useful? The answer to that question is complex enough to occupy the rest of this book, but if

it had to be expressed in one sentence, it would be this:

People should feel that their connection to a project, and influence over it, is directly

proportional to their contributions.

No class of developers, or potential developers, should ever feel discounted or discriminated against

for non-technical reasons. Clearly, projects with corporate sponsorship and/or salaried developers need

to be especially careful in this regard, as Chapter 5, Money discusses in detail. Of course, this doesn't

mean that if there's no corporate sponsorship then you have nothing to worry about. Money is merely

one of many factors that can affect the success of a project. There are also questions of what language to

choose, what license, what development process, precisely what kind of infrastructure to set up, how to

publicize the project's inception effectively, and much more. Starting a project out on the right foot is the

topic of the next chapter.

剩余199页未读，继续阅读

so_boring

粉丝: 1
资源: 2

开源软件项目管理指南

open source back software

Producing_Open_Source_Software_2nd_Edition(中文).epub

producing open source software

生产开源软件：如何运行成功的免费软件项目Producing Open Source Software: How to Run a Successful Free Software Project

Producing-Open-Source-Software-2nd-Edition

Producing_Open_Source_Softwa.zip_Free!

Graugon AntiVirus OpenSource,delphi

ProducingOpenSourceSoftwareHow to Run a Successful Free Software

How to Run a Successful Free Software Project

(源码)基于Spring Boot和JWT的饮品管理系统.zip

最新资源