程序员的全新全新兼职工作平台的设想。

今天看到@金色海洋的《程序员的全新的兼职工作方式》一文，勾起了我一直期望实现的一个平台的想法。基于我这个人“只想不干”的特性，看来我实现和完善这个想法的可能性也很低了。这里发布出来，也许能够为别人带来好的启发。

我的想法，就是建立一个《软件开发项目承接平台》。任何人都可以在这个平台上注册并发布自己的需求。任何人都可以在这个平台上注册并实现别人的需求。完成交易。听起来是不是和现在已有的很多兼职网站一样？听我细细表来。

这个网站的设想已经很久（有一年多了吧）。但是，有一个问题我没有像透彻，也相信这些网站没有做到。我觉得那才是该平台最核心的问题。我认为如果哪个网站可以解决了这个问题。那么，这个网站就真的可以把这个长尾做大做强。这个问题就是：

交易双方的认证

目前的网站，都只是在做一个中介，交易的风险都由交易双方承担。网站最多对交易双方进行一些简单的认证，比如：实名制，天知道现在市面上有多少假身份证；比如：保证金，这一点又使长尾的大半截被砍掉了。从Coder方面来看，很多认证又导致了老Coder积累的信誉对新Coder的不公平。

因此，我认为，合理并有效的解决了交易双方的认证（或保证）才能够真正将长尾发挥到极致。

那我来说说我设想中的解决方案：

1. 建立一套开发框架，这套框架实现了如下的功能：

a) 这套框架实现了版权保护的功能。从而确保甲方不能够在交易未完成的情况下使用产品。

   版权保护应该提供“试用版”，“限制安装次数版”，“限制使用时间版”等多种不同的方式供交易双方在交易前进行选择。

b) 这套框架对大多数敏感操作进行了限制。从而确保乙方不能够在产品中预留后门。

2. 建立代码版本库

乙方的所有产出都必须提交到版本库中。从而保证交易过程中甲方的权益获得足够的保证。但是，在交易完成前，甲方是没有权利访问代码库的。交易开始时，可以选择，最终代码库是否提供甲方访问的权限，也就是源代码是否作为交易的一部分最终卖给甲方。

3. 建立Build服务器，甲方获得的产品是由我们的Build服务器来生成的。

甲方不应该直接从乙方那里获得编译后的产品，因为这样我们无法保证双方的权利。甲方获得的试用版产品（包括最终的正式版产品）都是通过我们自己的Build服务器编译产生的。这样，既可以保证框架中的版权保护功能正确的开启。同时，可以避免乙方在产品中预留后门。当交易完成时，我们的Build服务器会根据交易双方事先的约定，产生一个特定保护方式的版本给甲方。

4. 建立预支付平台

甲方需要预支付开发费用，该费用会被我们托管。当交易完成后，将交易费用扣除手续费后打入乙方的账户。这一点基本和淘宝目前的模式一致。很成熟了。

5. 交易仲裁

当交易双方对交易有异议时，可以申请交易仲裁机构进行仲裁。双方需要提供对自己有利的证据来证明自己完成了交易中应该承担的责任。这一点很难把握。是一个我目前没有考虑透彻的点。但是，也许实施起来比我想象的乐观。

看到这里，相信各位Coder都已经抓住了我的七寸。都很敏锐的发现了我这个方案中最大的软肋——开发框架。接下来我们详细的讨论这套框架的可行性：

1. 版权保护

我相信目前技术上不存在完美的版权保护方案，但是，请记住，我们面向的是长尾市场。这块市场的特点是“重复性较低”，也就是说，需求千差万别。针对这个人的需求的实现碰到另外一个需求一致的人的几率很低。因此，投入大的技术力量进行破解的成本可能不低于自己实现需求的成本。因此，我认为一些简单的版权保护和认证机制就可以支撑起这个平台的运作了。

2. 权限限制

对敏感资源的访问限制是确保乙方不在产品代码中埋逻辑炸弹的重要途径。目前Silverlight/Flash/纯Web 对安全性问题已经有相对成熟的方案。也许，我们可以要求应用程序必须是基于silverlight/flash/纯Web的。

通过我们自己的Build服务器进行构建过程，我们确保产品代码中没有外来低安全性代码的干扰。

