为什么建设一个社区值得额外的努力
社区

> 
> 建立 NethServer 社区是有风险的。但是我们从这些激情的人们所带来的力量当中学习到了很多。
> 
> 
> 


![](/data/attachment/album/201805/22/171454x5jfnf8rggfsrgzo.png)


当我们在 2003 年推出 [Nethesis](http://www.nethesis.it/) 时，我们还只是系统集成商。我们只使用已有的开源项目。我们的业务模式非常明确：为这些项目增加多种形式的价值：实践知识、针对意大利市场的文档、额外模块、专业支持和培训课程。我们还通过向上游贡献代码并参与其社区来回馈上游项目。


那时时代不同。我们不能太张扬地使用“开源”这个词。人们将它与诸如“书呆子”，“没有价值”以及最糟糕的“免费”这些词联系起来。这些不太适合生意。


在 2010 年的一个星期六，Nethesis 的工作人员，他们手中拿着馅饼和浓咖啡，正在讨论如何推进事情发展（嘿，我们喜欢在创新的同时吃喝东西！）。尽管势头对我们不利，但我们决定不改变方向。事实上，我们决定加大力度 —— 去做开源和开放的工作方式，这是一个成功运营企业的模式。


多年来，我们已经证明了该模型的潜力。有一件事是我们成功的关键：社区。


在这个由三部分组成的系列文章中，我将解释社区在开放组织的存在中扮演的重要角色。我将探讨为什么一个组织希望建立一个社区，并讨论如何建立一个社区 —— 因为我确实认为这是如今产生新创新的最佳方式。


### 这个疯狂的想法


与 Nethesis 伙伴一起，我们决定构建自己的开源项目：我们自己的操作系统，它建立在 CentOS 之上（因为我们不想重新发明轮子）。我们假设我们拥有实现它的经验、实践知识和人力。我们感到很勇敢。


我们非常希望构建一个名为 [NethServer](http://www.nethserver.org/) 的操作系统，其使命是：通过开源使系统管理员的生活更轻松。我们知道我们可以为服务器创建一个 Linux 发行版，与当前已有的相比，它更容易使用、更易于部署，并且更易于理解。


不过，最重要的是，我们决定创建一个真正的，100％ 开放的项目，其主要规则有三条：


* 完全免费下载
* 开发公开
* 社区驱动


最后一个很重要。我们是一家公司。我们能够自己开发它。如果我们在内部完成这项工作，我们将会更有效（并且做出更快的决定）。与其他任何意大利公司一样，这将非常简单。


但是我们已经如此深入到开源文化中，所以我们选择了不同的路径。


我们确实希望有尽可能多的人围绕着我们、围绕着产品、围绕着公司周围。我们希望对工作有尽可能多的视角。我们意识到：独自一人，你可以走得快 —— 但是如果你想走很远，你需要一起走。


所以我们决定建立一个社区。


### 下一步是什么？


我们意识到创建社区有很多好处。例如，如果使用产品的人真正参与到项目中，他们将提供反馈和测试用例、编写文档、发现 bug，与其他产品进行比较，建议功能并为开发做出贡献。所有这些都会产生创新，吸引贡献者和客户，并扩展你产品的用户群。


但是很快就出现了这样一个问题：我们如何建立一个社区？我们不知道如何实现这一点。我们参加了很多社区，但我们从未建立过一个社区。


我们擅长编码 —— 而不是人。我们是一家公司，是一个有非常具体优先事项的组织。那么我们如何建立一个社区，并在公司和社区之间建立良好的关系呢？


我们做了你必须做的第一件事：学习。我们从专家、博客和许多书中学到了知识。我们进行了实验。我们失败了多次，从结果中收集数据，并再次进行测试。


最终我们学到了社区管理的黄金法则：**没有社区管理的黄金法则。**


人们太复杂了，社区无法用一条规则来“统治他们”。


然而，我可以说的一件事是，社区和公司之间的健康关系总是一个给予和接受的过程。在我的下一篇文章中，我将讨论你的组织如果想要一个蓬勃发展和创新的社区，应该期望提供什么。




---


via: <https://opensource.com/open-organization/18/1/why-build-community-1>


作者：[Alessio Fattorini](https://opensource.com/users/alefattorini) 译者：[geekpi](https://github.com/geekpi) 校对：[wxy](https://github.com/wxy)


本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出


OK
When we launched [Nethesis](http://www.nethesis.it/) in 2003, we were just system integrators. We only used existing open source projects. Our business model was clear: Add multiple forms of value to those projects: know-how, documentation for the Italian market, extra modules, professional support, and training courses. We gave back to upstream projects as well, through upstream code contributions and by participating in their communities.

Times were different then. We couldn't use the term "open source" too loudly. People associated it with words like: "nerdy," "no value" and, worst of all, "free." Not too good for a business.


On a Saturday in 2010, with pasties and espresso in hand, the Nethesis staff were discussing how to move things forward (hey, we like to eat and drink while we innovate!). In spite of the momentum working against us, we decided not to change course. In fact, we decided to push harder—to make open source, *and an open way of working*, a successful model for running a business.

Over the years, we've proven that model's potential. And one thing has been key to our success: community.

In this three-part series, I'll explain the important role community plays in an open organization's existence. I'll explore *why* an organization would want to build a community, and discuss *how* to build one—because I really do believe it's the best way to generate new innovations today.

## The crazy idea

Together with the Nethesis guys, we decided to build our own open source project: our own operating system, built on top of CentOS (because we didn't want to reinvent the wheel). We assumed that we had the experience, know-how, and workforce to achieve it. We felt brave.

And we very much wanted to build an operating system called [NethServer](http://www.nethserver.org/) with one mission: making a sysadmin's life easier with open source. We knew we could create a Linux distribution for a server that would be more accessible, easier to adopt, and simpler to understand than anything currently offered.

Above all, though, we decided to create a real, 100% open project with three primary rules:

- completely free to download,
- openly developed, and
- community-driven

That last one is important. We were a company; we were able to develop it by ourselves. We would have been more effective (and made quicker decisions) if we'd done the work in-house. It would be so simple, like any other company in Italy.

But we were so deeply into open source culture culture that we chose a different path.

We really wanted as many people as possible around us, around the product, and around the company. We wanted as many perspectives on the work as possible. We realized: Alone, you can go fast—but if you want to go *far*, you need to go *together*.

So we decided to build a community instead.

## What next?

We realized that creating a community has so many benefits. For example, if the people who use your product are really *involved* in the project, they will provide feedback and use cases, write documentation, catch bugs, compare with other products, suggest features, and contribute to development. All of this generates innovations, attracts contributors and customers, and expands your product's user base.

But quicky the question arose: How can we build a community? We didn't know how to achieve that. We'd *participated* in many communities, but we'd never *built* one.

We were good at code—not with people. And we were a company, an organization with very specific priorities. So how were we going to build a community and foster good relationships between the company and the community itself?

We did the first thing you had to do: study. We learned from experts, blogs, and lots of books. We experimented. We failed many times, collected data from the outcomes, and tested them again.

Eventually we learned the golden rule of the community management: *There is no golden rule of community management*.

People are too complex and communities are too different to have one rule "to rule them all,"

One thing I *can* say, however, is that an healthy relationship between a community and a company is always a process of *give and take*. In my next article, I'll discuss what your organization should expect to *give* if it wants a flourishing and innovating community.

## 5 Comments