agpl限制了開源

by Julien Danjou

通過朱利安·丹喬(Julien Danjou)

不要限制您的開源項目的潛力 (Don’t limit your open source project’s potential)

During the OpenStack summit a few weeks ago, I had the chance to talk to some people about my experience on running open source projects. It turns out that after hanging out in communities and contributing to many projects for years, I may be able to provide some hindsight and an external eye to many of those who are new to it.

在幾周前的OpenStack峰會上，我有機會與一些人談論了我在運行開源項目上的經驗。 事實證明，在社區中閑逛并為許多項目做出了多年貢獻之后，我也許可以為許多新手提供一些后見之明和外在的眼光。

There are plenty of resource explaining how to run an open source projects out there. Today, I would like to take a different angle and emphasize what you should not socially do in your projects. This list comes from various open source projects I’ve encountered these past years. Let’s explore these bad practices and illustrate them with examples.

有大量資源說明如何在那里運行開源項目。 今天，我想換一個角度，強調在項目中不應該在社交上做的事情。 這份清單來自我過去幾年遇到的各種開源項目。 讓我們探索這些不良做法，并通過示例進行說明。

不要將新的貢獻者視為煩惱 (Don’t perceive new contributors as an annoyance)

When software developers and maintainers are busy, there’s one thing they don’t need: more work. To many people, the instinctive reactions to external contribution is: damn, more work. And actually, it is.

當軟件開發人員和維護人員忙碌時，他們不需要一件事：做更多的工作。 對許多人來說，對外部貢獻的本能React是：該死，更多的工作。 實際上是這樣。

So some maintainers tend to avoid that surplus of work. They explicitly state that they don’t want contributions, or they passive-aggressively make contributors feel un-welcome. This can take a lot of different forms, from ignoring them to being unpleasant. This allows the project maintainer to avoid coaching new contributors on how they can productively add to the project.

因此，一些維護者傾向于避免過多的工作。 他們明確聲明自己不想要貢獻，或者他們被動地積極地使貢獻者感到不受歡迎。 從忽略它們到令人不快，這可以采取許多不同的形式。 這使項目維護者可以避免指導新的貢獻者如何有效地添加到項目中。

This is one of the biggest mistakes you can make in open source. If people are sending you more work, you should do whatever it takes to feel them welcome, so that they will continue working with you. Pretty soon they might become the people doing the work you are doing, instead of you. Just think: retirement!

這是您在開源中可能犯的最大錯誤之一。 如果人們給您發送了更多工作，則您應該盡一切努力使他們受到歡迎，以便他們繼續與您合作。 很快，他們可能會代替您，成為從事您正在做的工作的人。 試想：退休！

Let’s take a look at my friend Gordon, who started as a Ceilometer contributor in 2013. He was doing great code reviews, but he was actually giving me more work by catching bugs in my patches and sending me patches that I had to review. Instead of being a bully so that he would stop making me rework my code and review his patches, I requested that we trust him even more by adding him as a core reviewer.

讓我們看一下我的朋友Gordon，他于2013年開始擔任Ceilometer的貢獻者。他進行了出色的代碼審查，但實際上，他通過捕獲補丁中的錯誤并將需要審查的補丁發送給我，為我提供了更多的工作。 我要求自己不再是一個欺負人，以免他停止讓我重新編寫代碼并審閱他的補丁， 而是要求我們將他添加為核心審閱人，從而更加信任他 。

If contributors aren’t able to make their first contribution, they definitely won’t make a second one. They won’t make any. And the project may very well have lost its future maintainers.

如果貢獻者無法做出第一筆貢獻，那么他們肯定不會做出第二筆貢獻。 他們什么都不會做。 這個項目很可能已經失去了未來的維護者。

不要將您的貢獻者僅限于艱苦的工作 (Don’t limit your contributors to just grunt work)

When new contributors arrive and want to contribute to a particular project, they bring with them a wide range of motivations. Some of them are users, but some of them are just people looking to see what it’s like contributing to an open source project. They want the thrill of giving back to an ecosystem that they use.

當新的貢獻者到達并希望為特定項目做出貢獻時，他們就會帶來各種各樣的動機。 他們中的一些人是用戶，但其中一些人只是希望了解對開源項目做出貢獻的人們。 他們希望獲得回饋他們使用的生態系統的快感。

