The problem isn’t getting updates. It’s getting them accepted. Most projects will outright deny your changes.
Wow, already thinking about something like that.
I was thinking about project mantainers opening a tip jar with a price tag for each requested feature. For instance, sometimes users complain that a software doesn’t run on a particular version of a commercial OS. Mantainers could open a tip jar with a tip jar with a price tag matching that of the requested OS plus maybe a dedicated development machine.
Besides FAQ section, projects could also have a FAF (Frequently Asked Features).
If people who manage to make a fix would also try to fix compilation issues for their own platform, we could manage to reach the point where you just download, fix, compile, test and upload in a snap.
I understand that developing a way to deal with dependencies automatically could be - it is! - quite messy, but you know, computer can do the dirty work when given proper instructions.
Cheers
@PRMan
Once you put in the initial effort to get a codebase to compile, you generally don’t have to do it again. So your first bug-fix is 8 hours + 5 minutes, and the next one is 5 minutes.
Just about every codebase I’ve ever worked on that I didn’t write myself from the start has taken some up-front effort to configure, from an hour or two to a day or two. If you expect to spend some time with it, then that’s just some startup overhead. It’s only a problem if you just want to dive in, fix one thing and then stop working on the code.
And, Lele’s right – bad configuration experience is a bug, and if it itches too badly, scratch that itch and share it, and all benefit!
Reminds me of Horde project’s bounty system. They encourage contribution to their open-source code base by having 3rd party sponsorship for specific features. I have no idea if it’s at all successful but it always seemed like a good idea to me.
@Everett, re: blurry font
I had this problem as well, and ended up deleting the Calibri font (which I don’t use) from my Fonts folder. The site will then use Tahoma, which looks much better on my system.
The idea of providing priority support on an open source project is nothing really revolutionary. It’s a whole business model around open source.
I’m creating a threaded comment module for the Elgg social networking web application because I really need that feature. However, I only feel capable of contributing to web applications. Hmm, maybe I should create an aggregated sponsorship system and take a cut of the fund pool. Ka-Ching!
PRMan hit the nail on the head.
Downloading the devenviroment, all dependencies for the devenviroment, all dependencies for the project and then configuring the project often takes over a day.
All for a bugfix that could take 5mins to fix.
As someone who dabbles in the world of Free Software, I think the whole money == new feature idea is not always the right way to think about things. Most of the time the projects are coded in spare time at the weekends or at night. Money is not a factor, unless you can pay someone a full time salary to hack on new features. They already have a job, so don’t need paying.
Look at Beautiful Soup. From 3.1 onwards the author basically said this is no fun any more and abandoned it. Not because of lack of funds, but because of lack of time and lack of will. In the Free Software world, not everything is about cash. If you code the feature yourself, you are basically donating time to the author. And time is often far more valuable than any monetary donation.
And, Lele’s right – bad configuration experience is a bug, and if it itches too badly, scratch that itch and share it, and all benefit!
See? See that? That’s a F*ck you. Right there!
Get your stuff straight and they will come, but don’t ask me to fix your own project’s configuration experience. Or just say it upfront that you don’t give a crap about contributions from developers that work on Windows boxes.
So what if I come up with some VS (VS6, VS7, etc.) project files. And then what? They’ll be outdated in two weeks. Am I supposed to maintain them now? I don’t want a full time job. I just want to contribute a bug fix or two.
Val, I’m fully aware I’m coming off harsh but the more we air out these grievances, the better for the FOSS paradigm. It is my opinion that OS project owners should make the feature make it easy for casual contributors to contribute the top priority at all time, no exceptions, and devote as much time as needed to keep it that way. Yeah, sure, it’s not as fun as writing code but, honestly, do you expect casual contributors to do stuff that isn’t fun?
If you want me to code it myself then you remove the barriers. Or stop pretending.
I think (from experience) every open source project would be helped by a certain amount of money.
There is a threshold of usefulness–small donations aren’t useful. $10,000 can be useful. $100,000 is definitely useful.
Every project has to decide for itself how to deal with money:
-
If it’s a one-man project, no problem–the guy takes the money, and implements the feature.
-
But for other projects, if you just give them money, they have to have some process or system to deal with it. This only really works when that process is already in place, I think. So if there isn’t such a process, and all you care about is specific features or bug fixes, it’s normally more effective for a large donator to hire a contractor out of the pool of existing contributors to actually do the work, as long as you alone can afford that.
-Max
This idea already exists in the Perl community
This is a good idea. I see it as a Kiva style thing, people investing money in a project, and those that work on it receive money. It would obviously be a lot more complicated, but it’s an interesting idea to ponder.
atwood didnt like expertsexchange.com so he coded stackoverflow.com
Very interesting, Jeff!!
There’s a related thread on ALT.NET group that may interest you BTW (It’s still in beginning. Things are not warm enough yet).
Public radio and public television in the US have been doing this for decades.
People pledge small amounts, and the station pays for content bought from producers. Some producers specialize in public [radio,tv] types of content. Others don’t.
Key points:
small individual contributions are aggregated for larger effect.
the producers themselves are not the ones doing the fund-raising.
technical personnel are only involved in their technical capacity.
you have to make a convincing argument, either with the content itself or the people soliciting donation.
Stations even rate their content by the amount of pledges it brings in. On radio, Car Talk and Prairie Home Companion are super popular. Even though you can get the content itself on the web, for free, people still donate to support it on radio.
Other public-supported groups, like botanical gardens, have fund-raising drives for specific purposes. In short, the contributions are earmarked for only that purpose. That’s how vote for bugs should be done: contribute to the bugs you want, and your funds are earmarked for that, no matter how long it takes.
Seriously, the problem itself has been solved. It’s all in the logistics of deploying it for particular goals: radio, TV, or software.
Programmers don’t own PR degrees usually, neither do users. It shows from both sides.
If you can’t program yourself, go rent a coder. Guess, you have just to Google for it.
Maybe that’s true, in most cases. OTOH, a fix must be tested, and if the project lacks a good test suite, it can be not worth the trouble.
One thing that many people are missing is that many open source projects are not simple science experiments that some geek gemmed up in their basement, but a tool developed to help someone solve a bigger problem (Ruby on rails for example). The code had to be developed in the first place and it has to be maintained afterword. They could have saved the framework code internally, but then they have two problems: #1 THEY have to maintain everything themselves #2 There is no preexisting talent pool available from which to draw resources to grow their internal talent pool.
To extend this… If you build code and thousands of people start using it, you get a bunch of free (and often vocal) beta testers. You also get a few dedicated geeks (1 in a thousand maybe) who will dig in and also tell you where a problem lies or they will build a new feature for you.
What’s the downside?
I often want to fix things myself, but often use a different language to one I use normally (PHP). Big projects have a lot of internal structure. Often you don’t have the latest version so you need to check out the dev. version re-test (often has the same missing the same feature and has the same bug). Which all adds a lot of time.
The main coders could probably do what I want in a short amount of time, so paying them is probably a good idea.
However, I can see some problems with giving them money. Unless there is steady stream of requests coming in or a request has a bounty 5 figure sum attached it’s not like they are going to get time off their day job and contracting someone is probably not worth the overhead. The person could be a contractor, but I doubt many of those are open source contributors in their spare time and probably only do it when related to their contracting - in which case you can contract them.