Precisely. In a real corporate environment this guy would get fired for even thinking about building his own basic desktop computers. The only way that you can make the equation for building your own desktop computers work is if you have some special need. If you have enough time that you are willing to try and recreate Dell on a small scale what you really need to do to save money is fire some IT personnel.
You might be able to save a bit of money over Dell by building your own machines, but only if you consider your payroll a fixed cost. You can buy a lot of Dell machines at $1000 a pop for what a technician makes in a year.
Microsoft also produces some Free Software. That does not necessarily make them part of the Free Software community. In this particular case Sun gets credit for releasing the source code for OpenOffice.org and Java (and Solaris, I suppose). However, the OpenOffice.org development community has a long history of problems with Sun's stewardship of the project. It is difficult enough to get code accepted into OpenOffice.org that most Linux distributions actually ship code from go-oo.org's fork of OpenOffice.org. This particular announcement only shows that the Free Software community has basically given up on working with Oracle to push changes upstream.
Combine this new schism with the fact that Oracle is suing Google over a Free Software Java-alike (Dalvik, and Harmony), and the recent closure of OpenSolaris, and Oracle is not looking particularly friendly right at this moment.
This might seem like the sort of thing that only "long-haired, bearded hippies" care about, but that's just not the case. Red Hat has basically shown that even Oracle's own customers would rather pay for Linux support from them. Part of the reason that Red Hat wins these contracts is that Oracle's customers know that if they become too reliant on Oracle that they won't be able to shop around for competitive pricing in the future. Red Hat is unabashedly "Free Software" friendly, and Red Hat's customers definitely see that as an advantage worth paying for.
Likewise, if you were considering a move to an alternative office suite right now you almost certainly would be interested in go-oo.org's version (what the new LibreOffice is based on) over OpenOffice.org. Oracle certainly pays developers to work on OpenOffice.org, but so do Novell and Red Hat, and their version, quite frankly, is considerably better than the OpenOffice.org version you can get from Oracle.
My guess is that Sun will continue to work on OpenOffice.org. This is just Michael Meeks and the rest of the folks at Novell, RedHat, and others finally throwing in the towel on working with Oracle. Working with Sun was bad enough, working with Oracle has proven to be impossible.
If you have been getting OpenOffice.org as part of a Linux distribution chances are excellent that you are already using this particular fork of OpenOffice.org. My guess is the new branding is simply going to make this fork explicit.
I grew up in a small town. Pretty much everywhere I went I was recognized in much the same way that frightens you. When I went to the convenience store where I would buy my candy the owner invariably asked if I wanted "the regular." Most people don't seem to mind this sort of behavior. In fact, it is often called "good service."
On the flip side, when I was doing something I shouldn't people invariably threatened to call my father. This might seem disconcerting to someone who has relied on anonymity to keep themselves out of trouble their whole life, but there are some advantages.
Skype's problem is that developing a version of Skype that works on the various popular (and not so popular) versions of Linux is difficult. The Linux market is small enough, and fractured enough, that Skype would just as soon not even try. Unfortunately, Skype is concerned that, if left to its own devices, the Free Software community is large enough to build and popularize a Skype alternative that could compete with Skype. It has certainly done that sort of thing before.
So Skype is providing a SDK that would allow Open Source hackers the ability to build there own GUI front ends for Skype's service. This neatly solves the problem of creating a Linux client that works everywhere, as the preferred method for integrating software into a distribution in the Free Software world is to simply provide source. The idea is to get the Open Source hackers to work out the tricky bits like figuring out which API allows access to the web cam, and which API should be used for audio input/output. The folks working on the various distributions know how this is done, and Skype (apparently) does not.
This is a win for Skype because they get some help in creating Linux clients, and it is theoretically a win for the Open Source community as they get a working Skype client. This still leaves the Free Software guys, the ones that won't use Skype no matter how slick it is, because it is proprietary, to build their own competing service. Their initial reaction would probably be to leverage the work done by the Open Source guys. My guess is that Skype will try and make it so that the license on their SDK will not allow that. However, this is likely to be easier said than done, and that probably explains why the SDK has not actually been released yet. Skype is probably working on the proper license that will allow them to use the Free Software libraries that they need to use, while making it impossible for the Free Software guys to use software created to work with their SDK.
Whether the folks at Microsoft wrote this themselves, or whether they instead paid $1.1 billion for this software 9 years ago it is still pretty much the same thing. Either way this makes the folks at Microsoft look like amateurs. This is precisely the sort of thing that only closed source proprietary software can get away with.
Yes, but it does show the amount of protection that the MPEG-LA license afforded. Absolutely none. Microsoft still had to go pay to defend itself from litigation, it still lost the litigation, and if it wouldn't have been for a judge that was willing to overturn a jury verdict Microsoft would still have been on the hook for millions of dollars.
The MPEG-LA license did absolutely nothing to protect against patent claims from parties outside the pool.
And my point is that Google is going to be paying for legal protection for these codecs no matter who gets sued. That being the case any sane litigant is going to go after Google directly so that if some bits of their case *do* end up in front of a jury they can paint Google as the big bad patent stealer instead of looking like a bully.
A cease and desist order works against VirtualDub and ASF because these "technologies" are basically smack dab in the middle of MPEG-LA's kingdom. The patent holders involved (including Apple and Microsoft) want to force you to pay to use their licensed code and tools. That's essentially the whole point of both Theora and VP8.
If VirtualDub were to get a cease and desist order over VP8 then you can bet that Google would get involved in a big way.
Free Software projects are not likely to be a target in this particular patent battle. Patent lawsuits are expensive, and Free Software projects are unlikely to have the resources to make them workable targets. After all, how do you prove millions in damages from a project given away for free? More importantly, there are plenty of well-funded entities with an interest in protecting Free Software projects in general, and these codecs in particular, from patent attacks. My guess is that if you were sued by MPEG-LA (or whoever) for using of VP8 or Ogg Theora that there would be plenty of companies with deep pockets that would be willing to help pay for excellent legal representation.
You don't honestly think that Google will allow MPEG-LA (or Microsoft, or Apple) to get a precedent setting patent case against some piddly Free Software project that was merely using VP8 (or even Ogg Theora) without at least offering world class legal assistance? It doesn't matter who gets sued over these codecs. Google is going to make sure that whoever it is that gets sued has the best lawyers that money can buy. Suing a Free Software project just guarantees that the patent holders suing 1) look like horrible thugs in front of a jury 2) limit the amount of damages that they can ask for (because the Free Software guy is likely to be much poorer than Google).
In short, there is no upside to suing the little guy, only downside. So if there is a lawsuit it will be against Google, and MPEG-LA (or Apple or Microsoft) would have to be desperate to get to that point.
Talk, on the other hand is cheap. I fully expect a FUD-storm very reminiscent of the one that Microsoft leveled against Linux. Just because Microsoft, Apple, or MPEG-LA say that there are problems, however, does not mean that they are willing to risk a patent war with Google, and that's what it would take to actually back up any threats.
I suppose I can understand the reasoning to a certain extent. Then again I took one of those "remedial classes" (Physical Science) in College and received a perfect score without attending the class a single time. Attending the lectures would clearly have been a waste of my time.
It also seems to me that this simply *adds* an expense, instead of removing one. It is not as if the school is likely to kick a student out after simply missing a few classes. They are going to wait until the end of the semester to take any action. So this plan simply becomes an expensive way to take attendance.
What's more, it leads to what I consider the worst type of college course, the course that rewards you for simply showing up. I would feel differently if the course had a required quiz at the beginning of each lecture. That not only requires you to attend the class, but it also requires that you be prepared and actually learn something. However, it takes some amount of effort to create and grade assignments. Taking attendance is cheap and easy, even if it isn't particularly effective.
The answer to that is simple. If they fail kick them out. That will free up space for other students.
RFID cards don't actually make students go to class, they simply make it easy for the teacher to verify that the student actually attended (or that they at least had the foresight to make sure that their card attended the class). However, assuming that the student can not do well on the assignments and exams without attending class then this information is redundant. If, on the other hand, the student can do well in the class without attending the lectures then why in the world should the student be required to attend?
Sometimes I really wish that I had gone into academia. The idea of being able to get paid for 10 years (or more) before being required to write a single paper seems very appealing.
That being the case my guess is that more and more prestige is likely to go to those researchers that actually gather the necessary data. Doing a brilliant analyses is good and all, but gathering the necessary data is the truly important bit.
No one is asking to see the data before papers can be published. That's a classic straw man argument. The FoI rules specifically cover ongoing research. In this particular case the group doing the research did so little publishing that they were actually closed down. No one is getting paid to analyze this data any more.
The basic rule should be simple. Published papers should include source data. Take as long as you want to publish (of course, if you fail to publish, you'll likely end up in a different career), just don't try and publish your analysis of some data set without actually including the data set in question.
I agree that this project is potentially very dangerous to GNU/Linux as a platform. However, the only thing that Canonical has to do with this is that the hacker in question is using launchpad.net to host his code (or lack of it actually, so far we have a license and a stub readme file).
I like bzr and launchpad, so I can see why he made his choice.
I do not think that Canonical should get involved. Launchpad would be less useful if it tried to regulate what sort of Free Software could be developed on launchpad. If CoApp is to be stopped it should be stopped by not being adopted by upstream projects until such time as it provides some benefit for cross-platform compatibility.
For example, most Free Software projects that create Windows binaries have a build system that they use for Windows and an autotools one (or perhaps some other Posix tool) that they use for everything else. The Windows build system is usually a brain-dead cousin to the autotools build system primarily due to the fact that allows the project to target gcc as the compiler even on Windows. So while the project does have to have Windows compatibility baked in, it does not have to be compiled with Microsoft's compiler.
Of course, what Windows devs invariably want is VS project files and compatibility with Microsoft's compiler, which adds a great deal of complexity. If, however, CoApp was a tool that allowed VS to play nicely with gcc then it would be a different kettle of fish. Windows devs could have their precious project files while still targeting gcc. Sure, it would still be two build systems, but that is what we have now anyhow. The difference is that it would be two standard build systems that every project could use instead of each creating their own custom build system for Windows.
This does not appear to be what CoApp is trying to do, and probably for the reasons that you point out. Microsoft is not interested in making it easier to make cross-platform applications, it is only interested in borrowing code from cross-platform applications and turning the code into Windows-only code.
Because, even if we could get a great POSIX experience on Windows, it leaves out Windows developers.
The problem with this, of course, is that no matter what you do Windows developers aren't going to be able to help the Free Software community because they have chosen to use tools that only work on one platform, Windows.
Heck, the reason that there is a Free Software community in the first place was because they built a set of tools that was specifically designed to be portable to a wide array of operating systems. If Microsoft did not go out of its way to be incompatible this wouldn't even be an issue. Free Software apps build fine on every other proprietary OS on the planet.
One of my goals is to get Windows developers in the OSS game.
It takes discipline to build cross-platform applications, and despite the difficulty of using autotools-style build systems on Windows it is still arguably the best way to do so. If Windows developers were interested in joining the OSS community then they would already be using OSS build systems.
This is not going to get Windows developers to join the greater OSS community, at best it is going to be a method for making it easier to use Free Software on a non-free system. At worst it might actually shift some projects from being autotools dependent (and thus easy to build on GNU/Linux) to being CoApp dependent (and thus impossible to build on GNU/Linux).
Of course, you are free to do what you want with your own time (and Microsoft's money) but don't try and dress it up like some sort of blessing to the folks in the OSS community.
On top of that, there is a hell of a lot of non-POSIX open source software on Windows that needs fixing too.
If your tool aims to make software written for Windows work on POSIX systems then forgive me for my cynicism above. If not, why should the greater OSS community care? If we were interested in Windows-only software do you think we would be bothering with autotools?
Your tool is likely to create a Windows-only sub-community of OSS developers that can borrow from the greater OSS community but that doesn't share with the Linux, BSD, and Mac OS X OSS developers that created the software in the first place. That probably sounds good to your employers at Microsoft, but it doesn't sound like existing OSS developers are likely to get excited about.
Look at it this way: Would you respect someone who told you the best way to get FireFox running on Linux was to use some sort of Windows emulation layer... Like WINE? no, because FireFox *can* compile for Linux. Same thing with nearly all Open Source I encounter. I want to get the OSS quality and experience on Windows to exceed commercial developers... it needs the most love.
People don't like Wine because they use it to run software that neither targets nor tests against Wine. I personally would be perfectly happy with Wine-based software if said software was a first class development target. If the developers ran build tests against winelib, for instance, and accepted bug reports based on wine-derived versions then I don't see the big deal. Heck, in may ways it wouldn't be any different than software that uses a JVM as a platform.
The problem with Wine is not that it is a bad platform, the problem is that it isn't a platform at all. Instead it is trying to mimic a platform. If Wine became the target instead of Windows (or even alongside Windows) then I am sure it could be made into a perfectly acceptable platform for developing GNU/Linux applications.
The problem, as I stated before, is that Windows developers aren't interested in creating cross-platform applications. Free Software developers have created the necessary tools (like Wine or Mono), but Windows developers don't seem to be interested in spending the little bit of extra time that it would take to use those to
Precisely. In a real corporate environment this guy would get fired for even thinking about building his own basic desktop computers. The only way that you can make the equation for building your own desktop computers work is if you have some special need. If you have enough time that you are willing to try and recreate Dell on a small scale what you really need to do to save money is fire some IT personnel.
You might be able to save a bit of money over Dell by building your own machines, but only if you consider your payroll a fixed cost. You can buy a lot of Dell machines at $1000 a pop for what a technician makes in a year.
Microsoft also produces some Free Software. That does not necessarily make them part of the Free Software community. In this particular case Sun gets credit for releasing the source code for OpenOffice.org and Java (and Solaris, I suppose). However, the OpenOffice.org development community has a long history of problems with Sun's stewardship of the project. It is difficult enough to get code accepted into OpenOffice.org that most Linux distributions actually ship code from go-oo.org's fork of OpenOffice.org. This particular announcement only shows that the Free Software community has basically given up on working with Oracle to push changes upstream.
Combine this new schism with the fact that Oracle is suing Google over a Free Software Java-alike (Dalvik, and Harmony), and the recent closure of OpenSolaris, and Oracle is not looking particularly friendly right at this moment.
This might seem like the sort of thing that only "long-haired, bearded hippies" care about, but that's just not the case. Red Hat has basically shown that even Oracle's own customers would rather pay for Linux support from them. Part of the reason that Red Hat wins these contracts is that Oracle's customers know that if they become too reliant on Oracle that they won't be able to shop around for competitive pricing in the future. Red Hat is unabashedly "Free Software" friendly, and Red Hat's customers definitely see that as an advantage worth paying for.
Likewise, if you were considering a move to an alternative office suite right now you almost certainly would be interested in go-oo.org's version (what the new LibreOffice is based on) over OpenOffice.org. Oracle certainly pays developers to work on OpenOffice.org, but so do Novell and Red Hat, and their version, quite frankly, is considerably better than the OpenOffice.org version you can get from Oracle.
My guess is that Sun will continue to work on OpenOffice.org. This is just Michael Meeks and the rest of the folks at Novell, RedHat, and others finally throwing in the towel on working with Oracle. Working with Sun was bad enough, working with Oracle has proven to be impossible.
If you have been getting OpenOffice.org as part of a Linux distribution chances are excellent that you are already using this particular fork of OpenOffice.org. My guess is the new branding is simply going to make this fork explicit.
You are so gay.
Insert Ad for an Automobile.
I grew up in a small town. Pretty much everywhere I went I was recognized in much the same way that frightens you. When I went to the convenience store where I would buy my candy the owner invariably asked if I wanted "the regular." Most people don't seem to mind this sort of behavior. In fact, it is often called "good service."
On the flip side, when I was doing something I shouldn't people invariably threatened to call my father. This might seem disconcerting to someone who has relied on anonymity to keep themselves out of trouble their whole life, but there are some advantages.
Your kids first.
I was curious to see how far down I would have to read before Celko was mentioned. That's the book I would recommend.
Have you tried ConTeXt?
You should consider logging in Mr. Coward.
Exactly, I would be curious to know what sort of "room temperature" tests can tell how reliable something is going to be in 100 years.
Skype's problem is that developing a version of Skype that works on the various popular (and not so popular) versions of Linux is difficult. The Linux market is small enough, and fractured enough, that Skype would just as soon not even try. Unfortunately, Skype is concerned that, if left to its own devices, the Free Software community is large enough to build and popularize a Skype alternative that could compete with Skype. It has certainly done that sort of thing before.
So Skype is providing a SDK that would allow Open Source hackers the ability to build there own GUI front ends for Skype's service. This neatly solves the problem of creating a Linux client that works everywhere, as the preferred method for integrating software into a distribution in the Free Software world is to simply provide source. The idea is to get the Open Source hackers to work out the tricky bits like figuring out which API allows access to the web cam, and which API should be used for audio input/output. The folks working on the various distributions know how this is done, and Skype (apparently) does not.
This is a win for Skype because they get some help in creating Linux clients, and it is theoretically a win for the Open Source community as they get a working Skype client. This still leaves the Free Software guys, the ones that won't use Skype no matter how slick it is, because it is proprietary, to build their own competing service. Their initial reaction would probably be to leverage the work done by the Open Source guys. My guess is that Skype will try and make it so that the license on their SDK will not allow that. However, this is likely to be easier said than done, and that probably explains why the SDK has not actually been released yet. Skype is probably working on the proper license that will allow them to use the Free Software libraries that they need to use, while making it impossible for the Free Software guys to use software created to work with their SDK.
With judicious use of --link-dest rsync can do this for you without having to use cp at all.
Whether the folks at Microsoft wrote this themselves, or whether they instead paid $1.1 billion for this software 9 years ago it is still pretty much the same thing. Either way this makes the folks at Microsoft look like amateurs. This is precisely the sort of thing that only closed source proprietary software can get away with.
Yes, but it does show the amount of protection that the MPEG-LA license afforded. Absolutely none. Microsoft still had to go pay to defend itself from litigation, it still lost the litigation, and if it wouldn't have been for a judge that was willing to overturn a jury verdict Microsoft would still have been on the hook for millions of dollars.
The MPEG-LA license did absolutely nothing to protect against patent claims from parties outside the pool.
And my point is that Google is going to be paying for legal protection for these codecs no matter who gets sued. That being the case any sane litigant is going to go after Google directly so that if some bits of their case *do* end up in front of a jury they can paint Google as the big bad patent stealer instead of looking like a bully.
A cease and desist order works against VirtualDub and ASF because these "technologies" are basically smack dab in the middle of MPEG-LA's kingdom. The patent holders involved (including Apple and Microsoft) want to force you to pay to use their licensed code and tools. That's essentially the whole point of both Theora and VP8.
If VirtualDub were to get a cease and desist order over VP8 then you can bet that Google would get involved in a big way.
Free Software projects are not likely to be a target in this particular patent battle. Patent lawsuits are expensive, and Free Software projects are unlikely to have the resources to make them workable targets. After all, how do you prove millions in damages from a project given away for free? More importantly, there are plenty of well-funded entities with an interest in protecting Free Software projects in general, and these codecs in particular, from patent attacks. My guess is that if you were sued by MPEG-LA (or whoever) for using of VP8 or Ogg Theora that there would be plenty of companies with deep pockets that would be willing to help pay for excellent legal representation.
You don't honestly think that Google will allow MPEG-LA (or Microsoft, or Apple) to get a precedent setting patent case against some piddly Free Software project that was merely using VP8 (or even Ogg Theora) without at least offering world class legal assistance? It doesn't matter who gets sued over these codecs. Google is going to make sure that whoever it is that gets sued has the best lawyers that money can buy. Suing a Free Software project just guarantees that the patent holders suing 1) look like horrible thugs in front of a jury 2) limit the amount of damages that they can ask for (because the Free Software guy is likely to be much poorer than Google).
In short, there is no upside to suing the little guy, only downside. So if there is a lawsuit it will be against Google, and MPEG-LA (or Apple or Microsoft) would have to be desperate to get to that point.
Talk, on the other hand is cheap. I fully expect a FUD-storm very reminiscent of the one that Microsoft leveled against Linux. Just because Microsoft, Apple, or MPEG-LA say that there are problems, however, does not mean that they are willing to risk a patent war with Google, and that's what it would take to actually back up any threats.
I suppose I can understand the reasoning to a certain extent. Then again I took one of those "remedial classes" (Physical Science) in College and received a perfect score without attending the class a single time. Attending the lectures would clearly have been a waste of my time.
It also seems to me that this simply *adds* an expense, instead of removing one. It is not as if the school is likely to kick a student out after simply missing a few classes. They are going to wait until the end of the semester to take any action. So this plan simply becomes an expensive way to take attendance.
What's more, it leads to what I consider the worst type of college course, the course that rewards you for simply showing up. I would feel differently if the course had a required quiz at the beginning of each lecture. That not only requires you to attend the class, but it also requires that you be prepared and actually learn something. However, it takes some amount of effort to create and grade assignments. Taking attendance is cheap and easy, even if it isn't particularly effective.
The answer to that is simple. If they fail kick them out. That will free up space for other students.
RFID cards don't actually make students go to class, they simply make it easy for the teacher to verify that the student actually attended (or that they at least had the foresight to make sure that their card attended the class). However, assuming that the student can not do well on the assignments and exams without attending class then this information is redundant. If, on the other hand, the student can do well in the class without attending the lectures then why in the world should the student be required to attend?
My shirt has Vietnamese food stains, and I am not sporting a neckbeard. I just haven't had time to shave in the last few days.
Sometimes I really wish that I had gone into academia. The idea of being able to get paid for 10 years (or more) before being required to write a single paper seems very appealing.
That being the case my guess is that more and more prestige is likely to go to those researchers that actually gather the necessary data. Doing a brilliant analyses is good and all, but gathering the necessary data is the truly important bit.
No one is asking to see the data before papers can be published. That's a classic straw man argument. The FoI rules specifically cover ongoing research. In this particular case the group doing the research did so little publishing that they were actually closed down. No one is getting paid to analyze this data any more.
The basic rule should be simple. Published papers should include source data. Take as long as you want to publish (of course, if you fail to publish, you'll likely end up in a different career), just don't try and publish your analysis of some data set without actually including the data set in question.
They should be working on a "Somebody Else's Problem" field. I hear that this is much easier than trying to much around with physics.
I agree that this project is potentially very dangerous to GNU/Linux as a platform. However, the only thing that Canonical has to do with this is that the hacker in question is using launchpad.net to host his code (or lack of it actually, so far we have a license and a stub readme file).
I like bzr and launchpad, so I can see why he made his choice.
I do not think that Canonical should get involved. Launchpad would be less useful if it tried to regulate what sort of Free Software could be developed on launchpad. If CoApp is to be stopped it should be stopped by not being adopted by upstream projects until such time as it provides some benefit for cross-platform compatibility.
For example, most Free Software projects that create Windows binaries have a build system that they use for Windows and an autotools one (or perhaps some other Posix tool) that they use for everything else. The Windows build system is usually a brain-dead cousin to the autotools build system primarily due to the fact that allows the project to target gcc as the compiler even on Windows. So while the project does have to have Windows compatibility baked in, it does not have to be compiled with Microsoft's compiler.
Of course, what Windows devs invariably want is VS project files and compatibility with Microsoft's compiler, which adds a great deal of complexity. If, however, CoApp was a tool that allowed VS to play nicely with gcc then it would be a different kettle of fish. Windows devs could have their precious project files while still targeting gcc. Sure, it would still be two build systems, but that is what we have now anyhow. The difference is that it would be two standard build systems that every project could use instead of each creating their own custom build system for Windows.
This does not appear to be what CoApp is trying to do, and probably for the reasons that you point out. Microsoft is not interested in making it easier to make cross-platform applications, it is only interested in borrowing code from cross-platform applications and turning the code into Windows-only code.
The problem with this, of course, is that no matter what you do Windows developers aren't going to be able to help the Free Software community because they have chosen to use tools that only work on one platform, Windows.
Heck, the reason that there is a Free Software community in the first place was because they built a set of tools that was specifically designed to be portable to a wide array of operating systems. If Microsoft did not go out of its way to be incompatible this wouldn't even be an issue. Free Software apps build fine on every other proprietary OS on the planet.
It takes discipline to build cross-platform applications, and despite the difficulty of using autotools-style build systems on Windows it is still arguably the best way to do so. If Windows developers were interested in joining the OSS community then they would already be using OSS build systems.
This is not going to get Windows developers to join the greater OSS community, at best it is going to be a method for making it easier to use Free Software on a non-free system. At worst it might actually shift some projects from being autotools dependent (and thus easy to build on GNU/Linux) to being CoApp dependent (and thus impossible to build on GNU/Linux).
Of course, you are free to do what you want with your own time (and Microsoft's money) but don't try and dress it up like some sort of blessing to the folks in the OSS community.
If your tool aims to make software written for Windows work on POSIX systems then forgive me for my cynicism above. If not, why should the greater OSS community care? If we were interested in Windows-only software do you think we would be bothering with autotools?
Your tool is likely to create a Windows-only sub-community of OSS developers that can borrow from the greater OSS community but that doesn't share with the Linux, BSD, and Mac OS X OSS developers that created the software in the first place. That probably sounds good to your employers at Microsoft, but it doesn't sound like existing OSS developers are likely to get excited about.
People don't like Wine because they use it to run software that neither targets nor tests against Wine. I personally would be perfectly happy with Wine-based software if said software was a first class development target. If the developers ran build tests against winelib, for instance, and accepted bug reports based on wine-derived versions then I don't see the big deal. Heck, in may ways it wouldn't be any different than software that uses a JVM as a platform.
The problem with Wine is not that it is a bad platform, the problem is that it isn't a platform at all. Instead it is trying to mimic a platform. If Wine became the target instead of Windows (or even alongside Windows) then I am sure it could be made into a perfectly acceptable platform for developing GNU/Linux applications.
The problem, as I stated before, is that Windows developers aren't interested in creating cross-platform applications. Free Software developers have created the necessary tools (like Wine or Mono), but Windows developers don't seem to be interested in spending the little bit of extra time that it would take to use those to