其它开发组是基础库开发组的用户，上级是基础库开发组的客户。基础库开发组和其它开发组不是协作关系，因为其它开发组的成果不影响基础库开发组的质量。
推动基础类库，而不是拉动基础类库。拉动基础类库，至少会有如下几个问题：
一，没人能100%正确，我自然也是。
二，就算我是正确的，我和使用者的思维不一定是同一层次。水平高的认为简单无用，刚入门的认为太复杂。
三，拉动不容易尊重用户的使用习惯。想教育用户的人，往往会被用户教育。除非垄断产品，否则别想改变用户的习惯；就算是垄断产品，强行改变用户习惯，也会让用户愤怒。
四，人天生是扛精，同样的观点，如果是自己提出的，更高的几率支持；如果是别人提出的，更高的几率反对。
分五个阶段：
一，熟悉同事。收集大家的库、类、函数，整理并推广公共库。推广是主要工作。这是长期的过程。
二，熟悉代码。协助一个项目，收集好的东西，提一些书面的建议。一般2到4周。
三，收集天使用户，种子用户。主导一个项目或虚拟项目，优化到用户、绝大部分程序员满意，大部程序员（种子用户）比较满意，少数程序员（天使用户）很满意。一到3个月。
四，完成框架。在第三阶段的基础上，完成一个框架，并根据程序员的建议修改。一个月左右。
五，验证、完善框架、培养人才。和至少一个程序员协作，利用新框架完成一个项目。等项目基本完成后，我退出此项目，进入新项目。一到2个月一项目。
不同类型的项目，可能使用不同的框架。一个类型一类型来。 第一个框架建议最简单（万事开头难），第二个框架用得最多的，第三个框架最难的。
工作内容（减少重复造轮子）：
1，抽取已经封装的函数或类，整理文档和测试用例。
2，发现多次重复的代码，列出可能封装的函数和类供大家选择。
3，根据选择的结果封装类和函数。
4，完成相关相关类和函数的自动化测试。
5，反复测试可能的缺陷（尤其崩溃），避免坑惨调用者。
6，请不忙的同事，进行评审。有则改之，无则加勉。反复修改，直到大家满意。
7，查阅代码，看此函数可以代替那些代码。和作者沟通，告诉他那些代码可以直接用封装的类代替，如何代替。由作者自己决定是否代替，如果代替出问题及时反馈给我，我负责解决。
我以前看过一本书，新发明是否存活，和能否让用户爽有关，能否提高效率反而是次要的。所以，刚开始推广公开库的时候，不能因为提高效率而让用户不爽。推广结束，提高效率才是重要的。不要影响其他开发组程序员手头的工作，这是作死之路。
拆掉一个可用但不完美的房子，必定弄得天怒人怨，众口难调耳。每次拆掉几块坏了的砖，换上新砖，只有人赞成，无人反对。等砖换光了，问题依然存在，这时大家的意见就统一了：框架的问题。一般而言，换掉部分砖，大家的意见就统一了：每次更换都有少量好处。少量好处证明优化的方向完全正确，但无法从根本上解决问题。
如果把基础类库当成一个产品，程序员是用户，公司是客户。开发过程中，用户重要，用户搞几个小动作，就让开发成本翻倍；开发的结果，客户重要，付款、评价权在客户手中。所以整个开发过程，用户的重要性不断降低，客户的重要性不断升高。显然，第一阶段以用户最强的需求开始。我估计：某些程序员对驻场深恶痛绝，此乃基础库开发组的天然同盟。如果找不到此类同盟，试图寻找其他类型的同盟。