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

I recommend Tutos

[Korgan]

Tutos.

Its one of the most versatile project tools I've used for development projects. Full time management and accounting, tasks, there were even gantt charts addons, although I cannot remember where to find them.

Beyond project management, this also starts to grow into things like resource management. Its a very comprehensive package that I find extremely useful.

PHP+SQL and released under the GPL2. Will run on pretty much any platform (I have it on OSX, Apache+postgre) and easy to use once you get used to it. ;)

Give your community a good place to meet

[jtapper]

This might be a little ways down the road for your, but here goes anyway.
In my opinion, these are three essential things for your developer and user community to grow:

- bug tracking software (I recommend mantis)
- forums (I recommend anything other than the sourceforge forums)
- code repository (again I recommend using subversion on your own box rather than cvs at sourceforge)

The bug tracking software will allow you to set milestones and log issues so you can build towards those milestones. It gives active users as well as new users a good idea of what work is being done, at what pace, and your intended direction.

The forums are a great place for developer discussion to sort out what the next great feature will be or how to solve the current roadblock. Also makes for great reference material for new users. Almost like self documentation.

And obviously your code repository will give users easy access to checking out the latest changes and also commiting their contributions.

Let your community give you feedback on your project and steer the direction while you act as the figure head to sort out any conflicting needs/wants within the community. Remember that if your users/developers lose interest, your community will suffer.

Re:Give your community a good place to meet

[jtapper]

Subversion definately can be a pain to setup, but I've found it to be worth the effort.

One tool that gives you an excellent and basically unrivaled look into your code with subversion is trac.

Definately worth checking out for any subversion users.

Dotproject

[attaboy]

I evaluated dotproject not too long ago. The initative to implement it at my company got sidetracked, so I can't comment on actual usage.

It's on sourceforge and at http://www.dotproject.net/

Don't get too excited

[Scarblac]

If your case is typical, you will be programming on your own time for a long time to come. Just that it's on Sourceforge doesn't mean people are playing your game, let alone supplying patches - you should be very happy to receive one or two patches in the first year.

The important thing is to stay active, code a lot, and not let your project turn into yet another dead Sourceforge project. And then just handle things as they come up.

For 95% of the projects out there, there really isn't any difference between an open source project and something you just do on your own.

Re:Don't get too excited

[BinLadenMyHero]

Is it a .diff?
If so, try, on a shell terminal, something like this:

cd $project_dir
zcat $patch_file | patch -p 1

GanttProject

[mstefanus]

GanttProject seems nice. I haven't tested it thoroughly, but it seems promising. It was mentioned on a NewsForge article.

Re:Follow-up questions on the above

[Scarblac]

First guesses at answers:

- Traditionally, if people wanted support for platform X, they could test it on that platform and tell you the results. If there isn't anyone willing to do that, apparently there is no demand for a platform X version and it's not your problem. Although if you feel that supporting Linux is important for getting developers to help you on your project, I really think you should just install it on another box or dual boot. Or find a volunteer, as above.

- I would think that Sourceforge should be easily sufficient for your needs. If you have specific problems with Sourceforge later on, you can always move.

- Mention them in your README.txt and/or Changelog?

- Version numbers and names are rather arbitrary; it's totally your call. Every scheme you can think of (including version numbers that converge to pi) is probably already used by some serious project. But generally, 'alpha' and 'beta' etc mean 'please test this for bugs', and other versions are for use by people who don't want to see a lot of those.

- Wikis are highly useful for lots of things. I have no experience with using them for OSS, but I could see them as a nice way to start making documentation.

- Duh, a lawyer. Or the FSF if you release your code under the GPL, they are experts and are probably willing to give advice.

The Art of Unix Programming

[Anonymous Coward]

Read Eric Raymond's "The Art of Unix Programming", available online here, especially Chapter 19 about good free software development practices. Most of the guidelines are directed towards contributors instead of project maintainers, but you will get a good overview of the "best practices". The rest of the book might be less interesting to you if you're a Windows guy, but it's still a nice read (ignore ESR's random political rants and self-righteous examples) and gives a good overview of "The Unix way" of doing software development.

Learning More About Open Source Licenses

[gManZboy]

Check out There's No Such Thing as a Free (Software) Lunch. It's summarized as: What every developer should know about open source licensing and written by a General Counsel at Wasabi, an Open Source company.

Re:Follow-up questions on the above

[Otter]

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?

To some extent, this depends on what you're coding -- a script that should easily maintain cross-platform compatability, reliance on a cross-platform toolkit or something that will require a lot of work and prayer. My recommendations would be 1) install Linux somewhere you have some free disk space and 2) if you can't do that, get someone to periodically try builds for compatability.

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

Hey, the more credit they get, the happier they'll be. Put their names in the README, the source, the News section on your site...

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?

