践出真知。提高技术的关键是作出一些东西。看起来有用，看起来伟大的产品都是你我能做出来的。
偶结合自己近来的一些想法，提出几个项目，供大家参考讨论。感兴趣的一起探讨探讨。有时间的兄弟姐妹们可以尝试写一写。
这些项目有这些特点：（1）有用；（2）可行；（3）有意思；（4）做好了都能作大；（5）适合.net开发；（6）可出名（开源）或可卖钱（不开源）；（7）和asp.net无关；
一，geotools的.net版
GIS会越来越火。目前GIS中间件都是数万到数十万人民币之间。但开源2D GIS技术现在已经比较成熟了。数据库有postgresql/postgis，Server端有c写的mapserver和java写的 geotools。mapserver的缺点就是开发和扩展不如geotools灵活，geotools的缺点就是性能。用.net来改写 geotools比较有意义，难度不大。涉及到的内容主要是OGC规范，多维索引，缓存等技术。写好后应该不比国内几万块钱的GIS差。轻量一点的是写一个map控件，支持小型地图，支持有限的数据各式，适用于小型gis应用。
gis的原理很简单，找本书看看就行了。英文好的，直接看OGC规范，然后对照geotools源代码，就可以开写了。sourceforge上有一个 geotools.net项目，那个不是geotools的.net版本。只是geotools中用到的java拓扑套件JTS的.net实现.
预计规模：
GIS控件：50-100个类；
geotools的.net版：500-1000个类；
偶在sourceforge上申请了一个项目：agilegis，本来想写geotools的.net版的。没业余时间。有人写的话偶把这个让给他。
二，visio的.net版
visio好用但是也挺贵的。看过sourceforge上Netron Graphic Library的人可能会觉得，有了Netron Graphic Library，要写一个有visio 80%功能的东西不会很难。写UML设计软件，都不是很难。你要是写出一个java的这东西，永中可能会来要。不过有一点，这东西写出来没什么难度，要写得好用，就有很大的难度了。
预计代码规模：300-1000个类
三，luma qq的.net版
luma qq是luma用java写的qq client。有兴趣的人可把它用.net改写。这一块是值得做的，拿电话为例，我们不单需要电话机，还需要交换机，还需要客服中心。随着企业业务纷纷向网上迁移，一个集成Web，IM，音频，视频，数据库，知识管理系统的企业门户2.0应该是需要的。这一块难度也不算很大，不过开发量较大。
四，web挖掘基础件
主要的可能就是spider，parser，中文分词，索引技术，文本分类，自动排重。这些东西，单独写出来不算难，写好有点难。不过对一般应用来说，写得过得去就行了。spider有很多。parser主要是两种类型的，一种是把页面解析成xml文件，一种是解析成对象。中文分词写起来也简单，关键是词库的维护。索引和文本分类偶还没写过，但也没有什么难度。
目前java那边的东西比较多，.net还比较少。象字符串测量，这些东西，写起来应该很有意思的。
我觉得需要解决的一个问题就是网页的重复抓取，假设1000个人抓某一个网站，一天抓一次，那么100天就要抓100000人次了。这样会给别人带来很大的流量压力。如何使只抓更新的数据，只抓一次。这可能得认真设计，得对网页行为建模，用好hash，甚至引入一套p2p机制。
可能的用途：大型网站的自身管理；行业用户的网站订阅（比如订阅10000个左右的网站，每天及时报告更新，用户之间交换订阅，订阅别人的订阅......可参考Nullgate在zixia bbs上关于p2pBBS的一些文章）；数据采集（全自动的不好写啊！）
五，web实体与行为挖掘
论坛，bbs 上的用户，blog的主人，IM的ID，网络游戏的ID都是虚拟实体。找到虚拟实体，这些虚拟实体有什么样的特征，有什么样的关联，有什么样的特点是一个挺有趣的东西。进一步，由这些实体实现的行为有什么样的特征。举例子说，网络现象分析--一个有50万人阅读的帖子存在什么规律。需求挖掘--现实中人的需求如何通过网络挖掘出来，如，在XX地的青年对XX有什么样的要求？
采用的工具基本上是四中的东东，但是需要特殊的算法和特殊的模型。做这个需要有很强的建模能力。
六，高性能.net服务器端开发
对实时性要求不是很高的高性能服务器端开发。高性能Server端图形应用开发（如GIS应用），3D应用，这些传统C++的优势领域，用C# + C（<1%的代码用C写）到底能不能替代？如果能的话，那实在是太好了。随着未来多核处理器的普及，内存价格下降，.net的优势越来越大。研究研究未来系统软件的架构。
七，代码阅读
代码阅读是提高水平的捷径。阅读代码，感觉有兴趣的写个case，交流交流，很好玩的。比天天捣鼓模式有趣多了。
组织建议：
（1）开源，但有不超过3个人的控制者，控制结构和功能
（2）迭代开发，从最小的来。拿第一个举例，写一个GIS控件用不了多长时间。