回复内容：
1. 坚持遵循Wheaton法则
Wheaton法则的中心思想是“Don’t be a dick”，意思是不要成为一个不顾别人感受的人。在这里，我想说的是，你要耐心对待你的开源项目的用户。
2. 不要害怕说“不”、“请提交测试”，“请修复{X}”等
3. 明智地选择合作伙伴
如果你的项目已经增长到需要合作伙伴的地步，那么可以考虑让其他开发者来作为项目共同所有者或维护者。前提是，你要明智地选择这些人。
4.写好指导性文字每一个开源项目有三样东西是少不了的：项目目标和方法的简要说明、如何参与和授权许可。最好把它们预先放在一个README里。
5.技术社区
想要一个人做完所有的事是很难的，特别是很多人都期待着你能拿出好的作品。
抓住任何一个机会寻找pull请求。集思广益的力量是无穷大的，所以无论何时何地我都会向技术社区的成员寻求意见，他们常常说的RFC我从来没听过，甚至有的时候他们会主动研究前端主题。
项目可以很容易地升级随着项目中bug的修复和一些功能的改进，你需要发布另一个版本。需要注意的是：
1. 向后兼容
不要因为不向后兼容，而让用户重写大量代码。这样会让用户愤怒，继而抛弃你的项目。当然，你也不必像OpenJDK那样兼容15年前的产品。
2. 更新日志
有一个清晰明确的更新日志，需要包含：该版本发生了什么变化？会破坏用户现有项目的代码吗？等等。比如Twitter的做法：
- 每修复一个bug，就在更新日志中写上一个简短的条目
- 每添加一个功能，就简要描述一下并附上一些示例代码
- 每改变一个API，就需要在日志中用粗体明确指出
如果你有多个分支，就需要为每个分支都写一份更新日志。
3. 版本标签为你的项目的每一个版本打上一个标签，比如v1.0.0-alpha1、v1.0.0、v1.1.2，可以让你的用户很清晰地分辨出项目的版本。
4. 发布公告项目发布后，接下来就需要为这个事件写一篇博文，或直接将公告发布到项目的邮件列表中。
在公告中需要说明这个项目有什么用，是否向后兼容，并给出更新日志的链接。
5. 项目状态标签有些项目很长时间一直使用相同的版本号，比如1.1.0，而项目一直在改进。如果这是一个开发版本，你也需要通过标签来说明项目所处的开发阶段。比如：
- 1.1.0.pre1
- 1.1.0-alpha1
- 1.1.0-SNAPSHOT
总之，你要确保项目有一个严格的版本命名规划。
四、使用GitHub在GitHub上，你可以很容易地做下面的事情：
- 发布你的项目
- 浏览和搜索代码
- 专注于项目issues
- 参与贡献，合并用户的贡献
五、确保有一个为用户提供支持的地方如果你的项目达到一定的普及程度，你就会不断收到用户的提问。你需要有一个收集和回答用户提问的地方，比如论坛、邮件列表等。只要有一个交流的地方，用户也可以彼此提供帮助。久而久之，就会形成一个很不错的社区。
六、项目传递不排除这种情况——你可能会对项目维护失去兴趣，或者你换了一个新工作不再使用当前的项目了。你可以在邮件列表上公布，让其他开发者接管你的项目。在Github上项目所有权转移会更容易，尤其是在别人为你的项目引入了新功能后。
无论如何，不要让项目死掉。
七、总结总之，在你打算发布开源产品时，请确保它有：
- 清晰的依赖/安装说明
- 至少有一个简短的文档/指南
- 库中包含更改日志和相关标签
- 一些关于支持语言、运行环境、工具版本、项目成熟度的信息
- 邮件列表，供用户提问、相互帮助
八、最后总之，要想让你的开源项目“发扬光大”，首先应该让它对用户更友好。除了项目文档外，其他事情花费不了多长时间。
先点个赞，题主看起来有大将风范 。
大概看了一下，抽象程度还太低，暴露了太多接口了，
建议1，首页的demo换一个，改成面向策略开发人员，而不是交易通道开发人员，目标人群很重要。
建议2，期货端ctp暂时够用了，很通用满足很多人了。
但股票端lts太小众，而且华宝太小家子气成不了大气候(客观吐槽)，需要开发更多的股票broker，基础设施有了才能更好吸引人。
保持关注，找机会提交代码！
想到啥说啥:
- 还是用Github好，受众会广一点（科学上网对程序员就不是个事啊）。最好文档准备中英文；这样受众更多。
- 文档在README里面放链接，可以不限于放在github的wiki里面。文档写得好才会让开发人员感兴趣，让用户喜欢用。
- 开源本身是没有功利性质的，开源社区也不是你指挥其他人去做事情。
- 大部分情况是这样的：有人在Github看到你的项目觉得不错，但是有些地方自己觉得不爽，而且还想写代码。那么基本会fork一个，commit后发起pull request，或者不发pull request。。
- 这样慢慢积累长期贡献代码的核心成员。而不是先在网上号召一堆人去做。你说他核心，他不写代码，最多也就是个友情支持。
感觉任务分派模式不好，如果是没有酬劳，感觉要是有人跳票（毕竟也不能保证他的代码风格很好，注释很完备），那么很容易就卡住；而且代码的质量其实也无法保证。
喜欢社区或者 news letter 之类的方式，或者固定的一些维护人员这种、
代码托管平台肯定是要的，但是开放式的平台就感觉意义不是很大，毕竟不是那种公众性质闹着玩的东西。因为在开放式平台，权限是个很麻烦的东西，毕竟如果任何人都可以上来改一下代码，有时候会很乱的。除非弄很多 branch 然后花很多时间 merge。。。
个人感觉：最佳的办法是，有人先做好底层框架，然后上层都用组件的方式来做，大家可以做一些小组件，或者更新一些小组件，这种开发模式可能更好一些。
关注中。只有一个问题。量化交易对于延迟的要求是苛刻的，就算是低频交易，相信对冲也是比较重要吧，对冲缺腿或者滑点了都是直接损失啊。只限制于单边恐怕太狭隘了点。
如果是做策略开发，重要的事情读三遍：重心放在回测引擎。
模拟成交价格靠下一秒quote还是bar？还是trade？那时的流动性跟得上？随机滑点设置要不要？最差价格成交要不要？
说实话，感觉啥也没写呀。。就封装了两个发单api。。
而且量化本来就是anti-open source的，最后你搞出来这些东西也就是自己玩玩，没什么实际意义。
还不如学学AQR写个pandas这种粗糙但是灵活的库。
个人感觉用python研究和构建策略还是很好的，至于交易方面，也许高频交易有scala等可以用，但是对实时性要求不高的很多地方，python交易平台是很好的选择。其实ib也有python的接口。
但是从定位上来讲，感觉能制作一个很好的接口就可以了。GUI界面的交易系统工作量太大，也许专门开一个开源项目来做？
作为新手我就提一个问题，华宝证券API是不是只支持Windows平台？那用Mac的人怎么办哟。
知识管理可以使用问答社区的形式，使用wecenter深度定制:
举例:
http://elasticsearch.cn http://dockerone.io