The usual response from maintainers is to push people into doing grunt work. That means doing jobs that have no interest, little value, and probably have no direct impact on the project.

維護人員通常的React是促使人們從事艱苦的工作。 這意味著所做的工作沒有興趣，幾乎沒有價值，并且可能對項目沒有直接影響。

Some people actually don’t mind doing grunt work, but others do. Some people will love it as soon as you give them something — anything — to do and acknowledgment for their efforts. But others will feel offended that you’ve asked them to do low impact work. Be aware of this, and be sure to high-five the people doing your grunt work. That’s the only way to keep them around.

實際上，有些人不介意從事艱苦的工作，而其他人則愿意。 只要您給他們一些東西(任何東西)并感謝他們的努力，有些人就會喜歡它。 但是其他人會感到生氣，因為您要求他們進行影響較小的工作。 請注意這一點，并確保有五名從事您的艱苦工作的人。 這是保持它們不動的唯一方法。

別忘了贊美即使很小的貢獻 (Don’t forget to praise even small contributions)

When the first pull request a new contributor sends over is just a typo fix, some developers will feel annoyed at the prospect of wasting precious time vetting such a small contribution. And nobody cares about bad English in their documentation anyway, right?

當新貢獻者發送的第一個請求只是一個錯字修復程序時，一些開發人員會因為浪費寶貴的時間審查如此小的貢獻而感到惱火。 無論如何，沒人會在意文檔中的英語不好，對吧？

My first contributions to home-assistant and Postmodern were me fixing typos in their documentation.

我對家庭助理和后現代主義者的第一個貢獻是我在他們的文檔中修正了錯別字。

I contributed to Org-mode for a few years. My first patch to orgmode was about fixing a docstring. Then, I sent 56 patches, fixing bugs and adding fancy features. I also wrote a few external modules. To this day, I’m still #16 on the top-committer list of Org-mode, which lists 390 contributors. So I ended up being much more than a small contributor to their project. I’m pretty sure in retrospect their community was glad that they didn’t dismiss my documentation fix as a waste of their time.

我為組織模式做出了幾年的貢獻。 我對orgmode的第一個補丁是關于修復文檔字符串。 然后，我發送了56個補丁，修復了錯誤并添加了精美的功能。 我還寫了一些外部模塊。 時至今日，我仍然在組織模式的最高提交者列表中排名第16，該列表列出了390個貢獻者。 因此，我最終不僅僅是為他們的項目貢獻一小筆錢。 我很確定，回想一下他們的社區很高興他們沒有因為浪費時間而忽略了我的文檔修訂。

不要為新手設置過高的門檻 (Don’t set the bar too high for new comers)

When new contributors arrive, their knowledge about the project, its context, and the technologies can vary largely. One of the mistakes project maintainers often make is to ask contributors to perform a bunch of complicated tasks before they can contribute. This can have the effect of scaring away many contributors who are are relatively shy or introverted. They may just disappear, feeling too stupid to help.

當新的貢獻者到達時，他們對項目，其上下文和技術的了解可能會大相徑庭。 項目維護人員經常犯的一個錯誤是，要求貢獻者執行一堆復雜的任務，然后才能做出貢獻。 這可能會嚇跑許多相對害羞或內向的貢獻者。 他們可能會消失，感覺太愚蠢而無法幫助。

Before making any comment, you should not have any assumption about their knowledge. You also should be very delicate when assessing contributor skills, as some people might feel vexed if you underestimate them too much.

在發表評論之前，您不應對他們的知識有任何假設。 在評估貢獻者技能時，您也應該非常謹慎，因為如果您低估了他們，有些人可能會感到煩惱。

Once their skill level has been properly evaluated (a few exchanges should be enough), you need to mentor your contributor to the right degree so they can blossom. It takes time and experience to master this, and you may likely lose some of them in the process, but it’s a path that every maintainer has to take.

在正確評估了他們的技能水平之后(應該進行幾次交流就足夠了)，您需要指導貢獻者達到正確的程度，這樣他們才能成長。 掌握它需要時間和經驗，您可能會在此過程中失去其中的一些，但這是每個維護者都必須采取的方法。