Typically, separate "Stable" and "Development" releases are offered (as well as anonymous CVS access, sometimes). Netscape has permanently destroyed the meaning of "beta". The only "set standard" is "It's free, so STFU!"

Re:Follow-up questions on the above

[prezkennedy.org]

I've been actively following open source game (it's been linked to from Slashdot a couple times) development for awhile and might be able to provide you with some useful pointers.

• You could get a Linux maintainer, or you could attempt to use the compile features at Slashdot, they have many different types of boxes and operating systems for you to choose from. If you want to support all Linux versions, definitely see about getting a helpful maintainer to keep the source working and be able to compile something that works for a majority of the distributions out there.
• SourceForge is the largest community, but BerliOS is nice as well as it has SVN, CVS, and most of the other nice features that SourceForge has. Admittedly, the community is much smaller so you'll receive less traffic if you go there (but that didn't stop me from signing up my project).
• Make an AUTHORS file in the root of the source code and give them credit for what they did. You could also have a credits option in your game and list contributors.
• Someone else mentioned the meanings of the different terms so I won't go into that. You can however, have as much leeway as you wish when it comes to numbering conventions. Just be consistant!
• Wikis can be useful for OS projects as BZFlag will show you.
• If you have legal questions, first look through the licenses at the Open Source Initiative to see what they have to offer. It's a good idea to use your common sense for most things, but if you have really pressing issues you might be able to ask the folks at the FSF (they have some very brilliant minds at work there), or you may have to find and befriend a lawyer. ;-)

Hopefully that helps you out a little bit, development is one of those things that you can run yourself. Just don't abandon your work after a few months. I hate when people make a page on SourceForge and then don't go anywhere with it. It wastes my time and their resources when I go through trying to find the latest game projects.

Autoconf sucks - use PMK instead

[Anonymous Coward]

I found PMK to be MUCH easier to work with than the autoconf nightmare. Also, if you are doing C++, check out the Boost libraries, which hide most of the cross-platform complexities for you.

Re:Follow-up questions on the above

[Yaztromo]

As an Open Source developer myself, who likewise has their project hosted on SourceForge, maybe I can help somewhat.

* 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?

This can be a really hard question to answer. Ideally you'd like to find yourself a maintainer to work with you on this sort of thing, but finding one is a different matter. Such a maintainer will either worm their own way out of the woodwork, or they won't. Recruiting one yourself will probably be a lengthy and fruitless prospect.

In the more than two years my project has been Open Source (it was closed source freeware for 5 years), recruiting more people to work on the project has been nearly useless. In that time, after lots of recruitment campaigns, I've found only 4 or 5 people who have actually made any significant contributions to the project and all of its sub-projects (the last time I tried to run a recruitment campaign a few weeks ago I got about 50 responses, virtually all from India, who somehow interpreted "looking for a volunteer developer" to mean I was looking to hire someone for a job :P).

* 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?

Depends completely on your project. SourceForge is a good general place to host your project if nothing else fits -- they provide a good service IMO -- but they also host any project which is Open Source. If you can find one, you might be better off using something which is a more targeted community for your type of project, whether it be by language/develpment environment used, target OS, application type, etc. That is, if you're developing a Java-based project, java.net is a good choice, as everyone there is working in Java. If you're developing on OS/2, netlabs.org is where you'll find other OS/2 developers (what few there still are). If you're coding for Linux on the PlayStation 2, playstation2-linux.com is the place for you.

Don't forget -- nothing really prevents you from registering your project on every project site that suits your project, although maintaining all of those active communities might prove very time consuming!

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

Create your own. Typically what I do is credit the user by name and e-mail address during the CVS check-in. As I use the CVS log as the basis of the changelog for each release, this information also becomes part of the changelog. I also try to add an entry for them to my "Special Thanks" section of my Release Notes, and sometimes a comment crediting their fix/addition right in the source code. If the contribution is really significant, they usually also get a credit in the copyright statement.

One thing you should do, however, (something that I try to do at least), is to ask them if they want credit. Some people won't (and I've had a few contributions like this) for various reasons. Maybe they don't want to be bothered with questions, or maybe their employer has a draconian policy against this sort of thing (although in the latter case, you probably don't want to accept anything new from them so as to CYA. A minor fix that won't be subject to any copyright problems should be fine, however (ie: someone pointing out that an "i--" should be "i++", etc.).

* 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?

Well, there used to be a standard, but far too many projects have v

Trac is great for lightweight PM and SCM

[TheReal_BarkMan]

I have been using Trac for a little over half a year. Trac provides a combination of wiki + ticketing system (bug/issue tracking) + Subversion integration for source. Project Roadmap and Milestones are particularly helpful.

Check it out at http://projects.edgewall.com/trac