Arch Linux

xelados

Member

Registered: 2007-06-02

Posts: 314

Website

Meta: How to maintain a software project well?

The FOSS world is fueled by people scratching their itches, users and devs forming around software they love and improving it. Among the chaos, there is still order. There's a way of doing things that's expected in the community. This topic is aimed to ask developers how they think a successful or good project should be managed so others can learn a bit. Any aspect of it may be covered; I'm looking for answers for me and any other fledgling programmer that wants to adopt good habits. Here are a few questions to help set the tone:

* What versioning numbering system do you use or like?

* (assuming you use git) What is your favorite workflow? Do you use multiple branches? If so, how do you separate them and resolve merging when it's ready?

* How often do you commit changes?

* How do you raise awareness or interest in your software without spamming?

* How do you find other developers to mentor you or contribute to your project?

* How do you manage a changelog?

* When do you stop adding things and prepare a stable release?

* At what point do you need an IRC channel or mailing list? A wiki?

By all means discuss anything else related to starting and maintaining projects and their attached communities. The less-experienced (like me) could really use the insight.

EDIT: I use "how do you" deliberately; I want to know how _you_, the developer, work on your projects. If you could go into detail when necessary, that'd be awesome.

Last edited by xelados (2011-07-01 00:03:19)

---

sporkbox@GitHub

Nisstyre56

Member

From: Canada

Registered: 2010-03-25

Posts: 85

Re: Meta: How to maintain a software project well?

Well by no means am I very experienced, but I really like Donald Knuth's versioning systems:

Version numbers of his TeX software approach the number π, in that versions increment in the style 3, 3.1, 3.14. 3.141, and so on. Similarly, version numbers of Metafont approach the base of the natural logarithm, e.

---

In Zen they say: If something is boring after two minutes, try it for four. If still boring, try it for eight, sixteen, thirty-two, and so on. Eventually one discovers that it's not boring at all but very interesting.
~ John Cage

listdata

Member

Registered: 2008-12-23

Posts: 102

Website

Re: Meta: How to maintain a software project well?

Hi xelados,

I'm not a professional FOSS developer (I just send patches once in a while...), but I nevertheless have several thousands of lines of code for personal projects. My biggest epiphanies during the making/maintaining of my projects were: (1) stick to a coding style (e.g., Linux Kernel coding style), and (2) write documentation. The coding style helps keep development sane, and the documentation keeps the users (including yourself) sane. Good coding style by definition includes meaningful comments, of course.

I use git. In particular, as regards changelogs, versioning, etc, I've always emulated the git/Linux Kernel projects (how they write commit messages, version tag numbers/annotations, etc.) because they've got the whole revision control + development model down to a science.

As for git workflow, I use some of the features like rebasing to get things in the right order, using multiple branches to keep feature-development separate, etc. There are reams of git tutorials, best practices articles, etc. on the net. I guess I'm sort of lucky because git was my first revision control system I learned (around the same time I got started in programming), and CVS/SVN hasn't "rotted my brain." (quoting Torvalds from his Google Tech Talk.)

The IRC channel/mailing list/wiki stuff --- I only have experience as a user, not a dev. But IMHO, wouldn't these resources sort of "grow" out of a project's own momentum? Maybe it's a chicken-and-egg problem, because you need these forums to build a community, but then you first need the community to foster more discussion about the project...

But even without a community, you can always just go solo for several months and *poof* unleash whatever you're working on. So many top open source projects started this way. As long as there's a need, the users will follow... The key is probably not to burn out before you finish your alpha release.