基于open source的咨询业

阅读更多

    今天终于买了那本经典之作《J2EE Development without EJB》，读到26页，就忍不住要写点东西了。书真不错，是我看到的比较少有的佳作，而且JavaEye翻译的也很到位，不枉我经常光顾他们的论坛。第26页的内容让我想到了一种商机，基于open source开发工具的服务，我感觉这是一种国内软件业企业非常需要的业务。

        Rod Johnson（他竟然是一个音乐学博士，惊奇ing）告诉我们，在J2EE without EJB的时代，仅仅依靠众多open source project所提供的功能已经完全能够开发企业级应用了。这对于中小软件企业绝对是一个福音，显然，一旦省略了购买J2EE应用服务器产品的费用，开发和实施的成本可以降低很多。但是这样做对于应用软件提供商又是一种挑战：在开发周期紧张的前提下，用很短的时间把基于open source的开发环境，运行环境（应用服务器），测试环境和软件配置管理工具（CVS，SVN，Bugzilla等等）及时部署到位，在这些环境都是基于open source，而开发团队新手又比较多的条件下，对项目经理是一个极大的挑战。以我加入IBM之前的公司工作的经验，我感觉这样实施下来困难是不小的。测试组和开发组的连动，Build team的建立，都需要不小的力量。实施之后需要把实施经验，工作流程积累成文档，也需要专门的努力。这样，就需要一种针对软件公司内部建设的咨询业，为软件公司提供针对基于open source开发过程的咨询服务。

    建立这样一个咨询公司，需要这样两种人：咨询师和技术专家。首先咨询师走访客户，根据客户的项目特点，团队架构帮助客户制定一份详尽的实施计划，包括团队的构建（开发，测试，软件配置管理），每个团队所使用的开发工具的确定和实施，并制定日常工作流程。然后，根据项目特点，咨询师选择合适的技术专家帮助客户建立一个和项目尽量接近的应用模板，咨询公司应该尽量积累这样的应用模板以便用尽量快的速度帮助客户建立这样的模板。模板包括：值得学习的应用程序代码，配置脚本，build脚本，和各级测试用例。在项目进行过程中，咨询公司可以提供技术咨询，比如编写复杂的配置脚本等等。咨询公司的任务应该仅局限于软件开发过程和支持工具，而不去干涉业务。这样双方就没有任何特殊利益上的冲突了。

    当open source成熟并且得到多数公司接受之后，这会不会是我们的一个归宿？