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

Adding comments

[kickme_hax0r]

I've picked up an open source project that doesn't have comments. There's major chunks of it that the code is such a mess that I have no idea what it does, yet I'm supposed to be fixing it.

Re:Adding comments

[RAMMS EIN]

There's the Commentator for that.

Anybody have an implementation of that for *nix?

Writing tests, user-level docs, and finding bugs

[multipartmixed]

Please, for the love of God, somebody come along and write a test suite for my project. I'm sick of breaking code by accident! ;)

Re:irc.freenode.net

[betterunixthanunix]

Hey now, we cannot have it both ways. If we want to push community support, that means that we have to be ready to answer the same novice questions over and over again, especially since a lot of concepts are lost on Windows and Mac OS users -- like the idea of a package manager. Yes, it may seem like the most obvious question in the entire world, but I frequently get asked things like, "How do I install ," and if we are unwilling to answer such basic question, people will just get scared (and subconsciously assume that "Linux is not ready for the desktop").

We may find it annoying, but we absolutely should not avoid it. In fact, we should being doing it more often.

Re:One thing I don't do is troublesome licenses

[maxume]

You could say "I choose to respect the GPL in situations where I am not prepared or legally able to do the work necessary for compliance."

real hackers don't dread

[10am-bedtime]

Ahhh, can't resist...

Real hackers don't dread unpleasant tasks. They write code that (perhaps write code that) does the unpleasant task for them.

Re:real hackers don't dread

[quantaman]

How do you write code to do PR/create docs? Please, be my hero.

Simple, you obviously just need to write a program capable of passing the Turing Test.

Of course when you finish you probably want to give it some interesting tasks besides just PR/documentation, last thing you want is for it to get pissed off and go all Skynet.

Re:real hackers don't dread

[rockNme2349]

Sorry, but I tried that already. It was an incredible AI, so I assigned it the process of documenting my latest project. Unfortunately that was too unpleasant of a task for it, so now it's working on code to create PR docs. I guess I'll just see what it comes up with.

From a user perspective

[93 Escort Wagon]

I think the answer is obvious - what most developers avoid like the plague is documentation.

Re:One thing I don't do is troublesome licenses

[Jeff DeMaagd]

Going off on not wanting to be called a troll without explaining why GPL is so troublesome to you doesn't help the discussion that you're supposedly trying to have here.

Thanks for Slashdotting me

[paulproteus]

Working on fixing the site...

Re:Thanks for Slashdotting me

[paulproteus]

The blog post can also be read at http://www.asheesh.org.nyud.net/note/debian/avoiding-working-on.html

Re:Ego

[WrongSizeGlass]

I try to avoid the rabid advocates who seem to think (or at least they project) that using anything that isn't open source is some kind of affront to the entire open source movement.

Sorry guys 'n gals, but sometimes I need something now and can't wait for it to be included, supported or fixed in an open source solution. My clients aren't patient and don't really care about the necessity for creating an equal playing field for all software developers.

Unreproducible bugs

[vlm]

What are the parts that, in your projects, you would be relieved if someone else looked at for you?

How about unreproducible bugs?

I hate the whole situation.

The bug reports; "Uh, I got an error or something when I tried to run it" "OK, what was the error" "I don't know" "So how do you know theres a problem?"

Failing to reproduce the error. This ties in with the "prove a negative" problem. When to give up? Just document what I'm doing and hope for the best, I guess.

Problems that are probably specification failures but you can't prove it. Closely tied to mystery black boxes that do something, but no one is entirely certain what. Even funnier when there isn't really a spec, just kind of a goal. Best of all, when two groups make opposing policy decisions and want you to consider each other's design to be a bug.

When to close out the hopeless bug. Well, it doesn't hurt anything to keep it open. But bean counters like easily counted beans, like how many open bugs. Will I insult the submitter by closing it? Some 3rd party weirdos like to get involved at that stage, "I'm morally superior to you because I never give up on a bug like you did, ha ha ha" while the reality of the situation is they merely have more spare time, a poor self image, and a desire to very publicly display it. aka the "ticket ss" "I am morally superior and I say we will have order here! Order! Achtung!"

