OSS from Non-Developers for Non-Developers?

chrisatslashdot asks: "By training and title I am a Mechanical Engineer. I have never been involved with any serious software development although I am competent to develop quality code. Because the company that I work for will not purchase a canned software package, I am developing a web based CMMS (Computerized Maintenance Management System). I GPLed the project and put it on SourceForge hoping to help other people in my situation. The project is attracting much more attention than I anticipated. I have observed the development of many OSS projects but almost all of these have been by developers, targeted to developers. So what advice can you give a novice software developer on managing an open source project? What dangers and pitfalls await me? How does one foster more developer involvement? What resources should I exploit to keep from screwing this project up?"

Comments

TODO immediately

[Dancin_Santa]

1. If you have a mailing list, find one or two developers or power users who you find particularly astute and sociable and ask them to become your program managers.

2. If you do not have a mailing list, start one.

3. Maintain control over the project at all cost by checking in all changes to the tree yourself and not allowing others to do so. If they want to fork the tree, it's up to them.

4. Once #3 becomes too much work, ask one of the people you selected in #1 to become the project Boss and take over the responsibilities in #3.

5. Keep a close eye on the project, even if you are no longer the Boss. Your initiative in creating the project will not go unnoticed, so your voice will have a lot of weight in settling any important project directional matters.

6. Require all patch copyrights be signed over to you or whatever entity you establish as the owner of the copyright to this product. (this will come in handy later when you turn around and make the project closed and screw all your non-paying customers) Ask for an affidavit for every patch proffered.

7. Don't be an ass

8. Don't be an ass

9. Don't be an ass

10. Don't be an ass

Communication

[XBL]

I know that it becomes very tiresome to reply to e-mails of people asking the same questions, wanting to help (with no real skills), and requesting features. However, you must do your best to efficiently handle all of the communication a project needs to survive.

Maybe you could set up times for people to chat (you included), and try to maintain an active and coherent mailing list. Instant messaging is also efficient.

Also, prepare to be disappointed over and over again. People have good intention in helping out on these projects, but I bet well over 50% of the stuff that people say they will do never happens. I am very guilty of this myself.

Finally, be sure to do *real* testing on the software, and try to maintain some sort of metrics. Ask people how much time they are spending on the project, and see if there is anything you can do to help them manage their time better.

BTW, the best project management tool I have every used is Bugzilla. Use it, it helps a lot with dealing with the details of development, and actual bugs :-)

Hmmm.

[The Cydonian]

I don't know if you realise this, but just to point out:-

a) There are MANY competent OSS programmers who don't have a CS degree behind them. I'm a subscriber to a GPL-ed software's mailing list, and the resident guru in that list is actually a political science professor from somewhere in the Mid-West; he's the sort of guy who has a (correct, insightful) answer to just about anything regarding the said software. And his case is not alone in the OSS world; RMS, for another, comes to my mind (he has a BS in Physics from Harvard, if I remember correctly).

b), Your questions are mostly of the non-technical kind; you seem to be more worried about interaction and growth issues, than technical competency.

So the good news:- congratulations, you've got what it takes!

You've obviously got the enthusiasm (otherwise you won't Ask Slashdot, so to speak), you've got a base of developers who are keen to contribute, and finally, you've got the technical capability to understand and, perhaps, guide the project as it grows.

I won't answer your questions directly, however, I'm sure there are other even more experienced programmers and lead developers here who can give you a better reponse. In fact, I think your questions are very legitimate and hit close to the heart, am planning to GPL a project as soon as it hits a certain code threshold, so will keenly follow the ensuing discussion.