mirror of
https://github.com/LCTT/TranslateProject.git
synced 2024-12-26 21:30:55 +08:00
108 lines
6.9 KiB
Markdown
108 lines
6.9 KiB
Markdown
如何开始一个开源项目
|
||
================================================================================
|
||
> 循序渐进的指导
|
||
|
||
**你有这个问题**：你已经权衡了[开源代码的优劣势][1]，你也已经知道[你的软件需要成为一个开源项目][2]，但是，你不知道怎么做好的开源项目。
|
||
|
||
当然，你也许已经知道[如何创建Github帐号并开始][3]，但是这些事实上是做开源比较简单的部分。而真真正正难的部分是如何让足够多的人，关注你的项目并给你的项目做贡献。
|
||
|
||
|
||
|
||
接下来的原则是会指导你构建和发布其他人愿意关注的代码。
|
||
|
||
### 基本原则 ###
|
||
|
||
选择开源可能有许多原因。也许你希望吸引一个社区来帮助编写你的代码。也许，[总所周知][4]，你明白“开源 —— 一个开发小团队内部编写代码的倍增器。”
|
||
|
||
或者你只是认为这是必须做的事，[如同英国政府一样][5]。
|
||
|
||
无论何种原因，为了开源能够成功，是必须要做很多的计划去给将来使用这个软件的人们。如同[我在2005写道][6]，如果你“需要大量的人做贡献（bug修复，扩展等等）”，那么你需要“写一个好的文档，使用易于接受的编程语言，和使用模型架构”。
|
||
|
||
对了，你也需要写人们在乎的软件。
|
||
|
||
每天思考你依靠的技术：操作系统，web应用框架，数据库，等等。远离像航天这样，特殊行业的小生态技术，让开源拥有更多的可能性以便外部的（人的）产生兴趣和做出贡献。更广泛的应用技术，找到更多的贡献者和用户。
|
||
|
||
总的来说，任何成功的开源项目有以下共同点：
|
||
|
||
1.最佳的时间时机（解决市场实际需求）
|
||
|
||
2.一个健壮，包括开发者和非开发者的团队
|
||
|
||
3.一个易于参与的结构（更多详见下文）
|
||
|
||
4.模块化编码，使新贡献者更容易找到一个项目损坏的部分去贡献，比强迫他们理解巨大的代码的每一部分要好
|
||
|
||
5.代码可以广泛应用（或者达到一个狭窄的流行都比一个“自生自灭的”小生态更吸引人）
|
||
|
||
6.很好初始源码（如果你放垃圾在Github，你也只会得到垃圾回报）
|
||
|
||
7.一个自由的许可证-我[个人更爱Apache型的许可证][7]，因为它让开发者采用时障碍最低，当然许多成功的项目（如Linux和MySQL）使用GPL许可证也有很棒的效果。
|
||
|
||
上述几项，是一个项目成功邀请参与者最难的部分。这是因为他们不是关于代码而是关于人。
|
||
|
||
### 开源不单是一个许可证 ###
|
||
|
||
今年，最棒的一件事是我读到是来自 Vitorio Miliano ([@vitor_io][8])的文章，他是用户体验交互设计师，来自德州的奥斯丁。[Miliano][9]指出，那些不在你的项目上工作的人才是“外行”，从本质上说无论他们技术能力的级别，他们仅仅懂一点代码（也没关系）。
|
||
|
||
所以你的工作，他认为，是使人加入，为你贡献你的代码变得简单。当阐述如何涉及非程序员到开源项目中，他指出项目的一些事项，项目领导应需要有效地得加入一些任何技术或不懂技术的人到开源项目。
|
||
|
||
> 1. 一种方法去了解你的项目价值
|
||
>
|
||
> 2. 一种方法去了解他们可以为项目提供的价值
|
||
>
|
||
> 3. 一种方法去了解他们可以从贡献代码获得的价值
|
||
>
|
||
> 4. 一种方法去了解贡献流程，端到端
|
||
>
|
||
> 5. 贡献机制适用于现有的工作流
|
||
|
||
经常，项目领导者想要集中于上述的第五步，却不提供理解1到4的路径。如果潜在的贡献者不欣赏“为什么”，“如何”共享就变得不重要了。
|
||
|
||
注意，至关重要的，Miliano写道，建立拥有一个通俗易懂的简介的项目很有价值，如同任何时候通过简介给每一个人演示可访问性和包容性。他断言道，这增加了额外的好处，文档和其他的版本介绍的内容变得通俗易懂。
|
||
|
||
关于第二点，程序员或非程序员同样地需要能够明白到底你需要什么，这样他们就可以认识到他们的贡献（方向）。有时就像MongoDB解决方案架构师[Henrik Ingo告诉我][10]那样，"一个聪明的人可以贡献很棒的代码，但是项目成员不能理解它（代码）"，如果在组织内承认这个贡献并且研究后理解，那么这就不是一个糟糕的问题。
|
||
|
||
但是不会经常发生。
|
||
|
||
### 你真的想领导一个开源项目吗？ ###
|
||
|
||
许多开源项目的领导提倡包容性，但是他们拥有任何事除了包容。如果你不想要人们做贡献，不要假装开源。
|
||
|
||
是的，有时这是老生常谈的话题。就像HackerNews最近的报道[一个开发者的开发工作][11]。
|
||
|
||
> 小项目可以得到很多，基本不需要很多人合作来完成。我看到了他们的进步，但是我没有看到我自己的进步:如果我帮助了他们，显然，如果我花费了有限的时间在与那些计算机科学的硕士管理合作上，而没有参与编码，这不是我想要的。所以我忽略了他们。
|
||
|
||
这是一个保持理智的的好方法，但这个态度并不能预示着这个项目会被广阔的分享。
|
||
|
||
如果你确实很少关心非程序员设计的贡献、文档，或者无论其他什么，那么请首先了解那些。再次强调，如果这是实情，你的项目就不能成为一个开源项目。
|
||
|
||
当然，排除感觉不总是可靠的。 就像ActiveState的副总裁Bernard Golden告诉过我，“一些将会成为开发人员将会对现有的“小集团”开发团体这种感觉感到恐惧，虽然这不一定正确。”
|
||
|
||
现在，若使了解开发人员为什么要贡献并邀请做开发，意味着更多的开源项目投资，更长久地生存。
|
||
|
||
图片由[Shutterstock][12]提供
|
||
|
||
--------------------------------------------------------------------------------
|
||
|
||
via: http://readwrite.com/2014/08/20/open-source-project-how-to
|
||
|
||
作者：[Matt Asay][a]
|
||
译者：[Vic___/VicYu](http://www.vicyu.net)
|
||
校对：[wxy](https://github.com/wxy)
|
||
|
||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](http://linux.cn/) 荣誉推出
|
||
|
||
[a]:http://readwrite.com/author/matt-asay
|
||
[1]:http://readwrite.com/2014/07/07/open-source-software-pros-cons
|
||
[2]:http://readwrite.com/2014/08/15/open-source-software-business-zulily-erp-wall-street-journal
|
||
[3]:http://www.cocoanetics.com/2011/01/starting-an-opensource-project-on-github/
|
||
[4]:http://werd.io/2014/the-roi-of-building-open-source-software
|
||
[5]:https://www.gov.uk/design-principles
|
||
[6]:http://asay.blogspot.com/2005/09/so-you-want-to-build-open-source.html
|
||
[7]:http://www.cnet.com/news/apache-better-than-gpl-for-open-source-business/
|
||
[8]:https://twitter.com/vitor_io
|
||
[9]:http://opensourcedesign.is/blogging_about/import-designers/
|
||
[10]:https://twitter.com/h_ingo/status/501323333301190656
|
||
[11]:https://news.ycombinator.com/item?id=8122814
|
||
[12]:http://www.shutterstock.com/
|