Mentoring is a very important aspect of welcoming new contributors to your project, whatever it may be. Mentorship applies nicely outside free software too.

無論是什么項目，指導都是歡迎新的項目參與者的一個非常重要的方面。 指導也很好地適用于外部免費軟件。

不要讓別人為了幫助你而犧牲 (Don’t make people to make sacrifices in order to help you)

This is an aspect that varies a lot depending on the project and context, but it’s really important. As a free software project, where most people will contribute on their own good will and sometimes spare time, you must not require them to make big sacrifices. This won’t work.

這是一個因項目和上下文而異的方面，但這確實很重要。 作為一個自由軟件項目，大多數人將以自己的善意做出貢獻，有時還會騰出空余時間，因此，您不能要求他們做出重大犧牲。 這行不通。

One of the worst things you can do is require contributors to fly 5,000 kilometers to meet in person to discuss the project. This puts contributors in an unfair position, based on their ability to leave their family for a week, take a plane/boat/car/train, rent an hotel, etc. This is not good, and you should do everything in your power to avoid requiring contributors to do this in order to participate in the project and feel included in its community.

您可以做的最糟糕的事情之一就是要求參與者飛行5,000公里，親自見面討論該項目。 根據供款人離開家人一周的能力，乘飛機/輪船/汽車/火車，租用酒店等，這會使供款人處于不公平的位置。這不好，您應該盡一切可能避免要求貢獻者這樣做才能參與該項目，并使其融入社區。

Don’t get me wrong. I’m not saying that social activities should be prohibited. Quite the contrary. Just avoid excluding people when you discuss any project.

不要誤會我的意思。 我并不是說應該禁止社交活動。 恰恰相反。 在討論任何項目時，只要避免排斥他人即可。

The same applies to any other form of discussion that makes it complicated for everyone to participate: IRC meetings (it’s hard for some people to book an hour, especially depending on the timezone they live in), video-conferencing (especially using non-free software), etc.

這同樣適用于任何其他形式的討論，使所有人都難以參與：IRC會議(某些人很難預定一個小時，尤其是取決于他們所在的時區)，視頻會議(尤其是使用非免費會議)軟件)等

Everything that requires people to basically interact with the project in a synchronous manner for a period of time will put constraints on them that can make them uncomfortable.

要求人們在一段時間內基本與項目進行交互的所有內容都會給他們帶來約束，使他們感到不舒服。

The best medium is still e-mail and asynchronous derivatives (like bug trackers) which allow people to work at their own pace on their own time.

最好的媒介仍然是電子郵件和異步派生工具(例如錯誤跟蹤器)，使人們可以按自己的節奏按自己的時間工作。

別忘了您有書面或暗示的行為準則 (Don’t forget to that you have a Code of Conduct — written or implied)

Conduct codes seem to be a trendy topic (and a touchy subject), as more and more communities open up to a wilder audience than before — which is great.

行為準則似乎是一個時髦的話題(也是一個敏感的話題)，因為越來越多的社區向比以前更開放的受眾開放了，這是很棒的。

Actually, all communities have a code of conduct, whether it’s written with black ink, or being carried in everyone’s mind unconsciously.

實際上，所有社區都有行為準則，無論是用黑色墨水寫成的行為準則，還是無意識地帶入每個人的頭腦中的行為準則。

Now, depending on the size of your community and how you feel comfortable applying it, you may want to write it down in a document, like Debian did.

現在，根據您社區的規模以及您對它的使用感覺如何，您可能想要像Debian一樣將其記錄在文檔中 。

Having a code of conduct does not transform your whole project community magically into a bunch of care bears who follow its guidance. But it does provide an interesting artifact that you can refer to when needed. You can throwing it at some people, to indicate that their behavior is not welcome in the project, and somehow, ease their potential exclusion — even if nobody wants to go that far generally, and that’s it’s rarely that useful.

制定行為準則并不能將整個項目社區神奇地轉變為遵循準則指導的一堆護理熊。 但是它確實提供了一個有趣的工件，您可以在需要時引用它。 您可以將其扔給某些人，以表明他們的行為在項目中不受歡迎，并以某種方式減輕了他們潛在的排斥-即使沒有人愿意走這么大的距離，這很少那么有用。

