Microsoft wants apps to be portable to Windows. If they could create a project that allowed people to migrate autotools built apps to a Windows build system that would be a huge win. Especially if there was no way to go back to autotools.
The danger, for Free Software anyhow, of this system is that currently most of the actual development of Free Software applications is done with Free Software tools, and those Free Software tools pretty much assume a Posix API. That is true even when most of the folks actually developing the tools are using Windows systems. Free Software developers working on Windows invariably end up with a whole pile of specialist tools like MingW and Cygwin that are basically designed around getting the GNU build toolchain to work on Windows.
If this project works, then the pressure for Windows to be Posix-like so that it can run the GNU build tools goes away. Instead you simply fire up this new Windows translator and kick out VS project files from your autotools files. Notice that this tool is very likely to be one-way only, autotools to VS studio projects. Unless it is perfect every time (and if it has to try and read autools files that is very doubtful) the Windows devs are very likely to simply use the tool once to generate VS project files and then modify the VS project files going forward. Microsoft is probably hoping that, at least in some cases, the folks maintaining the autotools part of the build system will get lazy and fall behind in the same way that many Free Software projects do now when it comes to building on Windows.
Personally, I doubt that Microsoft is going to get anywhere near that lucky. I also think that, to the extent it tries to build using Microsoft's compiler, it is unlikely to be very successful. If this tool created a straightforward way to simply building for Windows with gcc then lots of projects would be interested as it would free them up from building their own custom system for building on Windows. Currently there are nearly as many ways to build Windows binaries as there are Free Software projects that build Windows binaries. However, for many projects maintaining compatibility with Microsoft's compiler is a non-starter. They have something that works with Mingw (or cygwin, or djpp in some cases) and they are happy to stick with that.
I just want to make sure I understand what you are trying to do.
The aptitude and Windows equivalent of the Debian repository sounds like a no-brainer. Microsoft should have done this 15 years ago. There is nothing the slightest bit controversial there. Assuming you can get enough packages in your repository to make it worth anyone's time, this is sure to be a smash hit.
However, in order for your plan to work, you need a source of Free Software packages for Windows. Apparently you are planning on doing this Ubuntu-style (to the point where you plan on using bzr and launchpad.net). In other words you are going to have a shallow branch of every package that you wish to include in your repository, and each branch will contain the build information necessary to build the package and format it according to your specifications. In fact, it would appear that you are planning to build tools that take autotools-style build systems and turn them into something that Microsoft's tools can use.
That is a tall order. In fact, if your tools get even remotely close to being able to do that for the five (or so) variations of Windows that people find to be interesting, then I would not be surprised if the UNIX people don't borrow your tools to help them migrate away from Autotools. No one actually likes Autotools. And let's not even get started on what your system is supposed to do with projects that use alternate build systems like cmake, scons, or whatever else.
Of course, such a repository would be useful even if it only worked for a handful of applications, which you could probably handle in a mostly manual fashion. After all, most Free Software does build on Windows already if you poke it hard enough. It doesn't tend to build with Visual Studio, of course, so playing nicely there raises the bar considerably.
I do have one question. Why, exactly, do you think that this sort of approach is likely to be easier than doing what Apple did and simply exposing a Posix API that is actually useful?
If the danger to Mono is so obvious, then please point out the patent numbers that Microsoft owns that would apply to Mono (and that don't, at the same time, apply to Free Software tools like OpenJDK, or gcc). Additionally, you should only use patents that don't apply to the ECMA specification.
What? You don't have access to such a list? Imagine that! My guess is that this is because (to my knowledge) no one has come up with such a list of patents. It is possible that you have access to such a list--in which case your accusations could *potentially* stop being FUD. Until then, however, you have no evidence that Mono is particularly vulnerable to attack from Microsoft.
Microsoft has already stated that it believes that Linux (for example) violates hundreds of its patents. In fact, it has even signed patent deals that supposedly cover Linux. Patent attacks on Linux are definitely not FUD. Should I stop using Linux as well?
If Mono is a trap, then it is quite likely to be the stupidest trap in the history of the world. At the very best Microsoft could force the Mono developers to be less compatible with.NET. Since Mono is not particularly compatible with.NET in the first place this is hardly a huge threat.
The Java trap doesn't really apply to Mono. The real problem with Java was that developers tended to use non-free Java tools even when developing for and on GNU/Linux. That's not the case at all with Mono. In fact, there are any number of Free Software projects written in Mono that will not run on Microsoft's.NET because they use GTK# or other Mono-specific extensions.
Besides, it is not as if the GNU project doesn't have it's own C# tools. Take a look at DotGNU, for instance. If Mono is so bad, then where does the FSF get off supporting DotGNU as an official GNU project? Heck, if you search on gnu.org you will even find several comments by RMS himself about the glowing promise of Mono. Take This one, for example.
When push comes to shove RMS' real issue with Mono is that he'd rather have you write your Free Software in C (or guile). The rest is pure FUD. If Microsoft decided to target gcc, Emacs, or whatever, tomorrow with a full frontal patent assualt they could probably come up with something that would be useful. You don't see RMS telling people not to use these software products because they might be infringing on Microsoft's patents.
What's more, Mono is undeniably Free Software, and it follows the grand tradition of GNU software in that it re-implements someone else's proprietary software (while mixing in its own completely Free Software extensions).
I am by no means a fan of Mono, but I fail to see how it is any different than gcc or the many GNU utilities that are basically work-alikes of any number of proprietary software products. Cloning commercial software products is hardly a new theme in Free Software. What is it, precisely, that makes Mono a special case.
The difference, apparently, is that Microsoft is especially evil.
The problem with that, of course, is that Microsoft is not really that particularly evil. Especially compared to AT&T or IBM in their respective heydays. Sure, patents have changed the game somewhat since the early days of UNIX, but Free Software's defense against patents has always been the same. Pretend that they don't exist until threatened, and then write the functionality out of the effected software. Mono is not appreciably more vulnerable to attacks from Microsoft than the Linux kernel, or any other major piece of Free Software.
Exactly. Heck, I *like* TeX and I still would at least consider using MS Word if a) I worked for Microsoft and B) I was writing a twelve page paper with very few equations.
I wouldn't use Word if I could get away with using TeX, but I would consider it.
I am just saying that this particular paper says good things about MS Research.
They aren't kidding when they say that Microsoft Research is autonomous. I would have assumed that Microsoft would at least make its researchers use MS Word.
Microsoft doesn't oppose the bridge. In fact, Microsoft is in favor of the current plans for the bridge. Currently plans for the bridge include 6 total lanes with two of those lanes (one in each direction) being HOV lanes. Apparently there is a contingent that wants to change the plans so that so there are two lanes for light rail and/or buses, two HOV lanes, and one general purpose lane in each direction.
Microsoft is right to oppose such a boondoggle.
The fact of the matter is that most of the people using the bridge will be using the general purpose lanes.
It's also essentially the same problem that DOS (and later Windows) had. As more and more android applications get developed, however, compatibility with existing applications is likely to reign in the more adventurous of the handset manufacturers. Handset manufacturers are going to want their phones to be able to run most Android apps, and so they will avoid incompatible changes unless they have a very good reason to be incompatible.
Android development in the future is likely to be driven by popular Android phones, but that's hardly a revolutionary thought.
IE may be the most dominant browser (not by much), but Windows users have a wealth of available browser options. I can imagine lots of scenarios where iPhone support (for example) might be more important than supporting Windows users that can't or won't install another web browser.
Which is why, of course, that Microsoft is starting to pretend that it actually cares about web standards. The executives at Microsoft aren't stupid. They know that installing an another web browser isn't that difficult. Heck, most home users have already switched to something else. If IE falls too far behind, then IE will simply be replaced by something else.
The typical user will care when IE won't play the games that they want to play or view the videos they want to see.
The fact of the matter is that the web has constantly evolved since the day that the first hypertext was invented. Up until very recently Microsoft was trying to push developers in the direction of Silverlight. It wanted to see the web evolve towards being Windows-centric again.
However, Mozilla, Apple, and Google (and Opera, I guess), have all decided that what they really want is for plugins to go away and for the browser to simply become a better client. This apparently resonates with some developers. Removing a reliance on formats like Flash or Silverlight definitely has some advantages. You can get a modern web browser for most any platform these days, Silverlight and Flash are much harder to come by.
So, while it is pretty clear that Freeciv.net is out out on the bleeding edge, it is also pretty clear that this sort of web browser usage is something that Microsoft needs to pay attention to. After all, it is not like it is particularly difficult to replace IE with something else. Windows users have a multitude of browser choices. At some point I would imagine that supporting iPhone users with a HTML5 client makes more sense than supporting folks that can't (or won't) install another browser on their Windows PC.
Yesterday I had a Jimmy Dean Flapstick. That product is a true culinary achievement, and I gladly spend my own money to help support Jimmy Dean R&D. Sending astronauts to the moon, on the other hand, is something that has been done. In fact, it was done before I was born, and I am old.
Besides, what Obama really needs isn't a man (or woman) on the moon. He needs an excuse that will allow him to pass the Carbon Cap and Trade bills so that he can raise billions in new tax revenues. NASA already has plenty of experience inventing climate data, so it is the perfect organization for the job. With enough money, convincing the voting public that CO2 is driving global warming should be pretty straightforward. In fact, the real problem may be knowing when to say when. With the increased funding NASA should be able to convince voters that they are actually ON FIRE.
It is in the Ubuntu user's best interest for Canonical to be successful. If Canonical is successful then we can basically rely on a continual string of upgrades for our Ubuntu machines. Switching to another GNU/Linux distribution (or another OS entirely) is going to cost me far more than changing my default search engine.
As far as I am concerned Canonical has just found a way to have Microsoft foot part of the bill for Ubuntu development. Quite frankly, I think that's genius.
And the politicians wonder why it is that America has trouble getting kids
interested in the sciences.
I can understand that an assistant principle might not have any
idea how bombs are made. There's no shame in that. However, he
probably should have talked to the child's teacher before he called
the fire department. My guess is that the kid had to tell his teacher
ahead of time what he was making. I have never heard of a science
fair where you weren't required to pre-register your experiment. How
hard would it have been to talk the the science teacher before calling
the bomb squad?
Now, if the teacher thought that the device was a bomb (especially
if he knew before hand that the kid was working on a proximity
detector) then shame on him. I mean seriously, how hard would it have
been to do a little research beforehand.
I agree that this has, in certain cases, worked in Microsoft's favor. However, on the web this has backfired badly against Microsoft.
One of the primary reasons that Microsoft has had such a hard time moving businesses away from Windows XP and IE 6 is that Microsoft tricked a whole pile of businesses into pretending that IE6 was the Internet. Then, after these business were locked into Microsoft's technology stack, Microsoft ripped out support for key Microsoft-only technologies in newer versions of IE. There were some good reasons for removing these mis-features, but this particular blunder on Microsoft's part basically amounts to what I believe is the biggest mistake in Microsoft history. Not only did this cause Microsoft's customers to stick with Windows XP instead of upgrading, but it also made it more difficult for Microsoft's partners and customers as they were forced to support more and more versions of Windows.
What's more, because these executives have been burned before they are far more interested in real web standards than they were in the past. No one wants to create a web application that you have to throw away just a few years later.
To a certain extent Microsoft is moving towards web standards because the alternative is to become completely irrelevant as a web client. Both Google and Mozilla have better browsers. If Microsoft gets too far behind then customers will simply give up on IE. That is especially dangerous because, despite Microsoft's best efforts, the operating system is slowing being supplanted by the web browser as the platform of choice. Heck, there are tools to provide for SVG on IE right now.
That being the case, I still think that it is premature for Microsoft to get involved on the standards committee before they have a working implementation.
First of all, both Firefox and Webkit support infinitely more SVG than IE. What's more, a huge part of the reason that SVG isn't more popular is that IE does not support it. SVG Tiny would be more than good enough for *my* needs, but I can't use it and still support IE so I am stuck with Flash. The rest of the browser developers don't have unlimited resources. They are hardly going to pour lots of time and effort into a standard that most developers can't use.
Second of all, librsvg is LGPLed, which should be perfectly fine for anyone that wants to simply include SVG support in their application, closed source or not. The only reason to prefer a BSD licensed library over an LGPLed library is if you want to make extensions to the library that you don't want to share with others. If that is the case, then you can write your own library and do what you want with it. For libraries that propose to be standard-compliant the LGPL is arguably the perfect license.
Either way it doesn't change the fact that Microsoft has dragged its heels on this particular standard. Now it wants a seat at the standards table despite the fact that it doesn't have a browser that will display SVG AT ALL. If joining the committee were accompanied by a commitment to actually implement SVG at some later time I would actually applaud Microsoft's behavior. However, that isn't the case, and so I do not see how to interpret Microsoft's actions in a non-skeptical manner.
Dengler didn't commit to add SVG to IE, and the company declined to comment about that possibility when asked.
Until Microsoft commits to supporting SVG in IE it is hard to see Microsoft's supposed support of the standard as anything but disingenuous. As you point out, Microsoft's position at this point is ridiculous. Not only has Microsoft been actively promoting an SVG competitor, but the primary reason why SVG isn't ubiquitous is the fact that SVG is not supported in Internet Explorer.
Slashdot Mirror
Microsoft wants apps to be portable to Windows. If they could create a project that allowed people to migrate autotools built apps to a Windows build system that would be a huge win. Especially if there was no way to go back to autotools.
The danger, for Free Software anyhow, of this system is that currently most of the actual development of Free Software applications is done with Free Software tools, and those Free Software tools pretty much assume a Posix API. That is true even when most of the folks actually developing the tools are using Windows systems. Free Software developers working on Windows invariably end up with a whole pile of specialist tools like MingW and Cygwin that are basically designed around getting the GNU build toolchain to work on Windows.
If this project works, then the pressure for Windows to be Posix-like so that it can run the GNU build tools goes away. Instead you simply fire up this new Windows translator and kick out VS project files from your autotools files. Notice that this tool is very likely to be one-way only, autotools to VS studio projects. Unless it is perfect every time (and if it has to try and read autools files that is very doubtful) the Windows devs are very likely to simply use the tool once to generate VS project files and then modify the VS project files going forward. Microsoft is probably hoping that, at least in some cases, the folks maintaining the autotools part of the build system will get lazy and fall behind in the same way that many Free Software projects do now when it comes to building on Windows.
Personally, I doubt that Microsoft is going to get anywhere near that lucky. I also think that, to the extent it tries to build using Microsoft's compiler, it is unlikely to be very successful. If this tool created a straightforward way to simply building for Windows with gcc then lots of projects would be interested as it would free them up from building their own custom system for building on Windows. Currently there are nearly as many ways to build Windows binaries as there are Free Software projects that build Windows binaries. However, for many projects maintaining compatibility with Microsoft's compiler is a non-starter. They have something that works with Mingw (or cygwin, or djpp in some cases) and they are happy to stick with that.
The tools are apparently going to be written in C#. So I suppose that much of the work is already done.
I just want to make sure I understand what you are trying to do.
The aptitude and Windows equivalent of the Debian repository sounds like a no-brainer. Microsoft should have done this 15 years ago. There is nothing the slightest bit controversial there. Assuming you can get enough packages in your repository to make it worth anyone's time, this is sure to be a smash hit.
However, in order for your plan to work, you need a source of Free Software packages for Windows. Apparently you are planning on doing this Ubuntu-style (to the point where you plan on using bzr and launchpad.net). In other words you are going to have a shallow branch of every package that you wish to include in your repository, and each branch will contain the build information necessary to build the package and format it according to your specifications. In fact, it would appear that you are planning to build tools that take autotools-style build systems and turn them into something that Microsoft's tools can use.
That is a tall order. In fact, if your tools get even remotely close to being able to do that for the five (or so) variations of Windows that people find to be interesting, then I would not be surprised if the UNIX people don't borrow your tools to help them migrate away from Autotools. No one actually likes Autotools. And let's not even get started on what your system is supposed to do with projects that use alternate build systems like cmake, scons, or whatever else.
Of course, such a repository would be useful even if it only worked for a handful of applications, which you could probably handle in a mostly manual fashion. After all, most Free Software does build on Windows already if you poke it hard enough. It doesn't tend to build with Visual Studio, of course, so playing nicely there raises the bar considerably.
I do have one question. Why, exactly, do you think that this sort of approach is likely to be easier than doing what Apple did and simply exposing a Posix API that is actually useful?
What do you need an iso for if you aren't doing an install?
They actually should call it Mono 5.5. That would teach Microsoft.
If the danger to Mono is so obvious, then please point out the patent numbers that Microsoft owns that would apply to Mono (and that don't, at the same time, apply to Free Software tools like OpenJDK, or gcc). Additionally, you should only use patents that don't apply to the ECMA specification.
What? You don't have access to such a list? Imagine that! My guess is that this is because (to my knowledge) no one has come up with such a list of patents. It is possible that you have access to such a list--in which case your accusations could *potentially* stop being FUD. Until then, however, you have no evidence that Mono is particularly vulnerable to attack from Microsoft.
Microsoft has already stated that it believes that Linux (for example) violates hundreds of its patents. In fact, it has even signed patent deals that supposedly cover Linux. Patent attacks on Linux are definitely not FUD. Should I stop using Linux as well?
If Mono is a trap, then it is quite likely to be the stupidest trap in the history of the world. At the very best Microsoft could force the Mono developers to be less compatible with .NET. Since Mono is not particularly compatible with .NET in the first place this is hardly a huge threat.
The Java trap doesn't really apply to Mono. The real problem with Java was that developers tended to use non-free Java tools even when developing for and on GNU/Linux. That's not the case at all with Mono. In fact, there are any number of Free Software projects written in Mono that will not run on Microsoft's .NET because they use GTK# or other Mono-specific extensions.
Besides, it is not as if the GNU project doesn't have it's own C# tools. Take a look at DotGNU, for instance. If Mono is so bad, then where does the FSF get off supporting DotGNU as an official GNU project? Heck, if you search on gnu.org you will even find several comments by RMS himself about the glowing promise of Mono. Take This one, for example.
When push comes to shove RMS' real issue with Mono is that he'd rather have you write your Free Software in C (or guile). The rest is pure FUD. If Microsoft decided to target gcc, Emacs, or whatever, tomorrow with a full frontal patent assualt they could probably come up with something that would be useful. You don't see RMS telling people not to use these software products because they might be infringing on Microsoft's patents.
So why, precisely, is Mono a special case?
What's more, Mono is undeniably Free Software, and it follows the grand tradition of GNU software in that it re-implements someone else's proprietary software (while mixing in its own completely Free Software extensions).
I am by no means a fan of Mono, but I fail to see how it is any different than gcc or the many GNU utilities that are basically work-alikes of any number of proprietary software products. Cloning commercial software products is hardly a new theme in Free Software. What is it, precisely, that makes Mono a special case.
The difference, apparently, is that Microsoft is especially evil.
The problem with that, of course, is that Microsoft is not really that particularly evil. Especially compared to AT&T or IBM in their respective heydays. Sure, patents have changed the game somewhat since the early days of UNIX, but Free Software's defense against patents has always been the same. Pretend that they don't exist until threatened, and then write the functionality out of the effected software. Mono is not appreciably more vulnerable to attacks from Microsoft than the Linux kernel, or any other major piece of Free Software.
So really, why all of the hate?
Exactly. Heck, I *like* TeX and I still would at least consider using MS Word if a) I worked for Microsoft and B) I was writing a twelve page paper with very few equations.
I wouldn't use Word if I could get away with using TeX, but I would consider it.
I am just saying that this particular paper says good things about MS Research.
They aren't kidding when they say that Microsoft Research is autonomous. I would have assumed that Microsoft would at least make its researchers use MS Word.
Are you insinuating that Google's camera van climbed this guy's fence to photograph this guy in the buff?
Microsoft doesn't oppose the bridge. In fact, Microsoft is in favor of the current plans for the bridge. Currently plans for the bridge include 6 total lanes with two of those lanes (one in each direction) being HOV lanes. Apparently there is a contingent that wants to change the plans so that so there are two lanes for light rail and/or buses, two HOV lanes, and one general purpose lane in each direction.
Microsoft is right to oppose such a boondoggle.
The fact of the matter is that most of the people using the bridge will be using the general purpose lanes.
It's also essentially the same problem that DOS (and later Windows) had. As more and more android applications get developed, however, compatibility with existing applications is likely to reign in the more adventurous of the handset manufacturers. Handset manufacturers are going to want their phones to be able to run most Android apps, and so they will avoid incompatible changes unless they have a very good reason to be incompatible.
Android development in the future is likely to be driven by popular Android phones, but that's hardly a revolutionary thought.
IE may be the most dominant browser (not by much), but Windows users have a wealth of available browser options. I can imagine lots of scenarios where iPhone support (for example) might be more important than supporting Windows users that can't or won't install another web browser.
Which is why, of course, that Microsoft is starting to pretend that it actually cares about web standards. The executives at Microsoft aren't stupid. They know that installing an another web browser isn't that difficult. Heck, most home users have already switched to something else. If IE falls too far behind, then IE will simply be replaced by something else.
The typical user will care when IE won't play the games that they want to play or view the videos they want to see.
The fact of the matter is that the web has constantly evolved since the day that the first hypertext was invented. Up until very recently Microsoft was trying to push developers in the direction of Silverlight. It wanted to see the web evolve towards being Windows-centric again.
However, Mozilla, Apple, and Google (and Opera, I guess), have all decided that what they really want is for plugins to go away and for the browser to simply become a better client. This apparently resonates with some developers. Removing a reliance on formats like Flash or Silverlight definitely has some advantages. You can get a modern web browser for most any platform these days, Silverlight and Flash are much harder to come by.
So, while it is pretty clear that Freeciv.net is out out on the bleeding edge, it is also pretty clear that this sort of web browser usage is something that Microsoft needs to pay attention to. After all, it is not like it is particularly difficult to replace IE with something else. Windows users have a multitude of browser choices. At some point I would imagine that supporting iPhone users with a HTML5 client makes more sense than supporting folks that can't (or won't) install another browser on their Windows PC.
Yesterday I had a Jimmy Dean Flapstick. That product is a true culinary achievement, and I gladly spend my own money to help support Jimmy Dean R&D. Sending astronauts to the moon, on the other hand, is something that has been done. In fact, it was done before I was born, and I am old.
Besides, what Obama really needs isn't a man (or woman) on the moon. He needs an excuse that will allow him to pass the Carbon Cap and Trade bills so that he can raise billions in new tax revenues. NASA already has plenty of experience inventing climate data, so it is the perfect organization for the job. With enough money, convincing the voting public that CO2 is driving global warming should be pretty straightforward. In fact, the real problem may be knowing when to say when. With the increased funding NASA should be able to convince voters that they are actually ON FIRE.
It is in the Ubuntu user's best interest for Canonical to be successful. If Canonical is successful then we can basically rely on a continual string of upgrades for our Ubuntu machines. Switching to another GNU/Linux distribution (or another OS entirely) is going to cost me far more than changing my default search engine.
As far as I am concerned Canonical has just found a way to have Microsoft foot part of the bill for Ubuntu development. Quite frankly, I think that's genius.
GNU Hurd.
Good catch. In my defence, I haven't had reason to spell that particular word in a long time.
And the politicians wonder why it is that America has trouble getting kids interested in the sciences.
I can understand that an assistant principle might not have any idea how bombs are made. There's no shame in that. However, he probably should have talked to the child's teacher before he called the fire department. My guess is that the kid had to tell his teacher ahead of time what he was making. I have never heard of a science fair where you weren't required to pre-register your experiment. How hard would it have been to talk the the science teacher before calling the bomb squad?
Now, if the teacher thought that the device was a bomb (especially if he knew before hand that the kid was working on a proximity detector) then shame on him. I mean seriously, how hard would it have been to do a little research beforehand.
Actually, this particular clock specifies a particular time before midnight. So they have only been right once a day for the past six decades.
In other words, a stopped clock was right twice as often (assuming, of course, that it was a standard analog clock without an AM/PM indicator).
Six minutes. Six minutes. Six minutes, Doug E. Fresh you're on!
I agree that this has, in certain cases, worked in Microsoft's favor. However, on the web this has backfired badly against Microsoft.
One of the primary reasons that Microsoft has had such a hard time moving businesses away from Windows XP and IE 6 is that Microsoft tricked a whole pile of businesses into pretending that IE6 was the Internet. Then, after these business were locked into Microsoft's technology stack, Microsoft ripped out support for key Microsoft-only technologies in newer versions of IE. There were some good reasons for removing these mis-features, but this particular blunder on Microsoft's part basically amounts to what I believe is the biggest mistake in Microsoft history. Not only did this cause Microsoft's customers to stick with Windows XP instead of upgrading, but it also made it more difficult for Microsoft's partners and customers as they were forced to support more and more versions of Windows.
What's more, because these executives have been burned before they are far more interested in real web standards than they were in the past. No one wants to create a web application that you have to throw away just a few years later.
To a certain extent Microsoft is moving towards web standards because the alternative is to become completely irrelevant as a web client. Both Google and Mozilla have better browsers. If Microsoft gets too far behind then customers will simply give up on IE. That is especially dangerous because, despite Microsoft's best efforts, the operating system is slowing being supplanted by the web browser as the platform of choice. Heck, there are tools to provide for SVG on IE right now.
That being the case, I still think that it is premature for Microsoft to get involved on the standards committee before they have a working implementation.
First of all, both Firefox and Webkit support infinitely more SVG than IE. What's more, a huge part of the reason that SVG isn't more popular is that IE does not support it. SVG Tiny would be more than good enough for *my* needs, but I can't use it and still support IE so I am stuck with Flash. The rest of the browser developers don't have unlimited resources. They are hardly going to pour lots of time and effort into a standard that most developers can't use.
Second of all, librsvg is LGPLed, which should be perfectly fine for anyone that wants to simply include SVG support in their application, closed source or not. The only reason to prefer a BSD licensed library over an LGPLed library is if you want to make extensions to the library that you don't want to share with others. If that is the case, then you can write your own library and do what you want with it. For libraries that propose to be standard-compliant the LGPL is arguably the perfect license.
Either way it doesn't change the fact that Microsoft has dragged its heels on this particular standard. Now it wants a seat at the standards table despite the fact that it doesn't have a browser that will display SVG AT ALL. If joining the committee were accompanied by a commitment to actually implement SVG at some later time I would actually applaud Microsoft's behavior. However, that isn't the case, and so I do not see how to interpret Microsoft's actions in a non-skeptical manner.
Until Microsoft commits to supporting SVG in IE it is hard to see Microsoft's supposed support of the standard as anything but disingenuous. As you point out, Microsoft's position at this point is ridiculous. Not only has Microsoft been actively promoting an SVG competitor, but the primary reason why SVG isn't ubiquitous is the fact that SVG is not supported in Internet Explorer.