Finally, last but not least, circumstantially, crazy/insane people seem to encounter more unreproducible bugs than typical people. Don't know if they're more ornery so the tend to report more, or more creative so they tend to find more, but I do know they're a pain to deal with.

Other than that, its not so bad.

Re:Unreproducible bugs

[gringer]

Here's some advice that I find useful when reporting bugs:
http://www.chiark.greenend.org.uk/~sgtatham/bugs.html

There are some non-obvious things in there, such as trying things that clearly won't work, if asked to by the programmer:

Somebody reported a bug to me once, and I asked him to try a command that I knew wouldn't work. The reason I asked him to try it was that I wanted to know which of two different error messages it would give. Knowing which error message came back would give a vital clue. But he didn't actually try it - he just mailed me back and said "No, that won't work". It took me some time to persuade him to try it for real.

How are volunteers unique here?

[betterunixthanunix]

What makes you think that corporate programmers are necessarily going to do drudge work better than volunteers? I guess you have only ever worked with big name proprietary software, where a lot of care was taken; I have seen many proprietary software packages that are barely usable, but they are niche products with little competition and thus there is no incentive for anyone to do a good job. So, where is the proprietary advantage?

Re:How are volunteers unique here?

[DaveV1.0]

What makes you think that corporate programmers are necessarily going to do drudge work better than volunteers?

Judging from the quality of 99% of the FLOSS software out there, I would say that primary difference is that corporate programmers actually do the drudge work whereas the volunteers don't. Or, more specifically, no one volunteers for the drudge work so it doesn't get done.

Re:Ego

[dvice_null]

> A lot of open source coders seem to avoid UI aspects and usability like a plague

- Programmers write code.
- UI designers design UI
- Technical writers write user documentation
- Graphical designers draw buttons and icons

The problem is that majority of open source developers are programmers and UI designing is a completely different profession.
Two possible solutions:
- Programmers must learn UI designing also
- We need more UI designers to join us

Re:Ego

[Securityemo]

My CS undergrad program has UI design as an obligatory second year course.

Re:One thing I don't do is troublesome licenses

[TheRaven64]

And the moment you distribute it you have to give the code to anybody you distributed to who asks

No you don't. You just have to give it to the people that you give binaries to. The GPL explicitly does not require you to give anything back, it requires you to give freedoms forward. In practice, this often means community-driven development with people contributing their changes upstream. They do this because it's cheaper than maintaining a fork though, not because the license compels them to. And, guess what? That economic incentive applies to permissive licenses too.

Compare, for example, Yahoo! contributing changes to FreeBSD back and Google keeping their internal version of Linux private. The GPL did absolutely nothing to protect Linux. The BSDL did nothing to protect FreeBSD. Yahoo! gave code back because they determined it that the cost of maintaining a fork was greater than the competitive advantage gained by keeping the code private. Google kept their filesystem (among other things) private because they made the opposite decision.

90% of software that is developed is never distributed. It is written in house to solve a particular problem. Whether you see any code back from these people depends entirely on whether they think it's cheaper. They can use GPL or BSDL code internally without any legal issues.

Re:Ego

[roman_mir]

You are probably right, but I think open source programmers need more of one more thing , which they maybe not getting enough of. Blow jobs. I think free and open source programmers need more blow jobs. From hot women. We should get the hot women to join in on this idea somehow.

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.

Open Source Nazis

[Niobe]

What Aspects of Open Source Projects Do I Avoid? The part where I get yelled at by a developer for filing a bug that I tried diagnose to the best of my ability but didn't mange to fix myself. Because, as we know, you shouldn't even USE open source software unless you're willing to DEVELOP it as well. Pffft.

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.

The aspect of open source projects I avoid is

[hey!]

contributing.

Re:Ego

[Ihmhi]

So were those! Pattern, perhaps?

The Curse of "Patches Welcome"

[bill_mcgonigle]

Interestingly, some projects could _really_ use a manager, but open-source projects are often begun by programmers who want to get away from having a manager.

There are a few floating managers disguised as QA people and community liaisons that manage to do a pretty good job at this without being recognized. Some of them read here. You're appreciated.