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
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.
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()?
In developing (I work with a company doing _mostly_ web-based applications; perl, php, asp, all that gibberish) I steer clear of projects and software with a troublesome license. I am very pro-open source, I am very pro-freedom, and I am very pro-FREE FOR NON-COMMERCIAL USE, so don't get the wrong idea, but I mainly steer clear of anything GPL when it comes to the point of including GPLd software in the projects I work with. Simply: it spells nothing but trouble to me. Please do discuss, debate, don't just f***ing go all nazi gpl/linux/grandma on this by modding it "troll".
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
The blog was cross-posted to asheesh.org. Lets slashdot them too!
Don't bother with IRC. Insist on email instead.
Then train a bayesian classifier (bogofilter) to answer the questions for you.
You just have to remember Bayesian classifiers are good at yes/no classifications (e.g. spam/notspam), so I have several corpuses and test incoming emails serially against them, tagging with the ones which match. Then process the email according to the tag. FAQ should be fairly easy. Use a procmail rule to answer, "thanks for your question, please have a look here".
Deleted
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.
Someone avoided performance optimizations on openhatch.org
If you have tough time deciding if you should do those, ask slashdot - that will clear up things!
I think the answer is obvious - what most developers avoid like the plague is documentation.
#DeleteChrome
Working on fixing the site...
|/usr/games/fortune
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.
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
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
The "app store" concept might help a lot in this regard.
Not to mention that the op is suggesting that one fights fir with fire, which would normally result in the fir being summarily consumed, immolated, if you will.
Unless the original fire is extremely small AND the fir is extremely green.
hth,
> 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
My CS undergrad program has UI design as an obligatory second year course.
Emotions! In your brain!
The situation, of course, is that a player might simply lie about not knowing where enemy units are, or might substitute a different map, or might lie about which units he has killed or where his units are located.
When it comes time to show the cards (we will ignore the issue of exchanging cards; this is also possible to do, using a similar procedure), players 1 and 2 simple reveal their secret keys -- thus, cheating is easily detected, because player 2 can see if player 1 lied about his hand, and visa versa.
I don't think your plan would help detect players whom lie about enemy units.
Assuming the whole point is the actions are public but some items are hidden, and you want to prevent substitution, you'd just hash, sign, and share your interpretation of the gameboard at each move, and then at the end, when its time to reveal the board and tally up and see who won, you reverse engineer what the board should be at each step working backwards, recompute the hashes, and make sure the provided and calculated hashes match, and the sigs are valid? That would catch any odd substitutions that you mention.
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
You could make documentation....
One of the reasons I avoid all this open source stuff is that most of it is badly documented, and quite often there is an almost hostile tone towards people "Just learn unix you scrubs" - no thank you.
If you want your stuff to be used by a lot make simple instructions and a userfriendly interface - if you just make it for your self feel free to ignore this.
If Google really cared they would fix Android Chrome to reflow text, instead of discriminating
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.
You can't handle the truth.
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.
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.
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.
Yes, precisely. Did you actually *do* it?
You’ll get back the following:
@(#) Copyright (c) 1983 The Regents of the University of California.Incidentally, on my FreeBSD server at home it shows a bit more up to date code:
strings /usr/bin/ftp | grep California
@(#) Copyright (c) 1985, 1989, 1993, 1994
The Regents of the University of California. All rights reserved.
Notice how the ftp in Windows predates the first copyright in FreeBSD. That copyright, 1985 also pre-dates the first open source version. The first open source version of BSD was Networking Release 1, which was released in 1989, and did in fact contain a 1989 copyright.
If you need web hosting, you could do worse than here
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:
--- Asking inconvenient questions for over 30 years...
contributing.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
So were those! Pattern, perhaps?
Random Thoughts From A Diseased Mind (Not For Dummies)
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? ;)
There are FIVE words!
That should be in the FAQ.