I have been using free software for years now and here is a pattern that could be noticed. Many projects suffer greatly of priorities not being set from very beginning.
I have been using free software for years now and here is a pattern that could be noticed. Many projects suffer greatly of priorities not being set from very beginning.
I have been using free software for years now and here is a pattern that could be noticed. Many projects suffer greatly of priorities not being set from very beginning.
For instance let's look at bochs (http://bochs.sf.net). It's an open source x86 PC emulator - free alternative to VMWare and some other commercial products. Project offers feature list that is far superior to VMWare one. However, there is a problem. VMWare is more or less full implementation of virtual x86 computer. Bochs only provides some (most) standard features, thus chances are that your software may not function correctly under it. Recently, original developer joined current development team and there has been lots of progress including performance optimizations and support for upcoming AMD's Hummer processor. However, some basic features are still missing.
Would it not be logical to first iron most essential features then continue working on new ones? What is better, feature-full alpha or modest release quality product?
If you think bochs is missing something you want, go ahead and add it -- I'm sure they'd value your contribution. If they don't, then fork it if you must. If you don't have the skills, maybe you could pay someone to work on the features you'd like to have.
Projects' priorities are set by the people working on them. If they're more excited by emulating the Hummer than by making your software work, tough beans for you.
Say you have 3 developers who want to work on hammer support - you cant force them to work on the basics
My answer to "quit whining" is simple.
I was not ordering developers to take one avenue or the other; although unless free software becomes useful to end users, it's nothing more than a game. There are several bochs-like products - VMWare, VirtualPC and Simics. Simics license starts @ $10,000, VMWare cost is around $300. Feature-wise bochs is somewhere in the middle.
However, people who use bochs are mostly those interested in hacking it. Nobody orders anyone to convert smart toy into quality software. Kevin who originally developed bochs did not mind money Mandrake offered and was/is recently out of job. I am sure if team would get product fixed, most commercial end-users would not mind some kind of donation. I think $1,000 would not be unreasonable.
In that case everybody wins, but it does require moderating talent and seeing who your consumer is.
If you want some features, and unwilling or unable to implement them yourself, a fine option is to offer someone else money to do it for you. I think I heard you almost offer US$1,000. Try to specify a reasonable feature you want, and put up the offer on the developer list.
I really doubt many developers will be impressed by a "if you implement this and give it away for free, someone will spontaniously offer you money" argument. I'd want to see the money first, before working on someone elses problem.
Bochs and VMWare are two different things, if you want an x86 only x86 emulator (which is what VMWare is), there's Plex86 (by the same person as bochs). Plex86 is faster because it doesn't have to emulate the entire x86 (but needs some kernel patching).
Bochs and VMWare are two different things, if you want an x86 only x86 emulator (which is what VMWare is), there's Plex86 (by the same person as bochs). Plex86 is faster because it doesn't have to emulate the entire x86 (but needs some kernel patching).
...is a bad idea IMHO.
First most projects are not organized enough to recieve money. They'd need to come up with some form of legal backing or you can only give money to individual developers and hope they'll pass it on to worthwhile purposes (like paying for the servers and domains or some pizza), you might even get into hassles explaining what your company did with handing money to a individual.
A few bucks definitly are a motivation ("We recieved 100 bucks, folks, someone is really thinking we are worth it."), but not much more.
Think about what a typical samll project can do with money:
Maybe I am missing something, but I'd allways go for paying someone to implement the features I need and then contribute the code to a projects than give money to a project directly. If I had lots of money on my hands and urgently needed to get rid of it I'd organize a meeting for the most important developers... or ask one of my employees to work on the project, such sponsoring the project with one fulltime devleoper.
The situation is of course different if there is some additional cash flow into the project (other donations, companies backing it, etc.), but that ususally only happens to the big fishes in the pond...
Regards, Tobias
PS: In your place I'd file 20 bug reports of the things most annoying to me and offer 50USD for each of these bugs fixed;-)
Paying $US1000 / year on it's own obviously isn't going to be enough. How much would "enough" be? Would you sign a promise: "I would pay $US1000 / year if $US100,000 / year were contributed by others, to the cause of making Bochs generally useful and reliable."?
Are you worried about accountability of such a promise? Would you prefer to assign an independent judge? What kind of promise would you sign?
You can read more about the Rational Street Performer Protocol, the Street Performer Protocol and the Wall Street Performer Protocol.
As you've gathered from the thread, you're asking the wrong question when you ask for your set of features to work properly, but you are also absolutely right in that open source methodology does not prioritize.
Industrial methodology prioritizes, yet most often industrial methodology also misses the mark or badly implements essential features. It's important to keep that in mind. It's not the methodology that is at fault: You can pay people to implement what you want, but if you pay the wrong people, you end up with something you can't use. 2/3rds of all proprietary projects fail in the first 6 months, 2/3rds of what remains fail within the following 2 years, and of that 10% who actually become products, well, just take a look at an old MicroAge catalog and you tell me how many of them can bare the harsh realities of the Real World.
What can you do? Same as any software shop: You do your best. And you consider any working parts of the code you inherit to be a bonus, free stuff, standing on the shoulders of both giants and dwarfs. The point is, if you found a company to complete dev86, maybe all the hard parts are left to write, but you still get all the rest of the labour completely gratis and that puts you ahead of the proprietary shop that tries to re-invent the whole thing in a clean room.
There are many precidents for this. WINE has seen much progress, especially in the compatibility libs (used to write new portable code) because the Big Money behind Corel and others needed it. Corel was faced with porting their office suite to Unix, or just moving WINE far enough to do just that much. Yes, WINE still won't run the software I need, but that is not the point: Without WINE, I still can't run that software, so who cares. WINE's brokeness for my needs is irrelevent -- as it turned out, the Crossover plugin showed up to solve half my WINE needs.
I meant bochs/plex86, not dev86. I believe dev86 is an assembler, but the same rules probably apply
Free software is (for the most part) a volunteer activity that falls somewhere between barn-raising and amateur scientific investigation. Although you can expect a sincere effort that may or may not be useful to you, the benefactor of free software, you have no particular right to expect a thoroughness or timeliness that is competitive with what fully funded professionals can accomplish.
Even still, the worry that free software will never amount to anything is misplaced. True, progress may be much slower than projected during the glory months when open-source hype got logically concatenated to the speculative reasoning driving the Internet boom. But open collaboration, given time, has a structural advantage over closed efforts that can't be erased.
The real problem in the open-source community is the shortage of (volunteer) second-generation programmers, those willing to evolve and perfect foundations laid down by others. Perhaps because, even though the job is as difficult or harder, it has far less perceived glory.
Sej: I think you're being overly pessimistic.
Even though most free software development is voluntary, there are enough [ill publicised] examples of commercial free software success to suggest free software can be done by "fully funded professionals". Even within projects that are volunteer-driven. See my links above for some examples.
Wrt second-generation developers, my experience has been there are lots of enthusiastic hackers who are willing, but the barrier to joining a project seems to be higher than starting afresh. Less low-hanging fruit to pick, but lots of code to learn.
New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.
Keep up with the latest Advogato features by reading the Advogato status blog.
If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!