In his "CM: the Next Generation" series, Joe Farah gives us a glimpse into the trends that CM experts will need to tackle and master based upon industry trends and future technology challenges.
I don't really think so. It is a winner. We like to look at various open source tools and use them fairly heavily. But there are some aspects of open source development that I would like to consider from a management perspective. They deal with innovation and excellence; architecture and entrepreneurship.
If I'm looking for software that's going to meet a standard, I can't go wrong with open source. Maybe today it falls short, but as the momentum for a particular product development picks up, it will exceed competitive solutions. In the early 90s it seemed to be a risk to go with the GNU C/C++ compilers. It quickly became apparent, though, that Gnu would set the standard for C/C++, for Make, etc. We hedged our bets and eventually went over to GNU.
Then we started looking at other things. What about Open Office? Great compatibility, but perhaps it could use some downsizing. Not to worry, right? It's open, we could do the downsizing ourselves if necessary. Well, no. Why? I find it's almost as big an investment to adapt open source code, as it is to write a separate application. Then there's trying to get the adaptations into the core of the development stream. Put the ideas out there in the form of feature requests and they will get picked up and implemented.
So what's the problem, you ask? Well, software is getting big and hard to manage. With so many hands in the pie, even if there's common ground on what should be part of the product, the architecture begins to suffer. There's no room for simplicity. There's little room for the orthoganal architecture that optimizes the results. Then there's momentum: just try to change the direction. The problem is that open source development is primarily a feature-driven exercise.
I know a lot of commercial endeavors are the same. In fact, Microsoft didn't excel because of its technology. There were better operating systems around, and even today I find it incredible that I can't do so many things that 30 years ago I could do with Unix, such as redirecting my display for a given application or resizing my "shell" window. So, commercial's not always better. But it could be.
With open source you may have a visionary, and even a vision, but it's hard to attain. With a focused drive to attain a vision, a commercial development effort can yield terrific results. That's how VNC came about. That's even how Unix came about. And it's great that open source was there to pick these both up when they were in danger of losing a marketing battle. But where has the little Unix kernel gone. Because there are Open tools, widgets, gadgets, you-name-it, they have been absorbed, not because of their simple design architecture, but because of their function, and perhaps their functional architecture. As a result, my Gigabyte-memory computer takes longer to boot up than did my 1MB Atari ST of 20 years ago. I could do word processing, desktop publishing, spreadsheets, games, etc. The network wasn't there yet, so it may be a bit unfair to compare.
So my first complaint is that it's hard to take a vision forward within an open source development framework.
Now let's get to the CM side of things. Open source means CVS. There are a lot of add-ons, as well, but the open source architecture will prevent CVS from really going places. Perhaps a next generation open source CM product will appear, though! So what's the difference between CVS and CM+, Accurev, MKS, etc.? CVS has established a framework that really won't be challenged by its development team. CM+ made some dramatic advances with allowing dedicated teams for dedicated periods of time and augment the vision.
Process workflow engine, dedicated effort. GUI generation engine, dedicated effort. Active workspace, dedicated effort. These are much harder to do in an open source community. You have to have a vision, battle it out with other visions, and sell it to the gatekeepers, etc., all across a global network of "owners". It's just easier to take many little steps. Put 100 new features on next year's model car, though, and you don't get a winner. You have to have the vision for where the car is going, work closely with others as to how to get there and then let the feature set fall out of this work. You can't just paste the features together to get a new model.