How do I decide which features to implement?

Answer 1

Fix all MAJOR bugs first. After that then work on the fun/interesting features that have been requested until you run out of fun/interesting ones. Then fix more bugs. Judge what you think would be more useful to the users. Also a voting system would be a pretty good idea. Just have a big list of features and have people upvote or downvote the ones they like or dislike respectively.

If you come across a feature that you are not particularly interested in, spice it up a bit yourself. Add your own flavor to it.

And when your bored of all of that, refactor!

Answer 2

First, get the software up and running to a point where it is usable and YOU are happy with the code (including refactoring). Until then, do not take any requests for additional features from others users (other than bugfix requests).

If you start the "democratic process" too early you will never get to a point where anything really works. Another important issue: DO NOT try to make everybody happy! It is impossible!

You as the developer have to be the final filter for any kind of requests for improvement. If it doesnt make somewhat sense to you, don't do it. Separate bugs and feature improvements strictly. Bugfixes come first, feature improvements next.

Personally, I think putting feature requests up for voting is a good idea. But I would make sure to have filtered through the requests in terms of "does it make sense?" and "do i really want to do this?" before putting them up for vote.

Answer 3

Don't worry too much about what other people want. This is your project and you are doing it for free. Your goal should be to make yourself happy.

If I were you, I'd identify whatever it is that is causing the most pain, and fix that first. Then just keep doing that.

Voting might be an interesting way to determine what your users most want, but you should be a dictator. Design by commitee never works

Answer 4

Fix all MAJOR bugs first. After that then work on the fun/interesting features that have been requested until you run out of fun/interesting ones.

I agree, in principle, but one of the challenges here is that most of the bugs and issues I am not happy with would likely disappear if I rewrote some major parts of the application. Naturally, this would probably introduce new, possibly different, bugs, but at least I would hopefully have more fun doing it than struggling with the old code. The downside to this approach is naturally that it will take much longer time until I have something suitable for release to the public.

Answer 5

Prioritize like this:

seriousness, effort

So you might have a less serious bug you can fix in an afternoon, and you might do that instead of fixing a more serious bug that takes a month and takes you over a release cycle.

Answer 6

To add to what schroeder said, I would also like to point out that you should take feature requests that are backed by code a lot more easily than I would any other type of request. If you turn them away, you could risk losing a future developer.

EDIT: See the following book. Read it and then read it again just to make sure you got everything. I'm serious about this.

Producing Open Source Software