I think it's far more likely that AAA games will come to the steambox as a supported option which just happens to give everyone linux support and over time we'll see more and more games and linux being seen as more of a legitimate gaming option just like the transition that OSX went through.

In some respects this has already happened. I couldn't imagine value pushing forward with linux as far as they have without all the humble bundles which have shown that there is a market for linux games. Everything has kind of progressed from there with a lot of indy developers jumping on the linux support bandwagon.

If anyone is interested in elite type games but on planets then you might be interested in helping out on my project.

I have a list of bit sized bugs here: https://openhatch.org/+projects/Hardwar

...or you can just come by the forums and say hi. Even some encouragement would be good. http://forum.hardwar.org/

I've experienced this myself with submitting patches to projects such as bzr-upload. Even though I have fixed a particular issue and proposed my changes for merging it just sits there because the upstream author disagrees with the particular feature that users have been requesting. This case in particular is the ability to allow an upload to continue even though it errors trying to delete files or folders on the server that don't exist. This feature can be useful when your online revision becomes out of sync because someone deleted the file online and then deleted it locally in the repo.

The upstream author disagrees with this "--force" option I added because (as he explains in the bug report) the online copy should always mirror your local copy and if it becomes out of sync you should be required to upload everything again. Many others and I disagree with this line of thinking because it is silly to upload over 1 Gig simply because you deleted a folder or file online.

My point with this little story is that it doesn't just happen to just UI designers in open source projects. It happens to everyone including programmers. If the upstream author disagrees with your changes there's nothing you can do, even though there's a large backing of people who want your UI design in.

I'm leading a project to remake an old game called Hardwar and I'd love to have some professional UI developers to help flesh out the details of my editor UI and Main Menu screen. Right now the editor menu looks horrible however it's not my area of experience.

Should I approach the copyright holder and purchase a license, or attempt to buy the rights outright and transfer them to the open source project/myself/the original creator?

If the game company has gone bankrupt it might be a situation where the company was liquidated and its assets sold. If that is that case then the company no longer owns the copyright.

In any case I doubt it is worth purchasing the copyright. You state that you will be remaking this game from scratch which means purchasing someone else's copyright when you aren't going to use it will be a waste of money. Also you have to take into account that purchasing copyright is very expensive, requires a lawyer and at the end of it you can't really be guaranteed that you own it.

If you wish to use the original name then you should check and make sure any registered trademark has already expired. If it has then you should have no issue naming your game with the same name or something similar.

When making your own version of the game you should make sure that the names of things in the game, artwork, etc are all of your own work. This means they should be different from the original game. Copying how the original game plays shouldn't be an issue however.

If you feel that is not an option and that you need the original names of characters etc in your remake then you could have an expansion pack hosted someone else away from the project which adds the original content. That way if you do get in legal trouble you can pull the offending content without causing any problems where your project is hosted.

Since you're only providing another anecdotal point of view, I fail to see how you can judge his comment to be false.

Because it doesn't sound like the mailing list at all. They do in fact spend the time to explain these things. Here's one of my first patches, where I would get almost everything wrong.

http://www.mail-archive.com/wine-devel@winehq.org/msg50828.html

Well I would fire someone who bases their arguments without any proof. Has Sun provided a link to his patch submission so we can discuss this futher? No.

To quote my post you're replying to...

However, without giving us the link to his patch on the mailing list we have no way of telling.

You would fire someone that demands proof? You sound like a bad manager who bases their opinions on personal feelings.

You are like a Dilbert comic strip. Passing all the tests because there aren't any for the functionality you've implemented is something worthy of a dailywtf submission. Not a software project which consists of millions of lines of code, used on millions of machines and writing to an ever changing specification.

As for your package maintainers comment, it's not going to happen. It's already been discussed to death on the mailing lists that it's a bad idea to have anything but vanilla wine.

The only person who wants a fork is you. You wrote this article, you're the one whining in the comments. If you want a fork so bad make one. I would happily contribute to both your fork and main wine. So go ahead, why haven't you already started instead of wasting your time on slashdot?

4. RTFA: "DIB Engine : Passing all tests"

From the latest discussions on the mailinglist this isn't true..

The engine has still some known bugs (known by me :-) ) which are not spotter
by wine testsuite, mostly related to coordinate spaces in xxxBlt functions.

So yes, it "passes all the tests", but that's only because there aren't enough tests.

The problem is that the maintainers follow a commercial agenda of their own and have to keep Wine crappier than their product.

This is stupid for many reasons however it's what I would expect from you since you're the author who submitted this nonsensical piece in the first place.

If you follow the WINE development at all then you should KNOW that there are numerous hacks that although work should never be committed upstream until they have be properly re-written. Just because code weavers includes these hacks in their release doesn't mean it's better, in fact I would call it worse. Also you can download the code weavers diff any time and patch it to upstream wine. Why don't you submit you own patches if you think something is being withheld. Code weavers will even tell you how to do it.

I would say "Good luck with your fork", obviously it will be a monstrous pile of hacks with regressions in every commit. However, we both know you'll never get that far because you want someone to do the forking for you, otherwise why post this on slashdot?

I've submitted many patches to wine and Alex has always given me good feedback. Without a link to the parent's patches so we can judge for ourselves I would have to say that what Sun is saying is false.

There's a couple of reasons why patches get rejected:
- The code style doesn't match what's in the file
- No test cases are submitted with a function implementation
- The patche's test cases fail on windows

I am subscribed to the mailing list and often see people get frustrated that they have to do more work then just throw code over the fence.

In the case of Sun's patch it sounds like "not pretty" means he either did something like put in C++ style comments or didn't match the coding standard on the file he was editing. However, without giving us the link to his patch on the mailing list we have no way of telling.

If you want to develop a platform independent C++ application you should try the following setup..

cmake - Used to generate makefiles and VS project settings
Graphics - Horde3D, Ogre3D, Irrlicht
Sound - OpenAL, FMOD
Keyboard, Joystick, etc - Open Input System