dotProject

The core dotProject development team is taking a rather controversial direction in its future development path, and the fallout from this prompted me to look at some of the ideas behind the controversy.

Business struggles with Open Source. It has a fraught relationship. Ask any business in the Open Source arena. From the big boys down to the one-person consulting shop, there are always two sides to the business-FOSS (Free and Open Source Software) nexus.

Partly this is because there tends to be a glaring disparity between the goals of business and FOSS. Business is there to generate money. FOSS is by its nature free to use, and distribute. There is no denying the two can learn to live together, and there should be no reason for them not to, but old habits on both sides can make the ride a difficult one.

I guess at this point I should declare my personal position on all this. I currently work for a large, worldwide FOSS company, and have been a contract programmer for more than 20 years. I passionately believe in FOSS, but my background is in the conventional software business. So I feel I have the ability to see both sides of the situation. My history goes back even before Linux, having had a bug fix incorporated into a commercial UNIX release, so my contributing back is not new.

Contributing back is the core of the way business and FOSS can work effectively together. FOSS offers business a cheap way to get product to market, or to provide cost-effective solutions to your customers. But with that comes a responsibility to understand FOSS and to contribute back. The cost of FOSS is in contributing to its success. Far too many businesses see this only as reporting bugs and asking for features that their particular clients require, regardless of how well received those features are to the rest of the user base, or to the core aims of the project.

If you have gotten this far you can probably tell where I am heading. At dotProject HQ we found that we were hitting our heads against brick walls in trying to get our vision for dotProject realised. It seemed like nobody was willing to grasp the nettle and take on the core infrastructure issues that we had. As a result the code was becoming increasingly difficult to maintain as "features" were being added without really making the necessary changes to the underlying structure to ensure their success. Bug counts were rising and the core team was spending far more time fixing bugs than getting any real work done. Something was wrong, and we needed to figure it out and fix it.

To me it was obvious. The core code wasn't up to the task. We needed to fix dP from the inside out. We needed to make it easier to build a new release, and to keep the bug count down when new features were added. We needed to think of the future and build to that, rather than thinking of the past and hobbling ourselves to that. More, we needed to make it easier for others to be able to extend the functionality of dotProject without having to hack the core code. And here was where we hit pushback.

At first I couldn't understand why there was such a bad reaction to something that would improve the ability for dotProject to reach its stated goals and to make it easier to integrate and extend. But looking at those that were the loudest in their criticisms I found something interesting. Business interests. The most vocal critics all had businesses that in part depended on dotProject consulting and customisation. So what, I hear you ask? Aren't they going to be the ones that benefit the most from such a move? You would have thought so, but think about it from their point of view.

If you had built certain customisations into dotProject based on the current core, and you wanted to make sure your work was protected (because you don't really want to contribute that code back, otherwise your competitive edge will be eroded), you don't want to see the core code changed in a way that would mean you will either need to refactor your code (costing you time and money) or your customer finding that the core product now provides them with the functionality they came to you for in the first place (costing you business and money).

Now I don't for one minute believe that these ideas are in the front of the minds of those pushing back. I believe that they are trying to see things in terms of what is best for the project, and certainly their arguments only tangentially approach these issues. I do believe, however, that in the back of their minds these niggling doubts are there, and are affecting their ability to see what is truly best for the project.

I don't claim to be omniscient, and it may be that our decision is the wrong one. I don't think so, but then again the FOSS arena allows for that. If we fail then another project will fill the void. But what I do know is that we are on the cusp of a great moment in the project. We had fallen behind the times and now we have the chance to make a leap forward that has meant there is now new enthusiasm in the core group and the new framework is already actively being developed.

So it is onward and upward. Rest assured if you have data in dotProject 2.x you will be able to migrate to the new code.