Start by taking patches from everyone. You don't have to accept them all - if rejecting a patch, explain why it was rejected and what can be done to improve it.
For accepted patches, clean them up (and document the cleanups in a coding style guide).
The people providing the most and best patches could then get access to the repository directly and start accepting patches themselves.
At this point, accept the fact that the project is no longer just yours, though you may want to continue and lead it.
There are as many styles of doing OSS as there are projects. The guidelines below have worked so far for me. YMMV.
Don't give write access to your repository to everyone. One of the biggest benefits of DVCS is that you don't have to, everyone gets their own repository, in principle equal to yours. Only give write access to people you really trust and that you know has similar views about the project.
Always encourage patches and pull requests. Sometimes you will have to reject some patch, however make sure you really justify your rejection to the contributor; people don't like being rejected without good reason and it would discourage them (and other people too, because other people will see the issue history in the tracker) from further contributing. Also, by pointing out what's wrong with the patch, both you and the contributor will learn from the experience.
Ownership is a very relative thing. If someone contributes 10 times more than you have throughout the whole history of the project, then who really owns the project? Don't worry too much about ownership, concentrate on the project itself. Make sure you always do what's best for the project. Everything else will follow naturally.
The good point to mention here, is that other developers want to contribute to your project, because they need to change/modify/upgrade it a little bit based on their needs. If they don't have the changes committed into your project, they won't be able to easily migrate to next version. These developers won't want you to share credit or anything. They just want their modifications/upgrades be committed.
The more developers are committing the higher chance is there that the project will be alive for a long time. The credit will be yours.
发布评论
评论（3）
有不同程度的贡献。
首先从每个人那里获取补丁。您不必全部接受 - 如果拒绝某个补丁，请解释其被拒绝的原因以及可以采取哪些措施来改进它。
对于已接受的补丁，请清理它们（并在编码风格指南中记录清理情况）。
然后，提供最多和最好补丁的人可以直接访问存储库并开始自己接受补丁。
此时，请接受该项目不再仅属于您的事实，尽管您可能想继续并领导它。
Have different levels of contribution.
Start by taking patches from everyone. You don't have to accept them all - if rejecting a patch, explain why it was rejected and what can be done to improve it.
For accepted patches, clean them up (and document the cleanups in a coding style guide).
The people providing the most and best patches could then get access to the repository directly and start accepting patches themselves.
At this point, accept the fact that the project is no longer just yours, though you may want to continue and lead it.
有多少项目就有多少种开源软件的风格。到目前为止，以下指南对我来说很有效。 YMMV。
There are as many styles of doing OSS as there are projects. The guidelines below have worked so far for me. YMMV.
这里要提到的一点是，其他开发人员希望为您的项目做出贡献，因为他们需要根据自己的需求对其进行一些更改/修改/升级。如果他们没有将更改提交到您的项目中，他们将无法轻松迁移到下一个版本。
这些开发人员不会希望您分享信用或任何东西。他们只是希望进行修改/升级。
投入的开发人员越多，该项目长期存在的机会就越大。信用将是你的。
The good point to mention here, is that other developers want to contribute to your project, because they need to change/modify/upgrade it a little bit based on their needs. If they don't have the changes committed into your project, they won't be able to easily migrate to next version.
These developers won't want you to share credit or anything. They just want their modifications/upgrades be committed.
The more developers are committing the higher chance is there that the project will be alive for a long time. The credit will be yours.