Open Source Project Management for Beginners?

aendeuryu asks: "So I've been getting the programming bug again, and I started up a Sourceforge project for a game I'm trying to write. Development is going really well so far, but I've quickly realized that programming in my own personal vaccuum for my own personal pleasure is completely different from programming for the community at large. Things I never needed to worry about -- applying patches, writing documentation, license requirements, creating autoconf files for Linux compatibility -- are suddenly my responsibility. Now, I'm trained in programming in several languages, using databases and specialized libraries, etc. but when it comes to deployment for, and interacting with, the Open Source community at large, I know just about nothing. So, to all the veterans out there, where is a good place to go to get your feet wet on this? Is there any good advice for people who are getting started in OS project management?"

Comments

Follow-up questions on the above

[aendeuryu]

I didn't want to clutter the submission with my own personal dumb questions, so here they are:

* All my development right now is on a Windows box. What's the best way to go about ensuring Linux/POSIX compatibility over the web? Compile farms? Recruiting a Linux maintainer?

* If I don't have access to my own server, where is the best place to host? Sourceforge (the only one I really know about) or somewhere else?

* Somebody's submitted a patch. What's the protocol for crediting them for the work?

* What are the criteria for determining whether or not something is "pre-alpha", "alpha", "beta", etc. Is there a set standard, or do I get to determine this on my own?

* How useful are wikis for OS projects?

* If I have legal questions regarding licenses or IP, who should I talk to?

Re:Follow-up questions on the above

[Jellybob]

Hey,

I'm one of the developers for the Jaws Project, which is currently taking off as an Open Source project, rather than a pet project under an OS license.

All my development right now is on a Windows box. What's the best way to go about ensuring Linux/POSIX compatibility over the web? Compile farms? Recruiting a Linux maintainer?

If you don't have any experience of developing under Linux, and you aren't motivated to get any, then let someone else do it. If you want to get to know Linux, there's nothing quite like porting software to do it.

If I don't have access to my own server, where is the best place to host? Sourceforge (the only one I really know about) or somewhere else?

Sourceforge is probably enough to begin with, obviously a dedicated server with everything you want running on it would be nice, but if you can't/don't want to afford it right now, just stick with Sourceforge. There's much worse out there. For the record, Jaws is currently using SF's CVS and we havn't had any problems other than it being CVS and not Subversion :P

Somebody's submitted a patch. What's the protocol for crediting them for the work?

I tend to credit the bumitter in the commit message, and add them to the THANKS and AUTHORS files which get distributed with each release (you should have both of these).

What are the criteria for determining whether or not something is "pre-alpha", "alpha", "beta", etc. Is there a set standard, or do I get to determine this on my own?

Largely it's a case of picking one depending on how things are going - if things are working, but not thoroughly tested, it's probably beta. If things are working when the moon is aligned right, it's pre-alpha.

How useful are wikis for OS projects?

We recently created a Wiki for Jaws, and it's been incredibly useful as somewhere to coordinate development of ideas. Sure, it could be done in CVS with plain text files, but a Wiki tends to be a lot quicker to use. We're using DokuWiki, which as far as I'm aware will run happily on SF's servers.

If I have legal questions regarding licenses or IP, who should I talk to?

Thankfully we havn't had to deal with this one yet. I'd reccomend a lawyer, preferably one with previous experience in software licensing, although that is likely to get expensive.

Re:Don't get too excited

[aendeuryu]

you should be very happy to receive one or two patches in the first year.

Actually, I just got my first one yesterday (the project's only a week old, and I'm pretty flattered that somebody took the time to bother), but I don't know what to do with it! I'm pretty sure it's filename extension related, but that hasn't been a problem for me on any of the Windows machines, and I don't have access to a Linux box to check and see where the errors may be coming from and how to fix them.

Re:Don't get too excited

[mwvdlee]

How about smaller projects which are "finished" (at least from the single-programmer perspective) before they ever gain a sufficient "activity" percentage on SourceForge?

I have a project on SF (pobs.sourceforge.net) which started when the activity measurements were cripled and since they still are (to my knowledge) they never measured any activity, even though I (together with one person) produced code on a daily basis.
The code was finished (at least from our perspective, we couldn't think of any way to improve upon it) and now it looks like a failed project, even though it's finished, stable and documented.

I've also released other finished projects on SF in the past, most of them never gain any developers because the activity meter just stays on zero, even though the code is fully opperational.

My experience with PM tools....

[fm6]

I've done a little project management myself, and I've also worked with a lot of full-time project managers, both very good and very bad. My own experience, and my observation of the best project managers tells me this: it's a serious mistake to get hung up on tools.

I once worked at company where the PMs were treated like royalty -- and with good reason. You saw them fighting Murphy's Law every day, and usually winning. I worked closely two of the most respected PMs ("respected project manager" sounds strange, since most companies treat them like shit) and neither of them relied on fancy tech. One simply kept a lot of notes on hard copy, email, and internal web sites. The other mostly did the same, but also hacked together a simple web-based database to help the developers on his team not trip over each other. Both did a really great job.

At the same company, I worked for the one department(publications) that refused to have a professional PM. (Manager was a socially challenged empire builder.) A lot of PM chores fell to me, because of the nature of my job (production for an online document bundle) and because I was the lowest-status member of the department. I knew jack about project management, and had to learn by doing. I made a lot of stupid mistakes, but the biggest was putting my faith in a Lotus Notes database to help me coordinate workflow. It looked cool, and it satisfied my long-frustrated desire to learn Notes, but it just didn't come close to repaying the amount of time I spent working on it.

Later I worked at another company where everybody had the more usual attitude towards PMs: they're petty bureaucrats whose only role is to waste everybody's time. Since there was no coordination, projects were always going off the tracks. Management lacked the ability to change the way people worked, so they kept coming up with silly magic bullets: weird organizational changes, rules for how people were supposed to do things (always ignored), and of course lots of fancy project management tools.

I spent hours learning and fighting this software. It wasn't totally hopeless, but it was overdesigned and inflexible. We would have been better off with simple web pages and databases. Wikis come to mind.

My point is this: you need to learn how to be a Project Manager first of all. Then you'll know enough to chose the right tools.