Slashdot Mirror
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?"
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.
-- Microsoft is the most expensive commodity operating system and office suite vendor in the marketplace.
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:
> 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.
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.
Steve Magruder, Metro Foodist