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

One word

[Pyromage]

Care.

If you care about the project, you will do fine. The biggest problem is not technical. It is not of arguments, flames, and users. More commonly than any other reason for a project failing is that the author fails to maintain focus and follow-through.

It's *your* project. You keep it alive by making it the best, and keeping it that way.

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.

Some tips.

[Yaztromo]

My project recently celebrated its first year o being Open Source (http://www.jsyncmanager.org. While I've been working on this project for the last 6 years now, it's only been in the last year that I've had to deal with other people working with my code, and managing their efforts. A few things I've learned along the way which might be helpful:

• The people who work with you on your project are volunteers, so you have to treat them as such. Sometimes they'll have more important things to do than work on your project, which can, at times, make deadlines a difficult thing to enforce. It alos means you have to show appereciation for their efforts -- if they don;t feel they're getting something out of their time, they'll drop whatever they're working on and leave the project.
• Expect at least 75% of the people who offer to help to end up doing absolutely nothing. I've had lots of people with great ideas and apparant energy offer to help with my project. I'll take the time to get them setup with the various permissions and resources, and may then never hear from them again (some of the more polite ones will appologise for not being able to be active in the project). Don't take it personally -- when people aren;t getting paid, sometimes their excitement at joining an interesting project outweights their actual desire to do any work :).
• If someone leaves your project, regardles of wether they contributed anything or not, thank them for taking the time to join in the first place. Even non-contributors have their hearts in the right place.
• Try to build up a solid core of developers, and then delegate. If at all possible, put different people in charge of different areas, giving them as much creative control as possible. Make these people you "leiutenants". This is particularily important for those development areas you either aren;t good at, or simply aren't interested in.

  In my project, my core strengths are with the base synchronization protocol stack and engine -- the really low-level stuff. That's my domain. Some of the things that hold no interest to me include the user interface portions of the project. Thus, I put someone in charge of UI development, giving them full creative control (although I'n known to offer feedback :) ). I found someone who is an expert on UI design, and leave them to their task.

  Build a community, and build bridges to other development communities that may find your project useful in their own projects. You never know where it might take you, or who might discover your project through another project. The jSyncManager (my project), for example, has ties to the jUSB Project, and OpenOffice.org'q Glow Groupware Client. Scratch their backs, and they'll scratch yours (and if your project needs an open, platform-neutral Palm handheld data synchronization facility, let me know :) ).

• Become a shameless promoter of your project. Bring aboard someone who knows a thing or two about marketing. Write up press releases every time you meet a significant milestone, or make a significant release, and send them out into the wild through every channel you know (just don't abuse them -- no spamming via e-mail or newsgroups, as that just pisses people off),
• Write good documentation. Better yet, get a volunteer who can write good documentation :).
• Have fun, and make sure your volunteers are having fun as well. Share the credit and prestige with everyone who makes a contribution, no matter how small or insignificant. Make sure people are doing the types of work they want to do as much as possible.
• Have fun!

I hope this helps!

Yaz.