dotProject

I'm often amused at the store people put in statistics. Forum post counts, bug counts, code commits, even lines of code are often touted as being indicative of some worth. The trouble is they are all very misleading. And what does it mean anyway?

Recently over at the dotProject forums we made a few changes. Probably the most important one, and one that is already having benefits is to search for posts matching a new posts subject matter. Why has this been of benefit? When a new user comes to the forums, they want to get their questions answered and if they don't see a similar thread in the index page for a forum, they post their question without searching further. When they do this the forum supporters need to respond to this in some way, upping their post count in the meantime even if it is just to point them to a similar post.

Now when a user posts, they get a list of similar threads. We are already seeing people looking at those threads before they post, reducing the number of times we have to answer the same question. Our post counts are not being boosted by one-liner 'have you looked at this thread' answers, but by the same token users are getting a better service and we now have the time to answer truly new questions and the much more important task of working on the code.

It is much the same with other statistics like code commits. Sure, I have one of those widgets that tell people how many commits I've done, but does it really mean anything? Not much. If I wanted to I could boost that by committing one file at a time, rather than a bunch of files in a related commit, something I have seen done in other projects. It also doesn't really measure why the commits were made. If I made a commit and realised that I'd screwed up and then committed the correct fix then I look better on raw numbers than if I'd got it right in the first place.

The worth of a programmer is something that is hard to quantify, but I guess it comes down to how your peers perceive you. After all, if you find that your peers enjoy working with you and respect you, what does it matter what some nefarious statistics show?

The worth of a non-programmer in a project (and lets face it, it takes much more than good code to make a good project) is even harder to quantify as currently there is very little in the way of statistics to even identify them as valuable member of the team. Again, it comes down to your peers. Not to a dodgy number.

Since dotProject was first registered on SourceForge on 1st March 2001, we have used their CVS system for managing the code. Today we moved this across to Subversion (SVN).

There are a number of reasons behind the move and behind the timing. Since we are going to start on a major revamp of code we really need to make sure our tools are up to the task. Subversion offers a number of improvements over CVS, and most of the developers already use SVN for other projects, so the move makes sense there.

We hope that this doesn't cause anyone any issues, and we have altered the documentation to detail the new connection requirements.

The nightly snapshots will continue to be prepared and their structure and usage will not change.

In addition we now have a mailing list for commits to the code repository, so you can keep track of changes (if you are that way inclined).

It has been a bit of a rocky road but we have now sorted out all of the insanity in the 2.1 release and have a stable 2.1.1 release for your pleasure.

If you installed 2.1 or any of the CVS snapshots since, you should immediately upgrade to 2.1.1 as there are a number of security related issues. One of immediate concern was a fix in 2.1 to a widely reported vulnerability in the companies module that was reversed in the days following the release so affects all snapshots since that time until the 2.1.1 release.

During the cleanup afterwards we also found further evidence of sloppiness in added fixes that broke other issues, added fixes that were not thought through and therefore made areas inconsistent and other issues of a similar ilk. Suffice it to say that the core and maintenance teams will no longer have to clean up after some of our less assiduous developers.

With thanks to DeBortoli Wines here in Australia for their sponsorship of the task, we are able to provide a 2.x compatible / offline dotProject User Manual. You can find the PDF's packaged into a single file at:

Sourceforge dotProject 2.x Manuals

They are in a different structure from the main documentation site at: http://docs.dotproject.net

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.