Slashdot Mirror
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?"
As long as I don't have to make freindly with the natives, the headhunters, and the unwashed masses, I'm happy.
"Windows is like the faint smell of piss in a subway: it's there, and there's nothing you can do about it." - Charlie Br
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! ;)
Do daemons dream of electric sleep()?
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.
Palm trees and 8
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."
Nerd rage is the funniest rage.
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.
The only thing it restricts is your ability to fork a open project and close the source. I don't know if I'd call changing that an improvement...
And don't give me the "viral" lie. Boxee closed the code it wrote and left the GPL XBMC guts open just fine. You just can't close already open code.
One way of stopping a wildfire is to use a controlled burn to burn off the area before the wildfire can reach it. Fighting fire with fire works.
I think the answer is obvious - what most developers avoid like the plague is documentation.
#DeleteChrome
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.
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.
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
People can use GPL code without giving anything back. They just can't modify it and hide those modifications from their users.
Nerd rage is the funniest rage.
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?
Palm trees and 8
> 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
Could you please tell me your projects, so I can avoid them and hence breaking my system? ^^
Any sufficiently advanced intelligence is indistinguishable from stupidity.
Yes, because every girl dreams of giving a blowjob to guy that 1) works for free 2) sits on computer all day long 3) just goes on and on about the wonders of open source 4) doesn't make any money
I think there will be a huge line of girls waiting!
Actually, the GPL extends plenty of freedom to developers; the only restriction is that those developers cannot impose any further restrictions than those imposed by the GPL
Another problem is that a lot of works, even works under "permissive" licenses, are licensed incompatibly with the GPL. For example, how would one make a video game using engine code and scripts under the GPL with, say, textures under the Creative Commons Attribution License? One might claim that the game engine code, scripts, and non-program assets make up an "aggregate" under the GPL, but I'm still having trouble figuring out what constitutes "other separate and independent works, which are not by their nature extensions of the covered work, and which are not combined with it such as to form a larger program", if the engine puts specific requirements on those files.
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.
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.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
Until your certificate expires.
A self-signed cert would be perfectly fine for most sites out there. Sure, it's susceptable to MitM attacks, but there's a reasonably big step from "I can eavesdrop" to "I can reroute your connections to me."
The biggest obstacle to this is the horrendous hoops you have to jump through to OK a self-signed cert in browsers.
I run a couple of small FLOSS projects and I have to confess that producing documentation is by far the most painful task that I need to accomplish. It basically demands that you put down in writing something which, as you've just spent a considerable slice of time which may amount to years writing it, to your own eyes is so blindingly obvious to use that you shouldn't be wasting your time writing about it. Adding to that, it's frustrating to document code because as the source code is easily accessible anyone can just fire up a text editor and read it.
To make matters worse, sometimes you are forced to rewrite a portion of your code. When you do that, if you already have some documentation written then you are forced to go back, find any reference to that particular behaviour and rewrite it to reflect your changes. And pray to God that you don't have to yet again rewrite everything all over again (or write a new copy of the docs) to reflect a minor version. Tools like Doxygen do help mitigate this problem but they are only good enough to handle code references, and they do that at expense of filling the project with long winded comments which, if you happen to use an editor which doesn't support code folding all that well, make up reading and writing code a bit needlessly complicated.
Ignoring some other nasty aspects of writing/maintaining a documentation, at least to me documentation boils down to wasting your time. It's a task which doesn't have any noticeable positive feedback and it always feels like you are completely wasting your time with fluff tasks. After all, if you've written an excellent documentation then your users will simply read it and go on with their lives while you never get to hear about it.
But although that's my personal view regarding producing documentation I also understand the need for it. It's extremely important to provide (and also have available) a decent documentation. Without it your users (and sometimes even you) are left disoriented and forced to waste time with basic things. But that won't make the job of generating it any more enjoyable than it already is.
Slashdot, fix your code or at least hire someone who is competent at it to do it for you.
Next question: WTF is RTFM? ;)