If you work with software this is a quite important statement. Read it carefully and think about it. I believe these issues are also true if one wishes to deliver a "solution platform" rather than an application. I also have a prejudice that the same designs that enable an open source or platfoorm approach may also allow long term software growth and evolution -- but I have no proof points for that prejudice. In contrast, Kapor has lots of proof points:
... There are advantages to going open source as well as challenges. In some cases it may even be necessary to forestall a competitive threat, i.e., do it before it is done to you. When I see businesses whose strategies involve defending a class of business model which is simply going to be obsolete going forward, my heart sinks about all the wasted effort.
Caveat altert: In a transitional era like the one we are in now, it is notable that it's harder to convert a code base developed in a proprietary context to be open source than it is to start from scratch for the same reason renovating a house completely is harder than new construction. Trust me if you haven't been through this. I have. This is one of the reasons it took seven years from the day Netscape announced it was going to open source the Mozilla browser to get to Firefox 1.0.
It typically requires a complete overhaul of the code and the development process, which is much harder than starting from scratch. Typically, the existing code base is not one which is amenable to community development. There is major code re-factoring and rewriting to be done, rethinking and reworking of API's, switching to open standards, and changing of the tool set to use transparent, community-oriented tools for source code management, issue and bug tracking, build status, knowledge base, and synchronous messaging.
No comments:
Post a Comment