mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-02-03 23:40:14 +08:00
commit
5da3fdf1b8
@ -1,109 +0,0 @@
|
||||
Vic020
|
||||
|
||||
Want To Start An Open Source Project? Here's How
|
||||
================================================================================
|
||||
> Our step-by-step guide.
|
||||
|
||||
**You have a problem. You've weighed the** [pros and cons of open sourcing your code][1], and you know [you need to start an open-source project][2] for your software. But you have no idea how to do this.
|
||||
|
||||
Oh, sure. You may know how to set up a GitHub account and get started, but such [mechanics][3] are actually the easy part of open source. The hard part is making anyone care enough to use or contribute to your project.
|
||||
|
||||
![](http://a4.files.readwrite.com/image/upload/c_fit,q_80,w_630/MTE5NDg0MDYxMTg2Mjk1MzEx.jpg)
|
||||
|
||||
Here are some principles to guide you in building and releasing code that others will care about.
|
||||
|
||||
### First, The Basics ###
|
||||
|
||||
You may choose to open source code for a variety of reasons. Perhaps you're looking to engage a community to help write your code. Perhaps, [like Known][4], you see "open source distribution ... as a multiplier for the small teams of developers writing the code in-house."
|
||||
|
||||
Or maybe you just think it's the right thing to do, [as the UK government believes][5].
|
||||
|
||||
Regardless of the reason, this isn't about you. Not really. For open source to succeed, much of the planning has to be about those who will use the software. As [I wrote in 2005][6], if you "want lots of people to contribute (bug fixes, extensions, etc.," then you need to "write good documentation, use an accessible programming language ... [and] have a modular framework."
|
||||
|
||||
Oh, and you also need to be writing software that people care about.
|
||||
|
||||
Think about the technology you depend on every day: operating systems, web application frameworks, databases, and so on. These are far more likely to generate outside interest and contributions than a niche technology for a particular industry like aviation. The broader the application of the technology, the more likely you are to find willing contributors and/or users.
|
||||
|
||||
In summary, any successful open-source project needs these things:
|
||||
|
||||
1. Optimal market timing (solving a real need in the market);
|
||||
|
||||
2. A strong, inclusive team of developers and non-developers;
|
||||
|
||||
3. An architecture of participation (more on that below);
|
||||
|
||||
4. Modular code to make it easier for new contributors to find a discrete chunk of the program to work on, rather than forcing them to scale an Everest of monolithic code;
|
||||
|
||||
5. Code that is broadly applicable (or a way to reach the narrower population more niche-y code appeals to);
|
||||
|
||||
6. Great initial source code (if you put garbage into GitHub, you'll get garbage out);
|
||||
|
||||
7. A permissive license—I [personally prefer Apache-style licensing][7] as it introduces the lowest barriers to developer adoption, but many successful projects (like Linux and MySQL) have used GPL licensing to great effect.
|
||||
|
||||
Of the items above, it's sometimes hardest for projects to actively invite participation. That's usually because this is less about code and more about people.
|
||||
|
||||
### "Open" Is More Than A License ###
|
||||
|
||||
One of the best things I've read in years on this subject comes from Vitorio Miliano ([@vitor_io][8]), a user experience and interaction designer from Austin, Texas. [Miliano points out][9] that anyone who doesn't already work on your project is a "layperson," in the sense that no matter their level of technical competence, they know little about your code.
|
||||
|
||||
So your job, he argues, is to make it easy to get involved in contributing to your code base. While he focuses on how to involve non-programmers in open-source projects, he identifies a few things project leads need to do to effectively involve anyone—technical or non-technical—in open source:
|
||||
|
||||
> 1. a way to understand the value of your project
|
||||
>
|
||||
> 2. a way to understand the value they could provide to the project
|
||||
>
|
||||
> 3. a way to understand the value they could receive from contributing to the project
|
||||
>
|
||||
> 4. a way to understand the contribution process, end-to-end
|
||||
>
|
||||
> 5. a contribution mechanism suitable for their existing workflows
|
||||
|
||||
Too often, project leads want to focus on the fifth step without providing an easy path to understand items 1 through 4. "How" to contribute doesn't matter very much if would-be contributors don't appreciate the "why."
|
||||
|
||||
On that note, it's critical, Miliano writes, to establish the value of the project with a "jargon-free description" so as to "demonstrate your accessibility and inclusiveness by writing your descriptions to be useful to everyone at all times." This has the added benefit, he avers, of signaling that documentation and other code-related content will be similarly clear.
|
||||
|
||||
On the second item, programmers and non-programmers alike need to be able to see exactly what you'd like from them, and then they need to be recognized for their contributions. Sometimes, as MongoDB solution architect [Henrik Ingo told me][10], "A smart person [may] come[] by with great code, but project members fail to understand it." That's not a terrible problem if the "in" group acknowledges the contribution and reaches out to understand.
|
||||
|
||||
But that doesn't always happen.
|
||||
|
||||
### Do You Really Want To Lead An Open Source Project? ###
|
||||
|
||||
Too many open-source project leads advertise inclusiveness but then are anything but inclusive. If you don't want people contributing code, don't pretend to be open source.
|
||||
|
||||
Yes, this is sometimes a function of newbie fatigue. As [one developer wrote][11] recently on HackerNews,
|
||||
|
||||
> Small projects get lots of, well, basically useless people who need tons of handholding to get anything accomplished. I see the upside for them, but I don't see the upside for me: if I where[sic] to help them out, I'd spend my limited available time on handholding people who apparently managed to get ms degrees in cs without being able to code instead of doing what I enjoy. So I ignore them.
|
||||
|
||||
While that may be a good way to maintain sanity, the attitude doesn't bode well for a project if it's widely shared.
|
||||
|
||||
And if you really couldn't care less about non-programmers contributing design input, or documentation, or whatever, then make that clear. Again, if this is the case, you really shouldn't be an open-source project.
|
||||
|
||||
Of course, the perception of exclusion is not always reality. As ActiveState vice president Bernard Golden told me over IM, "many would-be developers are intimidated by the perception of an existing 'in-crowd' dev group, even though it may not really be true."
|
||||
|
||||
Still, the more open source projects invest in making it easy to understand why developers should contribute, and make it inviting to do so, the how largely takes care of itself.
|
||||
|
||||
Lead image courtesy of [Shutterstock][12]
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: http://readwrite.com/2014/08/20/open-source-project-how-to
|
||||
|
||||
作者:[Matt Asay][a]
|
||||
译者:[译者ID](https://github.com/译者ID)
|
||||
校对:[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [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/
|
@ -0,0 +1,149 @@
|
||||
How to monitor and troubleshoot a Linux server using sysdig
|
||||
================================================================================
|
||||
What is the first thing that comes to mind when you need to track system calls made and received by a process? You'll probably think of strace, and you are right. What tool would you use to monitor raw network traffic from the command line? If you thought about tcpdump, you made an excellent choice again. And if you ever run into the need to having to keep track of open files (in the Unix sense of the word: everything is a file), chances are you'll use lsof.
|
||||
|
||||
strace, tcpdump, and lsof are indeed great utilities that should be part of every sysadmin's toolset, and that is precisely the reason why you will love [sysdig][1], a powerful open source tool for system-level exploration and troubleshooting, introduced by its creators as "strace + tcpdump + lsof + awesome sauce with a little Lua cherry on top." Humor aside, one of the great features of sysdig resides in its ability not only to analyze the "live" state of a Linux system, but also to save the state in a dump file for offline inspection. What's more, you can customize sysdig's behavior or even enhance its capabilities by using built-in (or writing your own) small scripts called chisels. Individual chisels are used to analyze sysdig-captured event streams in various script-specific fashions.
|
||||
|
||||
In this tutorial we'll explore the installation and basic usage of sysdig to perform system monitoring and troubleshooting on Linux.
|
||||
|
||||
### Installing Sysdig ###
|
||||
|
||||
For this tutorial, we will choose to use the automatic installation process described in the official website for the sake of simplicity, brevity, and distribution agnosticity. In the automatic process, the installation script automatically detects the operating system and installs all the necessary dependencies.
|
||||
|
||||
Run the following command as root to install sysdig from the official apt/yum repository:
|
||||
|
||||
# curl -s https://s3.amazonaws.com/download.draios.com/stable/install-sysdig | bash
|
||||
|
||||
![](https://farm6.staticflickr.com/5616/15334678580_99c5d38328_z.jpg)
|
||||
|
||||
Once the installation is complete, we can invoke sysdig as follows to get a feel for it:
|
||||
|
||||
# sysdig
|
||||
|
||||
Our screen will be immediately filled with all that is going on in our system, not allowing us to do much more with that information. For that reason, we will run:
|
||||
|
||||
# sysdig -cl | less
|
||||
|
||||
to see a list of available chisels.
|
||||
|
||||
![](https://farm4.staticflickr.com/3938/15334678610_e5956a26e8_z.jpg)
|
||||
|
||||
The following categories are available by default, each of which is populated by multiple built-in chisels.
|
||||
|
||||
- CPU Usage
|
||||
- Errors
|
||||
- I/O
|
||||
- Logs
|
||||
- Misc
|
||||
- Net
|
||||
- Performance
|
||||
- Security
|
||||
- System State
|
||||
|
||||
To display information (including detailed command-line usage) on a particular chisel, run:
|
||||
|
||||
# sysdig -cl [chisel_name]
|
||||
|
||||
For example, we can check information about spy_port chisel under "Net" category by running:
|
||||
|
||||
# sysdig -i spy_port
|
||||
|
||||
![](https://farm4.staticflickr.com/3945/15521424095_0365bf20c3_z.jpg)
|
||||
|
||||
Chisels can be combined with filters (which can be applied to both live data or a trace file) to obtain more useful output.
|
||||
|
||||
Filters follow a "class.field" structure. For example:
|
||||
|
||||
- **fd.cip**: client IP address.
|
||||
- **evt.dir**: event direction can be either '>' for enter events or '<' for exit events.
|
||||
|
||||
The complete filter list can be displayed with:
|
||||
|
||||
# sysdig -l
|
||||
|
||||
In the rest of the tutorial, I will demonstrate several use cases of sysdig.
|
||||
|
||||
### Sysdig Example: Troubleshooting Server Performance ###
|
||||
|
||||
Suppose your server is experiencing performance issues (e.g., unresponsiveness or significant delays in responding). You can use the bottlenecks chisel to display a list of the 10 slowest systems calls at the moment.
|
||||
|
||||
Use the following command to check up on a live server in real time. The "-c" flag followed by a chisel name tells sysdig to run the specified chisel.
|
||||
|
||||
# sysdig -c bottlenecks
|
||||
|
||||
Alternatively, you can conduct a server performance analysis offline. In that case, you can save a complete sysdig trace to a file, and run the bottlenecks chisel against the trace as follows.
|
||||
|
||||
First, save a sysdig trace (use Ctrl+c to stop the collection):
|
||||
|
||||
# sysdig -w trace.scap
|
||||
|
||||
Once the trace is collected, you can check the slowest systems calls that were performed during the capture interval by running:
|
||||
|
||||
# sysdig -r trace.scap -c bottlenecks
|
||||
|
||||
![](https://farm6.staticflickr.com/5611/15334678670_ebbe93265e_z.jpg)
|
||||
|
||||
You want to pay attention fo columns #2, #3, and #4, which indicate execution time, process name, and PID, respectively.
|
||||
|
||||
### Sysdig Example: Monitoring Interactive User Activities ###
|
||||
|
||||
Suppose you as a sysadmin want to monitor interactive user activities in a system (e.g., what command a user typed from the command line, and what directories the user went to). That is when spy_user chisel comes in handy.
|
||||
|
||||
Let's first collect a sysdig trace with a couple of extra options.
|
||||
|
||||
# sysdig -s 4096 -z -w /mnt/sysdig/$(hostname).scap.gz
|
||||
|
||||
- "-s 4096" tells sysdig to capture up to 4096 bytes of each event.
|
||||
- "-z" (used with "-w") enables compression for a trace file.
|
||||
- "-w <trace-file>" saves sysdig traces to a specified file.
|
||||
|
||||
In the above, we customize the name of the compressed trace file on a per-host basis. Remember that you can interrupt the execution of sysdig at any moment by pressing Ctrl + c.
|
||||
|
||||
Once we've collected a reasonable amount of data, we can view interactive activities of every user in a system by running:
|
||||
|
||||
# sysdig -r /mnt/sysdig/debian.scap.gz -c spy_users
|
||||
|
||||
![](https://farm4.staticflickr.com/3932/15518254291_5c9671ca41_z.jpg)
|
||||
|
||||
The first column in the above output indicates the PID of the process associated with a given user's activity.
|
||||
|
||||
What if you want to target a specific user, and monitor the user's activities only? You can filter the results of the spy_users chisel by username:
|
||||
|
||||
# sysdig -r /mnt/sysdig/debian.scap.gz -c spy_users "user.name=xmodulo"
|
||||
|
||||
![](https://farm4.staticflickr.com/3944/15498248556_66d15422b1_z.jpg)
|
||||
|
||||
### Sysdig Example: Monitoring File I/O ###
|
||||
|
||||
We can customize the output format of sysdig traces with "-p" flag, and indicate desired fields (e.g., user name, process name, and file or socket name) enclosed inside double quotes. In this example, we will create a trace file that will only contain writing events in home directories (which we can inspect later with "sysdig -r writetrace.scap.gz").
|
||||
|
||||
# sysdig -p "%user.name %proc.name %fd.name" "evt.type=write and fd.name contains /home/" -z -w writetrace.scap.gz
|
||||
|
||||
![](https://farm6.staticflickr.com/5610/15498248586_de5f5fc93d_z.jpg)
|
||||
|
||||
### Sysdig Example: Monitoring Network I/O ###
|
||||
|
||||
As part of server troubleshooting, you may want to snoop on network traffic, which is typically done with tcpdump. With sysdig, traffic sniffing can be done as easily, but in more user friendly fashions.
|
||||
|
||||
For example, you can inspect data (in ASCII) that has been exchanged with a particular IP address, served by a particular process (e.g., apache2):
|
||||
|
||||
# sysdig -s 4096 -A -c echo_fds fd.cip=192.168.0.100 -r /mnt/sysdig/debian.scap.gz proc.name=apache2
|
||||
|
||||
If you want to monitor raw data transfer (in binary) instead, replace "-A" with "-X":
|
||||
|
||||
# sysdig -s 4096 -X -c echo_fds fd.cip=192.168.0.100 -r /mnt/sysdig/debian.scap.gz proc.name=apache2
|
||||
|
||||
For more information, examples, and case studies, you can check out the [project website][1]. Believe me, the possibilities are limitless. But don't just take my word for it. Install sysdig and start digging today!
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: http://xmodulo.com/monitor-troubleshoot-linux-server-sysdig.html
|
||||
|
||||
作者:[Gabriel Cánepa][a]
|
||||
译者:[译者ID](https://github.com/译者ID)
|
||||
校对:[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译,[Linux中国](http://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:http://xmodulo.com/author/gabriel
|
||||
[1]:http://www.sysdig.org/
|
@ -1,3 +1,5 @@
|
||||
wangjiezhe translating...
|
||||
|
||||
Linux FAQs with Answers--How to change date and time from the command line on Linux
|
||||
================================================================================
|
||||
> **Question**: In Linux, how can I change date and time from the command line?
|
||||
@ -75,10 +77,10 @@ As opposed to one-time clock sync using ntpdate, you can also set up NTP daemon
|
||||
via: http://ask.xmodulo.com/change-date-time-command-line-linux.html
|
||||
|
||||
译者:[译者ID](https://github.com/译者ID)
|
||||
校对:[校对者ID](https://github.com/校对者ID)
|
||||
校对:[wangjiezhe](https://github.com/wangjiezhe)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译,[Linux中国](http://linux.cn/) 荣誉推出
|
||||
|
||||
[1]:http://ask.xmodulo.com/change-timezone-linux.html
|
||||
[2]:http://www.pool.ntp.org/
|
||||
[3]:http://xmodulo.com/how-to-synchronize-time-with-ntp.html
|
||||
[3]:http://xmodulo.com/how-to-synchronize-time-with-ntp.html
|
||||
|
@ -1,3 +1,5 @@
|
||||
Vic020
|
||||
|
||||
Linux FAQs with Answers--How to create and mount an XFS file system on Linux
|
||||
================================================================================
|
||||
> **Question**: I heard good things about XFS, and would like to create an XFS file system on my disk partition. What are the Linux commands to format and mount an XFS file system?
|
||||
@ -65,4 +67,4 @@ via: http://ask.xmodulo.com/create-mount-xfs-file-system-linux.html
|
||||
|
||||
[1]:http://xfs.org/
|
||||
[2]:http://lwn.net/Articles/476263/
|
||||
[3]:http://ask.xmodulo.com/expand-xfs-file-system.html
|
||||
[3]:http://ask.xmodulo.com/expand-xfs-file-system.html
|
||||
|
@ -0,0 +1,107 @@
|
||||
白话做好的开源项目
|
||||
================================================================================
|
||||
> 循序渐进的侃
|
||||
|
||||
**你有这个问题**:你已经权衡了[开源代码的优劣势][1],你也已经知道[你的软件需要成为一个开源项目][2],但是,你不知道怎么做好的开源项目。
|
||||
|
||||
当然,你也许已经知道[如何创建Github帐号并开始][3],但是这些事实上是做开源比较简单的部分。而真真正正难的部分是如何让足够多的人,关注你的项目并给你的项目做贡献。
|
||||
|
||||
![](http://a4.files.readwrite.com/image/upload/c_fit,q_80,w_630/MTE5NDg0MDYxMTg2Mjk1MzEx.jpg)
|
||||
|
||||
接下来的原则是会指导你构建和发布其他人愿意关注的代码。
|
||||
|
||||
### 基本原则 ###
|
||||
|
||||
选择开源可能有许多原因。也许你希望吸引一个社区来帮助编写你的代码。也许,[总所周知][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)
|
||||
校对:[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [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/
|
Loading…
Reference in New Issue
Block a user