项目计划
klzgrad
先规范一下命名。西厢是对一套东西的一个总体称呼，其中张某（ZHANG）指使客户端能够直连标准服务端的模块，崔某（CUI）指使标准客户端能够直连客户端的模块，gfw是指对GFW的伪包指纹进行匹配识别的模块。张某和崔某在逻辑上是客户端与服务端关系的良好比喻。这个项目在google
code叫scholarzhang是因为最初只有张某这一个模块，这是一种legacy的状况。
首先作为开发者，对于这个项目，应该消除幻觉，着眼缺点。西厢的弱点在README.wiki的局限一节已经描述得比较清楚，主要是两种问题：不稳定和易变。不稳定可能造成在使用过程中可能出现连接失败的情况，易变可能造成GFW升级之后如果西厢不升级便无法使用。不稳定是由于张某和崔某实际上做的是通过协议hacking弥补GFW造成的破坏，要求一种RFC规定的理想状况，原理就是不稳定的；而西厢的原理部分所依赖的GFW指纹和漏洞机制是易变的，需要即时更新。因此，“没有银弹”，西厢也不是对GFW的银弹，我看到自由亚洲的报道夸大其事，我想开发者关注的应该是bug才对。
然后，我想各位应该对西厢的工作原理有所理解。用wireshark就可以看到西厢做了什么，背后的原理首先应该看RFC793和README.wiki引用的那篇论文，其次可以看gfw技术评论的几篇文章。如果还不明白，过一阵我再发一点资料出来。
然后就是关于西厢的开发。我想强调一下所谓alpha状态的含义，就是目前这个东西本身可以用，但是具有强烈的试验性，扩展、用户支持等等特性都是没有的。由于原开发者已经没有时间继续开发，因此直接把alpha版作为prototype放了出来，希望抛砖引玉。我觉得这个项目并非一个结构特别紧密的项目，因此分支也不一定要组织特别严密，各自为战也会不错。
关于西厢本体，我觉得它目前有几个任务：
1. 测试。特别需要进一步测试明了issue #13提出的不稳定的状况，这应该是当前影响用户体验的主要问题；
2. 打包。用户如果能够直接运行dpkg
-i之类的一行命令就安装完毕，这比自行编译会方便许多。注意到西厢目前涉及到内核模块编译，我建议在打包中采用dkms框架，可以良好处理内核版本不同的问题。比如debian的virtualbox-ose-dkms便采用了dkms框架；
3. 移植。BSD系列用ipfw，跟iptables不一样。windows就更不一样了。当然这是一个显然的问题。
不少人提出西厢的分支任务，希望改成用户态的。张某原来也是用户态的，最后进入内核的原因在WhyNetfilter.wiki里面说明了，总结一下就是：优雅；iptables/ipset带来的高可配置性；性能。当然这也是原开发者的一己之见，西厢计划本身对于衍生项目不会有任何限制。如果要移植或者要改成用户态，那么就应该把易变的那部分业务逻辑抽象出来单独维护，其余各部分采用这个。
关于项目组织。首先欢迎大家认领自己感兴趣的部分（回复中说明），需要committer权限的向代码库管理员提出即可。其次是希望大家独立，西厢计划不是NED资助的组织，不用对我们期待过高。西厢的原开发小组即将解散，我们仍然会继续在原理部分提供帮助，但是由于能力和时间有限，我们基本上不会参与接下来的实际开发和项目领导（当然需要有基本的控制以免意外），如果有同学项目管理经验丰富可以来带头。