I don’t think it’s mandatory to have such a paper on smaller projects. But you have to keep in mind that the implicit code of conduct will be derived from your own behavior. The way your leader(s) communicate with others will set the entire social mood of the project. Do not underestimate that.

我認為在較小的項目上寫這樣的論文不是強制性的。 但是您必須記住，隱式的行為準則將源自您自己的行為。 您的領導者與他人交流的方式將設定項目的整個社交氛圍。 不要小看。

When we started the Ceilometer project, we implicitly followed the OpenStack Code of Conduct before it even existed, and probably set the bar a little higher. Being nice, welcoming and open-minded, we achieved a decent diversity score, with up to 25% of our core team being women — way above the current ratio in OpenStack and most open source projects!

當我們開始Ceilometer項目時，我們甚至在《 OpenStack行為準則》還沒有出現之前就暗中遵循了它，并且可能將這個標準提高了一些。 我們態度友善，熱情，開放，獲得了不錯的多樣性，核心團隊中多達25％是女性，遠遠超過了OpenStack和大多數開源項目中的現有比例！

不要讓非英語母語者感到局外人 (Don’t make non-native English speakers feel like outsiders)

It’s quite important to be aware of that the vast majority of free software projects out there are using English as the common language of communication. This makes a lot of sense: it’s a commonly spoken language, and it seems to do the job well.

非常重要的是要意識到，那里的絕大多數自由軟件項目都使用英語作為交流的通用語言。 這很有道理：這是一種常用的語言，似乎做得很好。

But a large proportion of the hackers out there are not native English speakers. Many are not able to speak English fluently. This means that the rate at which they can have a conversation might be slow, which can frustrate native English speakers.

但是，大部分的黑客不是以英語為母語的。 許多人不能說一口流利的英語。 這意味著他們可以進行交談的速度可能很慢，這可能會使以英語為母語的人感到沮喪。

The principal demonstration of this phenomena can be seen in social events (e.g. conferences) where people are debating. It can be very hard for people to explain their thoughts in English and to communicate properly at a decent rate, making the conversation and the transmission of ideas slow.

這種現象的主要表現可以在人們辯論的社交活動(例如會議)中看到。 人們很難用英語解釋他們的想法，并很難以適當的速度進行適當的交流，從而使對話和思想交流變慢。

The worst thing that one can see in this context is a native English speaker cutting people off and ignoring them, just because they are talking too slowly. I do understand that it can be frustrating, but the problem here is not the non-native English speaking — it’s that the medium being used does not put your fellow coders on an the same even playing field that asynchronous conversation would.

在這種情況下，最糟糕的事情是說英語的母語人士將人們拒之門外而無視他們，只是因為他們的談話太慢了。 我確實知道這可能會令人沮喪，但是這里的問題不是非母語的英語-這是因為使用的介質不會將您的其他編碼人員置于與異步對話相同的競爭環境中。

To a lesser extent, the same applies to IRC meetings, which are relatively synchronous. Completely asynchronous media do not have this flaw, and that’s why they should also be preferred.

在較小程度上，這也適用于相對同步的IRC會議。 完全異步的媒體沒有此缺陷，因此也應該首選它們。

沒有遠見，沒有授權 (No vision, no delegation)

One of the most common tragedies in the open source world is seeing a maintainer struggling with the growth of their project while other contributors are unsuccessfully trying to help them.

開源世界中最常見的悲劇之一是，維護人員正在為項目的增長而苦苦掙扎，而其他貢獻者卻沒有設法幫助他們。

Indeed, when an influx of new contributor starts asking for new features, feedback, or directions, some maintainers choke and don’t know how to respond. This ends up frustrating contributors, who therefore may simply vanish.

確實，當大量新貢獻者開始要求提供新功能，反饋或指示時，一些維護人員會感到ke惱，不知道如何應對。 這最終導致令人沮喪的貢獻者，因此他們可能會消失。

It’s important to have a vision for your project and to communicate it. Make it clear to your contributors what you want and don’t want in your project. Transferring that in a clear (and non-aggressive, please) manner, is a good way of lowering the friction between contributors. They’ll pretty soon know whether they want to join your ship or not, and what to expect. So be a good captain.

