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. ;)

Re:I recommend Tutos

[Anonymous Coward]

they have blink tags on their home page! :(

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

[smagruder]

Agreed, except for subversion over CVS. CVS comes pre-installed in most, if not all Linux distributions, is extremely easy to work with, and many software platforms integrate with CVS. Subversion has to be installed, and it has, in my opinion, too many prerequisites that make installing too much a pain for your average beginner. Certainly, subversion offers some technical enhancements over CVS, but CVS is tried and true, and is a great start for a beginner.

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.

autoconf

[keesh]

The first rule of autoconf is to find someone else to do it for you, or if that's really not possible to copy it off some existing code. autoconf is deep scary badly documented hacked together voodoo -- it's really not worth learning it properly unless you're going to be doing distribution work or similar.

Re:autoconf

[hitchhacker]

yea, all the autotools were tough for me to get into, but the documentation isn't bad.
There is a whole book available online to help:
The Goat Book (GNU Autoconf, Automake, & Libtool)

It's just macros anyway.. :)

-metric

Re:autoconf

[janwedekind]

At http://www.gnu.org/software/ac-archive/ you can download a bunch of autoconf-scripts for doing checks for different software (OpenGL, Qt, Lapack, ...). I found it to be quite useful.

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/

Re:Dotproject

[afd8856]

If the dotproject developers apreciate the postnuke systems as something to be used and maybe be inspired by, I don't even want to take a look at their project. Mod me troll, but *nukes are not an example of how to do 21 century webdevelopment.

Re:Dotproject

[Anonymous Coward]

What did you go with instead of dotproject, nothing?

Just curious because I think the same thing is going to happen at my company...

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

[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.

Re:Don't get too excited

[Scarblac]

Do you ever get mail on these projects? I would expect that before anyone would contribute anything, they would first be using it, asking you questions about it, etc.

Re:Don't get too excited

[reynaert]

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.

But on Sourceforge you list it as "Status: Alpha/Beta", your last release was 0.2 half a year ago and the mailing list is inactive. You web site has no documentation, no references to projects using your code, and, again, no mailing lists. It has all the tell-tale signs of a failed project.

So my recommendations:

• Put the documentation online.
• Given that there's a second developer, communicate over the mailing list. Don't use private mail or IM. That way other people can comment too, and, well, participate in development. Or just see that the developers are still active.
• Even if there are no other developers, even if you know nobody is subscribed, still send at least announcements of new versions to the list.
• Put your own mailing list archive online, or use GMane. SF's mailing list archives suck.
• If you believe your code is stable, don't advertise it as "alpha". Just go ahead and call it 1.0. If it turns out you want to make some large changes, call it 2.0.
• Back to your website. Get rid of that stupid contact form. Who even uses those things? Advertise your mailing list instead.
• Get rid of PHP. Your site is slow and has ugly URL's. It's much easier to refer somebody to http://pobs.sf.net/download.html than to http://pobs.sf.net/index.php?section=9&page=25.

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

Re:Don't get too excited

[tanguyr]

Skip on over to your neighbors at Gnuwin32.sourceforge.net - all kinds of *nix command line goodness ported to windows.

Re:Don't get too excited

[smagruder]

Get rid of PHP

Not exactly useful advice there. People are fully accustomed to the longer URL's that are, by the way, standard for any scripted web site--having nothing to do with PHP specifically. By the way, most PHP sites I've been to are screamingly fast, so if the site is slow, its code should be examined for performance issues, e.g. too many database calls during page generation.

Re:Don't get too excited

[an_mo]

It depends on the project leaders attitude. I use a tetrinet client, and wrote a patch for it because i felt it was missing an obvious feature (the ability to map some keys that weren't mapped). Nothing fancy, just a few lines of code here and there.

Offered the devs to send them the patch, never heard from them.

Re:Don't get too excited

[cerberusss]

If you believe your code is stable, don't advertise it as "alpha". Just go ahead and call it 1.0.

This is DEFINITELY a good advice. The other day I told the project manager that I was going to use this Java library and he came back to me, saying "hey, the library is versioned at 0.0.6, that doesn't look good AT ALL". No matter that it was part of Classpath and passed a bunch of unit tests I threw at it.

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

[Ithika]

Trying not to seem too much like a "me too" post - but these are all very interesting questions that I would like to see answers for. Are there experienced OSS developers here or has slashdot (as I've always suspected) a high mouth-to-trouser ratio? :)

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.

Re:Follow-up questions on the above

[SunFan]

What's the best way to go about ensuring Linux/POSIX compatibility over the web? Compile farms?

You might look into Cygwin to get started. I haven't used it, but it is a popular POSIX layer for Windows.

You won't need a compile farm for a one-person project. IIRC, 90K lines of code took about 5 minutes to compile on an old Sun workstation, and Make-like tools speed incremental builds. Even on an old computer, you would probably spend more time figuring out parallel builds than you would save by using them.

What's the protocol for crediting them for the work?

I'm sure the FSF would have a few opinions about this. Basically, give credit where credit is due in a file or on your website, unless someone doesn't want it.

What are the criteria for determining whether or not something is "pre-alpha", "alpha", "beta", etc.

For a one-person project, just don't worry about it.

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

For a one-person project, just CYA (cover your ass). Don't take code from sources with licenses incompatible with yours (yes, you really do have to read the licenses). Basic questions are almost certainly already answered somewhere on a newsgroup or forum. If you find code that is unlicensed to the best of your knowledge, you probably still want to find who the author is or see if there are multiple sources on the web (it may be public domain).

MORE IMPORTANTLY:

It seems you are beginning to fall into a trap that many many programmers do when taking on a new project. You are starting to ask lots of questions about process before you even really get deep into your work. Don't worry much about the bureaucracy of sophisticated version control or bug tracking, right now. For a relatively small code base, you can easily spend more time learning the nuances of your tools than you do programming, which is no help to your progress. The most important thing you can do now is focus on your program and its architecture and keep backups of your work (at least every night do a backup). If you feel you've achieved a milestone, make a complete and separate copy of that source tree for future reference.

Re:Follow-up questions on the above

[JohnFluxx]

I'm an experienced OSS developer, but have never had to worry about most of these questions.
And deciding alpha status? well that's just common-sense and randomness ;)
Generally the only rule is don't break ABI between minor releases (3.2.x) and don't break API between intermediate releases. (3.x)

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.

Re:Follow-up questions on the above

[reynaert]

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

Don't worry too much about it. Just make sure you're software doesn't use too much that's obviously Windows-specific, and advertise that you're looking for somebody to port it. If your software is useful enough, somebody will do it sooner or later.

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

Mention them at least in the changelog: "Rewrite the frobnication code. Patch from J. Random Hacker". If some effect of the patch is mentioned in the announcement of the new version, mention them there too: "Much faster frobnication, thanks to J. Random Hacker". I think everybody would be happy with this.

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?

I think it's best to forget about those labels. Everybody interprets them differently. Just say whether it is likely to crash or eat all my data (is it stable or unstable?), which features are expected to work, and, in case of a library, whether the API is expected to change.

* How useful are wikis for OS projects?

They can be as useful as any form of documentation. But before starting one, please make sure you that you have something to put on it (content won't magically appear), and that you have a few people who are dedicated to editing and maintaining it. There are too many empty (or spam-filled) wiki's out there.

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

This is rather vague... Do you have any specific worries?

Re:Follow-up questions on the above

[prezkennedy.org]

Guess I should proofread closer... I meant SourceForge when I was talking about compiling stuff... Ooops!!

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: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

Re:Follow-up questions on the above

[BenDeutsch]

...or you could attempt to use the compile features at Slashdot...
Guess I should proofread closer... I meant SourceForge when I was talking about compiling stuff... Ooops!!

Dang. And here I was checking the lameness filter for hidden "compile" switches...

Re:Follow-up questions on the above

[name773]

my best advice is to actually go out and do it.

GanttProject

[mstefanus]

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

Re:GanttProject

[michaelbuddy]

I've tested and use GanttProject extremely thoroughly. It's a great desktop app. It does have 2 routes you can go when you create a new project. 1 is a software project, with all the default job titles, the other is standard, and you customize your own project. The best thing about it is you can see your timeline, and see if it looks reasonable. Then move tasks around rearrange and make it so things flow in the right order. It doesn't offer bug tracking from what Ive seen. It does work well if you have a boss who wants to see your project, you can even upload it to a wevdav server and share the project.

I'd recommend it to a business project manager, one who might use microsoft project, but not really will it assist in solving problems. it's more like time / week / month management. And helps you flesh out your project in visual form.

If your goal is to create good software with no deadline, it's useless. If you have a deadline, on your project it might help.

the diiference

[failrate]

Pre-alpha means that some features have not been implemented. Alpha means that all features have been implemented, but some bugs remain, and you are still missing some content. Beta means that all features and content have been implemented, but some bugs remain. Final/Gold means that all features and content have implemented, but no bugs remain that your team is aware of. Some people may have different definitions, but these are pretty widely agreed upon by professional game studios and publishers.

Re:the diiference

[JohnFluxx]

I think the rules for game studios and publishers is totally different from the OSS world.

I'd say pre-alpha means it doesn't crash.
Alpha probably means feature-freeze (big difference from 'all features have been implemented', if I'm interpreting right), and then release candidates for string-freeze and bug-freeze.
I don't think I've ever seen a OSS program that's Final or Gold.

Re:the diiference

[dubious9]

Your list is a good start, many of my old bosses should take that to heart. Why do managers not accept that the final pre-release (when we have no beta testers) will be a beta? Why the hell call it "1.0" and then have users be angry that it's buggy, and/or incomplete? I *hate* that.

Rant mode off, I think you catagorization is a bit off. I agree with pre-alpha with the added stipulation that non-developers shouldn't be working with it yet. Alpha, means a useful feature set that still has enough bugs that it shouldn't be used by non-developers yet. Note that it's not a fully featured. Beta is core features are usefull and few critical bugs remain. , and is ready for testers. Final is all major features usable with no known critical bugs. If one waits until no known bugs, your product will never go gold. There will always be known issues. That's why there's 1.1.

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.

The #1Thing

[RoadChris]

Always remember to defrobnicate the fitzer valve. Nobody will take you seriously until you do.

Submitter's project

[Anonymous Coward]

A hasty Google search revealed the submitter has launched a project consisting of a game called Rush 2005 , which is described as is quoted beneath.

Rush 2005 is a BSD-licensed project to create an American football game for Windows and Linux in the tradition of Tecmo Bowl and NFL Blitz, built using the cross-platform SDL game programming library.

It looks quite primitive as it is, but with your help ...

(I am not affiliated to the submitter, by the way.)

Follow GNU standards and maintainers guide

[Carl]

Although specific to GNU projects they still contain very valuable advice for any free software project (especially when the project wants to work nicely together with the rest of the GNU system).

• GNU coding standards
• Information for maintainers of GNU software

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.

wiki + cvs

[BinLadenMyHero]

For a relatively small project, Wiki can integrate bug tracking, forums, homepage, documentation, etc.

Oh my God, aendeuryu

[Anonymous Coward]

You rock, aendeuryu! You actually said "different from" rather than "different than"... Thank you.

Never use a Wiki for technical documentation.

[KevinDumpsCore]

> How useful are wikis for OS projects?

Never use a Wiki for documentation! Instead, you need a documentation maintainer to handle submissions. They will ensure that your documentation is clear, complete, correct, current, and consistent. This is hard work that goes largely unrecognized by the rest of the Open Source community.

Consider your documentation maintainer a part of your team. Give them CVS privileges. Don't disrespect them because they don't contribute massive amounts of source code. Answer their questions quickly and in a friendly manner.

If they have a problem explaining a feature, it may be a usability problem with your interface. Also, users will find a bug but will complain that the manual is wrong. So documentation maintainers are a source of good bug reports. Don't ignore their input because they're not an active programmer!

DocBook is the standard markup language for the major Open Source projects, so learn it.

sorry

[BinLadenMyHero]

I didn't read your comment till the end, and missed "...that hasn't been a problem for me on any of the Windows machines, and I don't have access to a Linux box..."

Anyway, cygwin is a good way to run Linux commands on a Windows box.

"Contributors" can do more than code

[JavaRob]

SourceForge lets you specify what kinds of help you are looking for -- use this to find someone to help you out with these details. People love giving advice -- find someone interested in your project who has done this before, and take advantage of that. Give them access to your project, discuss the best options with them (nice learning experience for you... plus needing to explain "why" will push them towards better suggestions), and you're on your way.

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.

it's a bit personal..

[BinLadenMyHero]

On my game project I "defined" this:

Pre-alpha: something working that it's worth to show.

Alpha: Most basic engine and gameplay components working.

Beta: I finally looks like the game I had in mind (that is, all features that I thought off for the game are working), but it's not finished yet (gameplay tweaks, maybe a bit more content, bugs, maybe some optimization..)

Final: It's ready (but can envolve further).

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.

Bah. Use the front door.

[Anonymous Coward]

Get rid of PHP. Your site is slow and has ugly URL's. It's much easier to refer somebody to http://pobs.sf.net/download.html than to http://pobs.sf.net/index.php?section=9&page=25.

Even easier... Use PHP or anything you want and just send them to pobs.sf.net. The first thing they should see are obvious "download", "forums", "documentation", "screenshot" links. Encourage everyone to go in through the front door.

Shortest URL possible and opportunity to see other urgent/useful things.

Correcting myself.

[Yaztromo]

One minor typo/error in my list of release stages. The entry for "beta" reads:

• Beta - feature incomplete, but not fully tested.

...when it should actually read:

• Beta - feature complete, but not fully tested.

Sorry if this caused any confusion.

Yaz.

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

Eventum from Mysql AB

[antigravity]

Eventum is a user-friendly and flexible issue tracking system that can
be used by a support department to track incoming technical support
requests, or by a software development team to quickly organize tasks
and bugs. Eventum is used by the MySQL AB Technical Support team, and
has allowed us to dramatically improve our response times.

Product Overview:
http://dev.mysql.com/downloads/other/ev entum/index .html

Screen shots:
http://dev.mysql.com/downloads/other/event um/scree nshots.html

Features List:
http://dev.mysql.com/downloads/other/eventu m/featu res.html

Eventum has three main areas it may be used: One as a bug tracker, one
as a support software (ticket system), and one for project management.

We currently track many projects through several stages of development.
Using custom fields we are able to add project specific infomation to
the issue/task. i.e files edited, file added. SCM integration allows us
to track cvs commit history of all modified files associated with a
given issue/task (Change set). The project is supported and developed by Mysql AB
with a very nice user interface and well written php code (easy to
customize).

Quick List of Features:
-SOAP and XML-RPC
* add issues/task via web service api
-Email Integration
* add issues via email
* Create / Modify / Delete canned email responses to automate
common tasks of replying to support email
-SCM Integration
-Assigned issues listing by user
-Project Management
-Reports and graphs (by issue, by priority, by issue time, etc...)
-Command Line Interface
-Phone calls by issue/task
-notes by issue/task
-File upload by issue/task
-and many more ...

Eventum is wonderful for managing a large group of people over many
projcts and breaks the barrier between a bug tracking/ticket system and
a project management system. Well worth a quick look!