The OP is much more detailed but reminded me of a project I thought about some time ago: A site to match people with skills willing to put time in open source projects and the projects that need them, like how a dating site works, or Google Summer of Code.
I have a script somewhere laying around which does something similar for Gentoo: You give it a package and it will download and prepare it to some directory, then let you edit it, then compile it (via the Gentoo ebuild) and test it and you can repeat those last steps until you have fixed/changed what you wanted to do. And then it will return a final patch in the end.
I thought this was quite useful. I made quite a few patches this way and was very productive using this script (in some cases, it took me only about 2-5 minutes to prepare a patch if the fix was easy).
Though, the script was very hacky and it still often needed some hand-work to be made. I asked some Gentoo developers if there might want to make a full project out of this (because I thought that this might be a useful and important thing) but nobody really was interested.
The problem that the author describes is certainly a real one. If you want to hack on an open source project, it is sometimes tricky to figure out how to get the source and dependencies and then build the thing. Still, surely the actual process of learning the codebase and making changes to the code involve far far more effort for any non-trivial open source project. So you can make it easy to get started hacking the code but that's only a small part of the overall process.
True, but I guess I was thinking about basic things like crashes. Crashes tend to be among the easiest bugs to fix (you don't need to know that much about the codebase, you just need to know why there was a null pointer when it wasn't expecting one, for instance), and they're among the most annoying. This may not be the best setup for adding features. Anything in between, that's an interesting question I guess.
Nice! I'll keep it in mind. I agree (as I mentioned at the end of my post), if it already exists it should just be promoted. Perhaps a bit of a wrapper could be built too, but it's not bad as it is.
So, sorry, just to be clear, what does the ... mean?
"Fill in the blank" (it's a Unicode ... if it's not showing up for you). i.e. tar xzf /usr/src/packagex.1.2.3.tar.gz; diff -u the/file.c.orig the/file.c; etc.
Granted, tar & diff are the two steps which could most stand to be streamlined (and are by your git approach), but at least they're nothing earth-shattering.
Wait, where does the "bugreport" command come from? I'm running Lucid and it doesn't work. Searching for it on http://packages.ubuntu.com/ doesn't seem to render anything. Do you mean apport?
I have found it is extremely problematic to contribute to open source. The reasons are good ones though and the problem not solvable.
A typical open source experience for me (some 90% of cases) is I download a package, compile it, and it doesn't compile. Something is missing or it can't handle the latest version of the OS, or there is some library with the wrong version.
Now fixing it can take 1 hr to 6 months of work and you don't have any idea before you start.
The answer for me now is "why bother" and I stop there. In general it saves money to buy commercial software that does the exact same thing rather than figure this stuff out for 9 out of 10 open source downloads.
In the past I would fix the problem and try to submit a fix. Wrong answer! You can't submit a fix. Most projects won't accept it unless you join their cult, endure hazing, chat about politics and accept their belief system, and adulate their leaders and trolls.
Not worth it at all.
edit: Thanks for the downvotes. Do you really feel the above contributes nothing, or do you just not tolerate those who point out there are serious problems with the ability of non-project members to make open source contributions? I assure you these are real problems. I also am not surprised that anything other than adulation of Stallman's testicles is furiously downvoted by basement denziens.
>A typical open source experience for me (some 90% of cases) is I download a package, compile it, and it doesn't compile. Something is missing or it can't handle the latest version of the OS, or there is some library with the wrong version.
This, and a bit more, is what I'm hoping can be eliminated here.
As to the rest of it, I guess I never got far enough to find out. I hope it's not always true :( I don't see the point of voting you down either, if it's true it's true.
I also am not surprised that anything other than adulation of Stallman's testicles is furiously downvoted by basement denziens.
Truth is you'll get a better reception without pointless angry tripe.
I've no way of knowing what your OSS experiences have been, so I'll take you at your word. However, a broad statement such as this:
"Most projects won't accept it unless you join their cult, endure hazing, chat about politics and accept their belief system, and adulate their leaders and trolls."
... strikes me as patent bullshit. Maybe most projects you've tried to contribute to have turned out this way, but then I have to wonder if the problem is with the project owners or if maybe you approach things with an incredibly dismal attitude.
Some project owners and communities may suck, but most? You'll have to provide something more than bitter anecdote.
The biggest problems I've had with OSS projects is not getting an answer to questions. There are a good number of "works for me" code repos that simply refuse to build on my system no matter what dependency dance I do. If that's the case I go look for an alternative (though on Linux it's typically not something I can purchase).
Mostly I get things to almost work and get stuck, and then join a forum or mailing list or something to get some help.
Help tends to be of two forms: None at all, or friendly and pragmatic.
I've offered patches to a few projects, and everyone has been very nice about it, even when I forget to include unit tests or fucked up their coding convention. Maybe I've just been lucky.
As the maintainer of several OSS projects I empathize with those I contact for help ro offer patches. Time is often short, and most people aren't getting paid to support their OSS projects.
Most of this is all a gift, and when a gift turns out to be not quite what you hoped for better to just move on and be grateful for you have, not bitter about what you didn't get.
A typical open source experience for me (some 90% of cases) is I download a package, compile it, and it doesn't compile. Something is missing or it can't handle the latest version of the OS, or there is some library with the wrong version.
If you're using Debian stable or Ubuntu, in almost 100% of cases, you can get things to build. apt-get source and apt-get build-depends will get the exact source code and prebuilt dependencies that were used to build the exact binary you are running. Gentoo is presumably even better, since they don't even distribute binaries. And, of course, anything in an interpreted language lacks this problem.
Most projects these days have public bug-tracking systems where you can post your patch. Then anyone else who has the same problem or wants the same feature can use your patch, even if it hasn't been accepted.
We're hoping to help this a bit at Alt.Net 2011. I'm co-organizer and we've been pushing hard to get several quality OSS project leaders to come and use our conference as a platform to gain collaboration. We've got one last one to add from Cheezburger Network but see the list here: http://altnet2011.heroku.com/oss
21 comments
[ 2.8 ms ] story [ 61.5 ms ] threadIs there such a thing, is this a good idea?
I thought this was quite useful. I made quite a few patches this way and was very productive using this script (in some cases, it took me only about 2-5 minutes to prepare a patch if the fix was easy).
Though, the script was very hacky and it still often needed some hand-work to be made. I asked some Gentoo developers if there might want to make a full project out of this (because I thought that this might be a useful and important thing) but nobody really was interested.
I love that there are communities where "regular user" and "coding skills" overlap.
apt-get source packagex
apt-get build-dep packagex
tar xzf …
code code code
dpkg-buildpackage
diff -u … > patch.diff
bugreport -A patch.diff packagex
The functionality's all there; all that's really needed is a FAQ pointing it out.
So, sorry, just to be clear, what does the ... mean?
Granted, tar & diff are the two steps which could most stand to be streamlined (and are by your git approach), but at least they're nothing earth-shattering.
A typical open source experience for me (some 90% of cases) is I download a package, compile it, and it doesn't compile. Something is missing or it can't handle the latest version of the OS, or there is some library with the wrong version.
Now fixing it can take 1 hr to 6 months of work and you don't have any idea before you start.
The answer for me now is "why bother" and I stop there. In general it saves money to buy commercial software that does the exact same thing rather than figure this stuff out for 9 out of 10 open source downloads.
In the past I would fix the problem and try to submit a fix. Wrong answer! You can't submit a fix. Most projects won't accept it unless you join their cult, endure hazing, chat about politics and accept their belief system, and adulate their leaders and trolls.
Not worth it at all.
edit: Thanks for the downvotes. Do you really feel the above contributes nothing, or do you just not tolerate those who point out there are serious problems with the ability of non-project members to make open source contributions? I assure you these are real problems. I also am not surprised that anything other than adulation of Stallman's testicles is furiously downvoted by basement denziens.
This, and a bit more, is what I'm hoping can be eliminated here.
As to the rest of it, I guess I never got far enough to find out. I hope it's not always true :( I don't see the point of voting you down either, if it's true it's true.
Truth is you'll get a better reception without pointless angry tripe.
I've no way of knowing what your OSS experiences have been, so I'll take you at your word. However, a broad statement such as this:
"Most projects won't accept it unless you join their cult, endure hazing, chat about politics and accept their belief system, and adulate their leaders and trolls."
... strikes me as patent bullshit. Maybe most projects you've tried to contribute to have turned out this way, but then I have to wonder if the problem is with the project owners or if maybe you approach things with an incredibly dismal attitude.
Some project owners and communities may suck, but most? You'll have to provide something more than bitter anecdote.
The biggest problems I've had with OSS projects is not getting an answer to questions. There are a good number of "works for me" code repos that simply refuse to build on my system no matter what dependency dance I do. If that's the case I go look for an alternative (though on Linux it's typically not something I can purchase).
Mostly I get things to almost work and get stuck, and then join a forum or mailing list or something to get some help.
Help tends to be of two forms: None at all, or friendly and pragmatic.
I've offered patches to a few projects, and everyone has been very nice about it, even when I forget to include unit tests or fucked up their coding convention. Maybe I've just been lucky.
As the maintainer of several OSS projects I empathize with those I contact for help ro offer patches. Time is often short, and most people aren't getting paid to support their OSS projects.
Most of this is all a gift, and when a gift turns out to be not quite what you hoped for better to just move on and be grateful for you have, not bitter about what you didn't get.
If you're using Debian stable or Ubuntu, in almost 100% of cases, you can get things to build. apt-get source and apt-get build-depends will get the exact source code and prebuilt dependencies that were used to build the exact binary you are running. Gentoo is presumably even better, since they don't even distribute binaries. And, of course, anything in an interpreted language lacks this problem.
Most projects these days have public bug-tracking systems where you can post your patch. Then anyone else who has the same problem or wants the same feature can use your patch, even if it hasn't been accepted.