Functionality vs. Features

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:

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.