FDPM Maintainer

Since I'm ducking out of the FDPM project ... the new maintainer would have to do everything. There wasn't a lot of outside interest in helping out with FDPM, although there are certainly more people on the fd-dev list (see www.freedos.org/freedos/join) who are discussing writing a new install program. FDPM should be a part of that, I think.

Anyway, since there wasn't a lot of outside interest, Andy & I were pretty much the only ones to work on the code. So as the new maintainer, you should be prepared for that. I've left notes on the web page at fdpm.sourceforge.net that describe what I was planning to do. The major work is going to be figuring out why the db lib doesn't work ... or just replace it, I guess.

Speaking more generally ... I have powerpoint (and openoffice) slides at www.freedos.org/news/vtntug that talk about what qualities a successful open source software project should have. It also describes what a project maintainer will have to do. Basically, you play "gatekeeper" to the code. Expect people to submit code, and your job would be to merge their code contributions into the FDPM code. If someone contributes regularly, and you like their work, then you grant them checkin rights to the CVS repository. You do all that by making them a "manager" for FDPM in the Sourceforge system.

There's a bug tracking system on Sourceforge, but I haven't used it. You'd probably want to start a bug list there, so you can track bugs (either ones that you enter, to help keep track of where you are ... or ones that others submit, as they find new bugs.)

A maintainer also plays cheerleader, at least to a certain extent. You'll be the one to post encouraging notes on the project web site, to help get people interested in your project so they can help out. A big part of that will be contributing to the fd-dev mailing list, and see if any of the people there who've been discussing writing a new FreeDOS Install Program would be interested in using & contributing to the FDPM system. I think anyone who writes a FreeDOS installer needs to look seriously at FDPM. When I was the Install program maintainer, I contributed to FDPM because I wanted to add some kind of package support to the installer. When I stopped being involved with the Install program, I kind of dropped interest in keeping FDPM updated.

And of course, a maintainer is always responsible for making new releases of the software. Release early, release often. There will be bugs in your releases, and that's okay. Just document what bugs you know about, and people will be fine with that. People just need to see regular updates to an open source software project if they want to contribute to it. If the version they have gets out of date because bugs are fixes but new versions (with those bug fixes) aren't released, then people stop using the software.

If becoming the FDPM interests you, let me know and I'll help get you set up as the new owner of the FDPM project in Sourceforge.