If you read the history of most open source projects, they start with one person doing a lot of the initial work. If there's a team, it's small, and one person actually leads the team.
To pick one example. In the Python community, they refer to Guido van Rossum as the Benevolent Dictator for Life (BDFL). His word is (more-or-less) final. In many cases there are folks don't agree with him -- but for the sake of the Python community -- they seem to acquiesce to his judgment.
I think every open source project has a (singular) lead programmer who assures that decisions get made, and made in a consistent way.
Back in the olden days, Fred Brooks (The Mythical Man Month) described "chief programmer teams". Same concept. Someone is in charge of the technical content. Emphasis on the one. Nowadays we call the the "architect" or some such term.
No real methodology here, but I think 2 things are important:
Have well defined goals and responsibilities.
Let each developer have the last say in how their allocated part should be done.
In open source projects the only real and strongest motivation is the fun to be had coding the product. Relating to #2 above, if people are told what to do, and they don't agree with it, the motivation starts lacking. Of course there will always be a bit of give-and-take like in any other type of relationship.
Also about the face time, Skype is great for having face to face meetings, which I recommend at least once a week or month (depending on the size and momentum of the project)
This is a difficult question to answer because "open source projects" is a very broad selection of projects. I think the defining characteristic is the project has a single unifying goal (perhaps, a set of related goals).
Are you on any open source mailing lists? I am subscribed to my favorite distro's mailing list and the developers e-mail each other many times a day. Also, there are other avenues of communication such as IRC / Instant Messenger.
I am not a RoR developer, but I would suggest skimming through Getting Real for some inspiration.
My guess is that your private projects are all run and coded by developers. Developers are known to... keep on developing. The big difference, in my experience is that a company has experienced managers that can define when things are DONE. I'd recommend putting someone on the task of defining goals and decide when things are done.
还有一件事。 既然您在评论中说您确实有代码，只是进行了大量重写，我强烈建议您阅读 Eric Raymond 的 大教堂和集市。 埃里克实际上有点疯狂，但这篇文章对于任何想要运行自由软件项目的人来说都是无价的。
I've been on some projects where we had a lot more talkers than developers. My inclination is to ignore the talkers and listen to the coders. Even then there's usually one person who is in charge of accepting patches. There may be political issues they have to tread lightly around, but for all intents and purposes they have final say.
Linus has had some fairly famous issues with the same problem. Take note of this thread from 2006: Talk is cheap. Show me the code.
One more thing. Since you say in the comments that you do have code, just a lot of rewrites, I'd highly suggest you read Eric Raymond's The Cathedral and the Bazzaar. Eric's a bit of a nutter actually, but the essay is priceless for anyone wanting to run a Free Software project.
I'd have a think about your and your team mate's motivation and goals in this project. Are they to:
a) Create an awesome product
or
b) play around with software, and learn some new things
Both answers are equally valid, and i'm guessing it'd be a mix with a leaning towards one or the other.
If it's more of (a) then look at suggestions on methodology etc. Maybe even consider forming a company around your awesome idea. Because making such a thing takes work.. and well you probably get enough of that at work.
If it's mostly (b) then you're going to have a harder time making an awesome product, but an easier time in that you can forgive yourself for not getting there right away and suffering multiple re-writes. And you will all be learning new skills each time you look at it and work together which are very applicable to your long term careers.
Firstly i suggest you all be clear with each other on why you are there. Then look at paring back on what you are planning on doing, and release early and release often. If your project is made up of three components and one is complete, then release that as a separate component and start building a community of users. This will pay off as these users will possibly help you with your code, plus form a solid core of users for the full product and let you assess how you are going early rather than later.
发布评论
评论（6）
如果您阅读了大多数开源项目的历史，您会发现它们都是从一个人做大量的初始工作开始的。 如果有一个团队，也是很小的，并且只有一个人来领导这个团队。
举一个例子。 在 Python 社区中，他们将 Guido van Rossum 称为“终身仁慈的独裁者”(BDFL)。 他的话（或多或少）是最终的。 在很多情况下，有人不同意他的观点——但为了 Python 社区——他们似乎默许了他的判断。
我认为每个开源项目都有一个（单一的）首席程序员，他确保决策能够以一致的方式做出。
回到过去，弗雷德·布鲁克斯（人月神话）描述了“首席程序员团队”。 相同的概念。 技术内容有人负责。 强调一个。 如今我们称之为“建筑师”或类似的术语。
If you read the history of most open source projects, they start with one person doing a lot of the initial work. If there's a team, it's small, and one person actually leads the team.
To pick one example. In the Python community, they refer to Guido van Rossum as the Benevolent Dictator for Life (BDFL). His word is (more-or-less) final. In many cases there are folks don't agree with him -- but for the sake of the Python community -- they seem to acquiesce to his judgment.
I think every open source project has a (singular) lead programmer who assures that decisions get made, and made in a consistent way.
Back in the olden days, Fred Brooks (The Mythical Man Month) described "chief programmer teams". Same concept. Someone is in charge of the technical content. Emphasis on the one. Nowadays we call the the "architect" or some such term.
这里没有真正的方法论，但我认为有两件事很重要：
责任。
对他们的方式有最后发言权
分配的部分应该完成。
在开源项目中，唯一真正、最强烈的动机是编写产品的乐趣。 关于上面的#2，如果人们被告知要做什么，但他们不同意，那么动力就开始缺乏。 当然，就像任何其他类型的关系一样，总会有一些给予和索取。
另外关于面对面的时间，Skype 非常适合举行面对面的会议，我建议至少每周或每月一次（取决于项目的规模和势头）
No real methodology here, but I think 2 things are important:
responsibilities.
have the last say in how their
allocated part should be done.
In open source projects the only real and strongest motivation is the fun to be had coding the product. Relating to #2 above, if people are told what to do, and they don't agree with it, the motivation starts lacking. Of course there will always be a bit of give-and-take like in any other type of relationship.
Also about the face time, Skype is great for having face to face meetings, which I recommend at least once a week or month (depending on the size and momentum of the project)
这是一个很难回答的问题，因为“开源项目”是一个非常广泛的项目选择。 我认为决定性的特征是该项目有一个统一的目标（也许是一组相关的目标）。
您是否在任何开源邮件列表中？ 我订阅了我的最喜欢的发行版的邮件列表，开发人员每天会多次互相发送电子邮件。 此外，还有其他沟通途径，例如 IRC/即时消息。
我不是 RoR 开发人员，但我建议浏览一下 Getting Real 以获得一些灵感。
This is a difficult question to answer because "open source projects" is a very broad selection of projects. I think the defining characteristic is the project has a single unifying goal (perhaps, a set of related goals).
Are you on any open source mailing lists? I am subscribed to my favorite distro's mailing list and the developers e-mail each other many times a day. Also, there are other avenues of communication such as IRC / Instant Messenger.
I am not a RoR developer, but I would suggest skimming through Getting Real for some inspiration.
我的猜测是，您的私人项目都是由开发人员运行和编码的。 众所周知，开发人员...不断开发。 根据我的经验，最大的区别是公司拥有经验丰富的经理，他们可以定义事情何时完成。 我建议让某人负责定义目标并决定何时完成工作。
My guess is that your private projects are all run and coded by developers. Developers are known to... keep on developing. The big difference, in my experience is that a company has experienced managers that can define when things are DONE. I'd recommend putting someone on the task of defining goals and decide when things are done.
我参与过一些项目，其中谈论者比开发者多得多。 我的倾向是忽略谈话者并倾听编码员的意见。 即使这样，通常也会有一个人负责接受补丁。 可能存在一些政治问题，他们必须谨慎对待，但对于所有意图和目的，他们拥有最终决定权。
Linus 曾遇到过一些相当著名的同样问题。 请注意 2006 年的这条线索：谈话很廉价。 显示代码。
还有一件事。 既然您在评论中说您确实有代码，只是进行了大量重写，我强烈建议您阅读 Eric Raymond 的 大教堂和集市。 埃里克实际上有点疯狂，但这篇文章对于任何想要运行自由软件项目的人来说都是无价的。
I've been on some projects where we had a lot more talkers than developers. My inclination is to ignore the talkers and listen to the coders. Even then there's usually one person who is in charge of accepting patches. There may be political issues they have to tread lightly around, but for all intents and purposes they have final say.
Linus has had some fairly famous issues with the same problem. Take note of this thread from 2006: Talk is cheap. Show me the code.
One more thing. Since you say in the comments that you do have code, just a lot of rewrites, I'd highly suggest you read Eric Raymond's The Cathedral and the Bazzaar. Eric's a bit of a nutter actually, but the essay is priceless for anyone wanting to run a Free Software project.
我会考虑一下您和您的队友在这个项目中的动机和目标。 他们是要：
a）创建一个很棒的产品
还是
b）尝试使用软件，并学习一些新东西
这两个答案同样有效，我猜这将是偏向其中一个的混合体。
如果更多的是（a），那么看看方法论等方面的建议。甚至可以考虑围绕你的绝妙想法组建一家公司。 因为制作这样的东西需要工作……而且你可能在工作中已经受够了。
如果主要是（b），那么你将很难制作出出色的产品，但也会变得更容易，因为你可以原谅自己没有立即实现目标并遭受多次重写。 每次观看并一起工作时，你们都会学到新技能，这非常适合您的长期职业生涯。
首先，我建议你们彼此清楚自己为什么来这里。 然后看看减少你计划做的事情，尽早发布并经常发布。 如果您的项目由三个组件组成并且其中一个已完成，则将其作为单独的组件发布并开始构建用户社区。 这将会带来回报，因为这些用户可能会帮助您编写代码，并为完整产品形成坚实的用户核心，并让您尽早评估进展情况，而不是稍后评估。
祝你好运。
I'd have a think about your and your team mate's motivation and goals in this project. Are they to:
a) Create an awesome product
or
b) play around with software, and learn some new things
Both answers are equally valid, and i'm guessing it'd be a mix with a leaning towards one or the other.
If it's more of (a) then look at suggestions on methodology etc. Maybe even consider forming a company around your awesome idea. Because making such a thing takes work.. and well you probably get enough of that at work.
If it's mostly (b) then you're going to have a harder time making an awesome product, but an easier time in that you can forgive yourself for not getting there right away and suffering multiple re-writes. And you will all be learning new skills each time you look at it and work together which are very applicable to your long term careers.
Firstly i suggest you all be clear with each other on why you are there. Then look at paring back on what you are planning on doing, and release early and release often. If your project is made up of three components and one is complete, then release that as a separate component and start building a community of users. This will pay off as these users will possibly help you with your code, plus form a solid core of users for the full product and let you assess how you are going early rather than later.
Good luck.