当开始建设社区的时候，你需要拿出一个像样的承诺。程序此时并不需要特别好，它可以简陋、有错、不完整，文档可以少得可怜。但它至少要做到：(a)能运行，(b)让潜在的合作开发者相信，这个软件在可预见的未来，能演变成一个非常棒的东西 –《大教堂与集市》

目前edx的复杂度很大程度影响了它在国内的使用和推广。

我平时收到的国内折腾edX的团队发来的邮件中，大多都对此存在抱怨。

国内开发者聚集之处，每天翻来覆去的谈论的，也都是安装啦部署啦协作啦代码管理啦这些问题，的确每一个问题都让人头疼。而每一个入门者，在最初阶段又都得面对它们。

这道烦人的门槛并不低。

上上周，去北京讨论了一下关于组织国内开发者会议的事。（初步定在暑期）

同@MT聊到建立国内社区的可能性，以及社区一旦形成，致力于去解决哪些问题，本土化自然是核心，这里指广义的本土化，而不仅仅是汉化这种初步的，我们希望通过开发者会议（会邀请教育界的人士），收集国内用户都有哪些需求和痛点，然后将其作为之后社区努力的方向之一

目前已在edx-platform的wiki里列出了中国区Open edX使用者及开发者关注的一些问题，并整理开发相关中文资源：localization and development in china

edx的复杂度，开发者们有目共睹。我相信docker是推广edx和驯服这些复杂度的利器。

我最近在使用docker做实验，目前已经build出了birch版本，已提交到docker hub，完善后（汉化，自适应主题，可用性优化等），准备发布出来。接下来将尝试基于docker的多容器以及分布式，此后将尝试使用docker容器做数据分析，而不打算采用amazon。

也建议采用docker来构建社区维护的基础版 ：）

我相信用docker折腾edx能简化以下问题：

  • 开发：使用docker将获得以下好处
    • 轻量化，docker比virtualbox要节约内存得多，跑edx的速度也快得多
    • 协作变得容易，团队成员之间的协作开发模式，变得与git相似，环境和开发成果的同步变得容易
    • 开发成果很容易直接部署到生产环境，几乎就是一键式的
  • 部署：部署变得一键式，docker pull下来就可以run了。甚至可以据此可以构建云平台，提供云服务
  • 社区构建：有一个可用的版本可以被社区环绕
  • 升级：集中化管理。将复杂度转移给社区，只要针对一个image进行升级，社区成员可以共享成果，各自去pull新版本就行。需要单独处理的，只有自己的数据，大大降低了升级难度。一些烦人的问题，诸如国外网络之类的，只需要被解决一次就行
  • insights ：分析平台成为单独的组件，封装在docker中,只对外暴露出接口（端口）
  • 分布式：采用多容器部署，分离出数据库之类的组件，之后这些组件可以轻易地分布到不同机器上