最近在整理我们创业的一些故事，发布在我们刚做的一个外包项目上。看到当时一个关于股份讨论的issue，现在看来也很有意思。不同于一般的八卦聊天和疯婆娘吵架，我们吵的还是很有诚意和态度的（猜猜哪个是我？）。未删减无码版如下（如果你点了上一个链接，后面这个链接就不用点了，它们是一样的：原网页在这里）：
happypeter opened this issue
公司组织，cofounder 股份组成
今天 @asmcos 来信给我，说已经和业内资深人士 C 老师确立了股份关系，现在讨论和我的股份关系。
我和 C 老师并不认识，同时这边和我密切合作的 @luckyyang 和他们二位都不熟悉，而我的意愿是如果我有股份的话，@luckyyang 也和我占有同样比例的股份。
所以现在情况不太明朗，请大家讨论。 3 participants
happypeter
我先发言。
我觉得此时确立谁将成为公司的 co-founder 为时尚早。没有人会跟他不认识的人结婚。所以我建议咱们 onestep 的开源项目继续走，等大家磨合好了再定谁是谁也不迟。
未来定股份和发言权我的意见是兼顾自由和平等。
所谓平等就是 “骥不称其力，称其德也“，不能看暂时谁写的代码快，谁的股份就多，每个 co-founder 很多地方的贡献很难量化衡量，所以原则上每个 cofounder 股份和发言权平等，类似于民主社会里，无论老幼贤愚，大家都享有平等公民权。
所谓自由。我们欢迎资金形式入股等多种形式，估值细节我还没想好。资金入股获得资金收益，但是资金不能参与干扰日常决策，确保团队的工程师文化。co-founder 中干活多的人并不保证能有更多分红，但是团队文化应保证这些多劳动的人获得比别人更多的 glory 和 honor。另一方面就是将来业务分成多个部分，每个部分都会有相应的 dictator，由最了解该块业务的人担任，以保证团队效率。
happypeter
公司的这些组织原则会直接影响公司的企业文化，硅谷的一些企业家如是说
How do you define Culture? A1: a thread to bind everybody together A2: two things: what is important and what is acceptable. A3: sometimes you have to make hard decisions and let someone go… otherwise there won’t be a culture, that will be sort of anything. — Tom from github.
happypeter
Tom from github http://vimeo.com/39016099
Do you want to optimize your company for profit, or do you for happiness?! If I am using my whole life to make a company successful, I want to make sure that company also is trying to make my life happy. creating superfuns by crafting experiences hire = skill + cultural fit
happypeter
邮件中我和 @asmcos 有了明显争执（针对我的第一个评论），遵照 @asmcos 个人意见，内容不便公开。
我想说的是我心目中的公司是一个童话王国，坚信个性解放，民主自由这些东西。尚鼓励，不尚压制。我们自小到大几十年都在压制环境下长大，也知道压制可以产出一股蛮力，但是这种力量，跟创造性好像没什么关系。
来举一个实际的例子。好比我最近很着急，觉得项目进度慢了，这时我的 co-founder 正在海边和女友度假。那我应该做的不是反复打电话催他回来，而是我自己多写代码，让他能感动，自己做出相应的调整。我期待的结果是他不必回来，在海边拿出电脑编程。生活质量和事业同样重要。如果他不感动呢？那就证明我选错 cofounder 了。
所以选择 cofounder 和选择婚姻一样，不可草率。
asmcos peter，
做一个好的作品；和做一个商业公司是不同的概念。 做一个好的社区、一个好的开源软件；和做一个商业公司也是不同的概念。
我希望就我们要做的视频网站有个明确的规划（时间，目标）。 咱们第一要考虑用户的需求，拿出一个让用户可以用的产品。 第一步不一定那么完美（完美是相对的，咱们觉得美，用户说不定要的实用的功能）。 而能使用的产品。
以上是我个人观念，我和peter有些分歧。 希望听听 @luckyyang 意见。 …
luckyyang
由这个题目引申出来的诸多观点，才是我们这个网站/团队的根本问题，决定了我们这个团队能合作多久，我们的产品是什么样子。当然，我希望我们能一直愉快的合作下去，产品越来越好。
我们都听过太多的借口和妥协了，诸如“没办法，。。。就是这个样子，我们只能。。。”，而往往我们也是其中说这种话的那个人。我们受过太多集体主义至上，雷锋精神的教育，以至于我们现在已经不能再接受一点点这些“恶心”的东西，所以现在有理想往往和不切实际和不求利益联系起来，而想赚钱，想在商业上成功，就要像在战场上厮杀一样。是啊，战场上谁和你谈理想，谁管你来这是为了保卫家园还是想奸淫掠夺，先把对方干倒再说。
我最近发现，很多问题，如果从 人性和 自然的角度考虑，会想得通很多。比如说，少即是多，当我发现我更少的以金钱和地位衡量人的时候，我获得了更多的真正的朋友；当我更少的想着把赚钱放到第一位而只想着做好一个产品时，这个产品也更是我想要的模样。
关于 商业，很不幸，我也有点理想主义。我相信如果我按照作出好的产品这个方向来作为指导原则的话，最后才能作出一个有灵魂的产品，用户才会买账，商业才会成功，生活才会富足，心灵也会满足。
关于 规划，对于我个人来说，我似乎从来不太规划，我为人生规划（1年，3年，5年要怎么样）等等这些东西困惑了很多年，甚至我一直觉得我是不是没什么理想。确实，那时我没有理想和方向，对前方的路充满迷茫。但现在，我成熟了很多，我还是不会像那样规划，但我发现，隐约中我的规划很厉害，可以让我终身使用：不断地发现和进步，调整自己，以快乐和幸福为目标。这些我觉得也算规划，但我现在觉得这些更像 敏捷。
希望大家畅所欲言。
asmcos
从这封邮件，我发现有大家很多观点的本质上是一致的。 但实现方式确是有很大的差距。
但无论如何，我觉得 liujiyang 和peter 观点非常接近。 因此，这个产品仍然保持着良好的研发状态。我也期盼着能看到一个好的产品。 这个产品最终用在hpcasts.com上，我们能把hpcasts.com 做成用户非常满意的产品。
我需要和你们协商的是，在咱们这个hpcasts.com未完成之前。 我能否用 railscasts，happycasts 这样的框架来搭建 hpcasts.com ? …
happypeter
@asmcos 我们是个崇尚自由，敢于尝试各种不靠谱，浪费时间的方法的团队。所以如果你想装 railscasts，我们可以给你提提意见，不过我是反对这个的，所以肯定不会动手帮你，哈哈
happypeter
@asmcos 的思想里还是微软文化，我曾经工作在两家微软文化的团队，项目分别进行了 5 年和 2 年，强权压制下的文化是在堆大粪，而不是在做项目。
最强执行力的团队是最尊重个体的团队。建议何老师读一读 http://gettingreal.37signals.com/ ， 如果实在不同意里面的观点，那我可以很确切的说在 ruby 圈子里是没有高手愿意和你合作的。
luckyyang
@asmcos 确实，大家都是想作出好的东西来。你说我和peter不急么，我们可能和你一样着急。而我们也很清楚，踏实做产品是最好的选择。
asmcos
关于敏捷开发；我这段时间一直在关注ruby社区的文化。 差异很大。:–) …
asmcos
我怎么听着，我就是那 地主，唉。
happypeter
@asmcos 对啊，正因为你多年从事教学，站在为弱势群体服务的第一线，我和 @luckyyang 才非常尊重你，你可注意自己不要倒向 Linus 所说的 dark side 啊。
luckyyang
哈哈哈
何老师确实是我很尊重的人，做事情有激情是就能看出来的，而且难得热爱。
asmcos
还是我说的，我等待你们做的精品，我也会参与开发。 同时，我也会寻找其他方案。（这个会伤害大家的感情） 希望最终的这个分叉会有合并的时候。 要不就是我妥协；要不就是你们妥协。
happypeter
@asmcos
同时，我也会寻找其他方案。（这个会伤害大家的感情） 这个我是支持的，这是自由精神的一部分。逃离的自由。我个人也保留这个权力，未来我们的股份关系未形成法律 paper 之前，保持随时退出的权力。特此声明。
asmcos
这张图是你们描述的 管理代码的弊端：
http://ww1.sinaimg.cn/large/92c9aa30gw1e28y3a1gxzg.gif
这只能说是一个错误的管理。
happypeter
@asmcos 这不就是 happy tree friends。
改来改去是挺恐怖的，所以我们这边的方案就是
提出方案 issue 上参与讨论，没有明显反对意见就是通过 讨论结果形成 wiki 已经形成既定事实的内容，有代码或者 wiki 中有体现的内容，是不能随便改的，要改必须提供充足理由。 一个例子：#28 (comment) 再比如 @luckyyang 把颜色定为绿色，那么以后就没有人能够无理由的把它改为红色或其他，包括他自己，也必须提供极为充分的理由才能改。
asmcos
提出方案
issue 上参与讨论，没有明显反对意见就是通过
讨论结果形成 wiki
已经形成既定事实的内容，有代码或者 wiki 中有体现的内容，是不能随便改的，要改必须提供充足理由。 一个例子：#28 再比如 @luckyyang 把颜色定为绿色，那么以后就没有人能够无理由的把它改为红色或其他，包括他自己，也必须提供极为充分的理由才能改。
这就是我要的4条。为什么你说我这样做是微软风格？ …
happypeter
@asmcos 这是各种风格中共性的东西，就像不管是民主还是专制，法律都是有的。
asmcos
那我就非常奇怪，到底我说是哪些 你认为有问题？ 我倒是想仔细考虑一下。 …
happypeter
@asmcos 卡进度，就是典型的微软风格。卡进度，完不成就 blame 是 ruby 社区非常讨厌的。
不开会，不做计划，没有 Gantt chart，是 ruby 社区的正常行为。
http://zachholman.com/talk/how-github-uses-github-to-build-github/
asmcos
我认为有讨论，有计划，有时间预估是非常好的。
如果没有计划，那么谁知道这个东西做成什么样？ 拿建房子来说，如果没有图纸，没有设计 房子怎么建设呢？ …
happypeter
计划确实适用于盖房子这样的事情，因为这是工程 engineering 。 Edit: 同时也可已看出只有民工级的人才需要计划，真正的建筑设计师也绝不会有计划的。
但是软件开发绝非工程。所谓 “软件工程”其实是一句屁话，就跟“计算机科学”这个概念一样，是骗人用的。
Rails 的作者 DHH 说过：I am not a engineer，I am a craftsman. Paul Graham 写过一篇文章叫 “黑客与画家”（http://paulgraham.com/hp.html%EF%BC%89 中心思想就是其实软件开发更接近于艺术创造。我们不会让画家去做计划，所以我们的项目也不做计划。
以上是宏观的讨论，对于不做计划如何具体实施项目开发就是很复杂的技术问题了。要学习，我们可以从这本书入手： http://gettingreal.37signals.com/
以上观点也分享给 @luckyyang
happypeter closed the issue 8 months ago