为了满足用户不同的需求，我们可能会为用户提供多个开发框架，其中部分框架没有这么高的安全性。从而满足一些上面的高安全性框架无法解决的问题。比如：开发人员不熟悉Silverlight，或者应用程序需要访问系统底层接口。这种情况下，我们就仅履行告知义务了，交易的风险只能由甲方自己承担了。

3. 反后门

因为源代码在我们的版本库中，并且版本库对提交的代码进行了一些限制（比如：命名规范，书写格式等），以提高代码的可读性。即使乙方在产品中留有逻辑开关，一般也可以通过阅读源代码将开关解除掉。当然，这个服务是收费的。

4. 第三方类库

原则上，我们不允许乙方使用第三方类库。因为我们的框架库中已经包含了大多数常见场景下需要的功能。如果确实需要第三方类库，我们只能行驶告知义务——也就是确保甲方知道此次交易中的风险。然后，让交易双方选择低安全性的框架了。随着平台的发展，我们可以逐渐的将一些开源类库引入到我们的系统中来。从而满足更多用户的需求。对于非开源的类库，我们也可以考虑提供一定的认证机制来降低交易双方的风险。

最后再说几个其它问题：

1. 验收测试

也许随着平台的发展，我们可以抽象出来一组验收测试用例。交易双方可以选择使用我们的验收测试用例。这个东西和前面所提到的框架的发展和成熟将会使我们的平台具有平台壁垒。从而阻止其它的公司进入这一块市场和我们竞争。因此，着两个东西是平台发展的重中之重。

2. 代码库的管理

对于每个Coder，我们会为他提供自己的代码库。这样，他可以在自己的多个项目之间共享代码。从而进一步的增加他对我们网站的依赖度和粘度。

3. 关于分包

我知道目前这一块市场中很大一部分其实是分包。也就是实际产品的运行平台等有很大的限制。这一部分也许能，也许不能纳入到我们的体系中来。是一个值得继续考虑的问题。

我放弃一切对本文中想法的权利，也不承担任何因本文而引发的责任。你可以出于任何原因和目的转载，修改本文或使用文中的想法，但是，不能在任何商业行为中使用我的名字。

当然，文字能够表达的内容很有限，我也欢迎任何人和我继续探讨这个想法的可行性，一起来完善这个想法。你可以在这里给我留言。或通过twitter（@colinhan，需要FQ）和我交流。

-------------------------------------------------

2009/08/25 更新：

我之所以提出这个想法，是因为我认为目前，软件开发方面有一个很大的长尾没有发掘出来。这个长尾就是非IT用户的IT需求。我在几年前曾经帮别人做过一个小软件（彩票选号的小工具）。对方就是一个不懂软件开发的人。但是，他有一个想法，期望找人帮他实现这个想法。我相信现实中很多这样的人。这些人不会像外包公司那样动扎出手上百万的项目。但是，这样的人却非常多。这些人就是定制软件开发市场的长尾。我想解决的也就是这样的需求。

另外，我不觉得网站的信用是一个很严重的问题。如果真的严重，也许我们可以卖给知名的大公司，百度，谷歌，淘宝，这样就可以部分的解决网站的信用问题。重要的是你解决了用户的需求，或者说你只要解决了甲方的核心需求，有甲方愿意来这里招标，其它的都不是问题。另外，维护自己的道德底线很重要。象腾讯，金山这样不维护自己道德底线的公司，出钱也不能卖的，卖给这些公司只会毁了这个平台。

这时候，我想起了一个关于是否应该将企业ERP搭建在云计算平台上的问题。很多人都说，“哪个公司能够愿意将自己的核心业务数据放在别人的服务器上。”，我记得一篇博客上说的就很好：“当年ERP不普及的时候，ERP是很多公司超越其他同行的法器，他们当然不愿意将ERP放在别人的服务器上。但是，现在是个企业就有ERP，ERP已经不再是他们商场制胜的法器了，放在云里，可以降低他的成本，他自然会选择了”。市场就是这样发展起来的。

最后，补充一点，使用支付宝进行交易是必然的。目前支付宝在国内的普及程度确实太高了。我可不打算自己重写一套交易系统。那个的水太深了，我相信我们没有经历完成的。我看到很多朋友在回复中指出了这一点。谢谢大家。