對項目有遠見并進行溝通很重要。 向您的貢獻者明確說明您在項目中想要和不想要的東西。 以明確的方式(而不是侵略性的)進行轉移是減少貢獻者之間摩擦的好方法。 他們很快就會知道他們是否要加入您的船，以及會發生什么。 所以做個好隊長。

If they chose to work with you and contribute, you should start trusting them as soon as you can, and delegate some of your responsibilities. These can be any tasks that you used to do yourself: review patches targeting some subsystem, fixing bugs, or writing docs.

如果他們選擇與您合作并做出貢獻，則應盡快開始信任他們，并委派您的一些職責。 這些可以是您自己執行的任何任務：查看針對某些子系統的補丁程序，修復錯誤或編寫文檔。

Let people own an entire part of the project, so they feel responsible and care about it as much as you do. Doing the opposite — being a control-freak — is your best shot at staying alone with your open source software. And no project is going to grow and become successful that way.

讓人們擁有項目的整個部分，讓他們感到責任心并像您一樣關心它。 相反，做個怪胎是與開源軟件獨處的最佳選擇。 而且沒有任何項目能夠以這種方式發展壯大。

In 2009, when Uli Schlachter sent his first patch to awesome, this was more work for me. I had to review this patch, and I was already pretty busy designing the new versions of awesome and doing my day job! Uli’s work was not perfect, and I had to fix it myself. More work. And what did I do? A few minutes later, I replied to him with a clear plan of what he should do, and what I thought about his work.

2009年，當Uli Schlachter將他的第一個補丁發送給awesome時 ，這對我來說是更多的工作。 我必須查看此補丁，并且我已經非常忙于設計awesome的新版本并完成我的日常工作！ Uli的工作并不完美，我必須自己修復。 更多的工作。 那我做了什么？ 幾分鐘后，我以清晰的計劃回答了他應該做什么以及我對他的工作的想法。

In response, Uli sent patches and improved the project. Do you know what Uli does today? He manages the awesome window manager project, and has since 2010 instead of me. I managed to transmit my vision, delegate it, and then retire!

作為回應，Uli發送了補丁并改進了該項目。 你知道烏里今天做什么嗎？ 他管理著很棒的窗口管理器項目，自2010年以來一直代替我。 我設法傳達了我的愿景，將其委托給他人，然后退休！

注意識別各種貢獻 (Be careful to recognize all kinds of contributions)

People contribute in different ways, and it’s not always with code. There are a lot of tasks surrounding free software projects: documentation, bug triage, user support, user experience design, communication, translation…

人們以不同的方式做出貢獻，而并非總是使用代碼。 關于自由軟件項目，有很多任務：文檔，錯誤分類，用戶支持，用戶體驗設計，交流，翻譯...

For example, it took a while for Debian to recognize that they should grant their translators the status of Debian Developer. OpenStack is working in the same direction by trying to recognize non-technical contributions.

例如， Debian花了一段時間才意識到他們應該授予翻譯者Debian Developer的身份。 OpenStack通過嘗試識別非技術性貢獻而朝著同一個方向努力。

As soon as your project starts attributing badges to some people and creating different classes of members in the community, you should be very careful that you don’t forget anyone. That’s the easiest road to losing contributors along the road.

一旦您的項目開始將徽章分配給某些人并在社區中創建不同類別的成員，您應該非常小心，不要忘記任何人。 這是沿途失去貢獻者的最簡單方法。

別忘了感恩 (Don’t forget to be thankful)

This whole list has been inspired by many years of open source hacking and free software contributions. Let me know in the comments section if you have anything that has blocked you from contributing to open source projects. Thanks for reading!

整個清單的靈感來自多年的開源黑客和免費軟件貢獻。 如果您有任何阻礙您參與開源項目的內容，請在評論部分讓我知道。 謝謝閱讀！

Original article at https://julien.danjou.info/blog/2016/foss-projects-management-bad-practice

原始文章位于https://julien.danjou.info/blog/2016/foss-projects-management-bad-practice

翻譯自: https://www.freecodecamp.org/news/the-bad-practice-in-foss-projects-management-32f66c3515f9/

agpl限制了開源

總結

以上是生活随笔為你收集整理的agpl限制了开源_不要限制您的开源项目的潜力的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。