What Aspects of Open Source Projects Do You Avoid?

paulproteus writes "I'm a Debian developer and a part-time contributor to a few smaller projects. I do a lot of free software-y and open source-y things. Sometimes, though, I don't do them. I figure some other Slashdotters might have similar hang-ups — we contribute to a project, but there are parts that we really dread thinking about. So I wrote a post about having these hang-ups, and I made a place on the web to share how others can help your project. What are the parts that, in your projects, you would be relieved if someone else looked at for you?"

Comments

Re:Ego

[acidrainx]

Exactly. I'm a professional UI developer and I used to contribute to open source software quite a bit back in the day. I don't contribute much these days mostly because of lack of free time to do so, but this was a major point of contention for me.

The biggest problem is that the programmers have trouble accepting advice for changes to the product they've poured their blood, sweat, and tears into. I've found for the most part that many open source projects are over complicated. One of the best ways to improve the usability of a product is to simplify it. You need to remove or conceal the features that are rarely used. Unfortunately, those features tend to be the hardest to implement, so the person who implemented it wants to make sure people know about it. It's not unexpected that they wouldn't be happy if you suggest that it be removed.

Re:irc.freenode.net

[Dorsai65]

One of the reasons I avoid all this open source stuff is that most of it is badly documented

THIS

IRC channels, wikis, blogs, mailing lists (and their archives), a set of web pages... none of these is a valid substitute for actual documentation that a user can actually find an answer in. Fine, if you feel the need to be high-tech, edgy, l33t, or whatever, make it a pdf or downloadable html pages. Do not force users to have to jump through any 'extra' hoops to try and get help with a problem they may be having. I'd also add:

• If you get some variation of the same question over and over again, you need to (better) explain it in the docs.
• If a user finds an actual bug, don't make them have to sign up for some service or other that they'll (hopefully) only need once (i.e. Bugzilla) to report it. Maybe have a bugs@myproject.org to triage.
• CLEARLY provide SOME way to contact SOMEBODY actively involved with the project. Keep this updated if you don't want to be getting annoyed emails five years from now.
• If it's a Linux app, it would be kinda nice if it worked/looked good under ANY desktop, not just your personal favorite.