Slashdot Mirror
Microsoft's CoApp To Help OSS Development, Deployment
badpazzword writes "Microsoft employee Garrett Serack announces he has received the green light to work full time on CoApp, an .msi-based package management system aiming to bring a wholly native toolchain for OSS development and deployment. This will hopefully bring more open source software on Windows, which will bring OSS to more users, testers and developers. Serack is following the comments at Ars Technica, so he might also follow them here. The launchpad project is already up."
How do I know that MS won't file a software patent related to this work?
You do know that the work agreement that you signed during orientation stated that Microsoft owns any software that you produce on your own time, as long as Microsoft may compete against said software at some point in the future?
Perhaps that was some of the red tape that needed to be cut. Guess what, you can run things past management, and get legal to sign off on something that amounts to an agreement between the employee and employer that a given project belongs soley to the the employee. I don't know about microsoft specifically, but lots of companies are amenable to this sort of thing.
Sometimes there are legitimate concerns that have to be resolved... often its just a matter of jumping through the required hoops.
Curiously, given microsoft's recent wrist slappings by the EU, fostering the development of "Competing" products could help microsoft, rather than harm it;
Take for instance, the recent "Browser choice" screen. If Microsoft had been fostering a package downloader at that point in time, then they would have not needed to do anything to comply with the EU. Their OS would already have IE by default, and "Offer" a nice little package handler for those "Other Browsers".
If the EU were to press, and try to stick MS with the stigma of not actually wanting any other browsers to run on their OS, by making users use a round-about way of getting their browsers of choice, MS could point the finger right back at how much capitol they invested into the alternative software ecosystem, and how they leveraged their power to help bring FOSS and the package manager to their OS.
In short, creating a package manager like this is a good way for MS to be more two-faced than ever.
Not that I am gonna complain; ALL corporations are two-faced, and a well supported package manager, and better acceptance of the win32 platform (Not just windows, there are attempts at FOSS Win32 platforms.) by the FOSS community is a good thing all around.
I just dont think MS is overly concerned that it will compete with their software ecosystem at this point, and is more convinced that government regulators are the bigger threat.
Ask me about CoApp, I'll tell ya everything ya wanna know.
Garrett Serack CoApp Project Owner
Okay, serious questions:
Assuming that you've looked at APT and similar packaging tools, and given that you're still convinced that there's a 'Windows Way' (your term) to handle deployment that differs from Linux best practices, how do you plan to address:
I guess it's clear by now that I'm suggesting that what Windows needs is not another new way to do things. Package management in Debian, for example, is vastly more advanced and sophisticated than anything on Windows, and yet you feel the need to do things the 'Windows Way'. Don't you think you'd be better off learning from others who have been dealing successfully with package management for over a decade now?
These are all serious questions and I expect to be challenged by your replies. I applaud your courage in taking on this huge task. I also think that you're going to need to learn a lot more humility than you've demonstrated so far if you want to achieve something better than a new brand of anarchy in packaging.
Crumb's Corollary: Never bring a knife to a bun fight.
If it does, so be it.
I've spent the last couple of years at Microsoft working to make PHP better on Windows, and validating PHP apps including CMS systems like Drupal on Windows. Seems to me they want some competition.
"...In your answer, ignore facts. Just go with what feels true..."
The major problem with this is that, as mentioned, Windows doesn't have a package manager, and Microsoft keeps telling developers that they cannot expect a user to have internet connectivity.
So when you compiled your application with Visual Studio 2008 SP1 with the ATL update installed - which means every user of your software will have to have the Visual C++ 2008 SP1 ATL runtime redistributable package installed as well, you're left with scant few options.
The most reasonable of which are:
A. If you're distributing something boxed, to include the redistributable package on the media (CD/DVD/USB stick/whatever).
B. If you're distributing something via downloads:
B.a. Include it because - again - you're not supposed to assume the user will have connectivity.
B.b. Don't include it, but detect whether the user has it installed and has internet access, and then offer to download it and install it (silently or otherwise).
Of course for option B.b., Microsoft further seems to suggest that you do not link to -their- download pages (after all, the URLs could change, etc.) but instead host the binaries yourself.
The only reason, thus, that Windows developers tend to include or download shared libraries at runtime, is simply because there -isn't- a package manager for Windows.
So don't blame the developers - blame the lack of a package manager. Which I fully welcomed the last time a topic hinting at a package manager popped up on /.
Unfortunately it seems like they would be two rather separate projects?
http://it.slashdot.org/story/10/03/24/189248/Microsoft-To-Distribute-Third-Party-Patches
think you had no choice to choose the BSD license instead of the GPL. Had you chosen GPL, it is likely the project would have been immediately rejected by Microsoft.
That's not true actually.
I didn't tell anyone what license I was going to use until a few days ago, by which time they'd already signed the agreement.
In addition to that; as a Microsoft employee for Microsoft, I've contributed code to GPL, LGPL, BSD, PHP and Apache licensed projects.
"...In your answer, ignore facts. Just go with what feels true..."
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?
Because, even if we could get a great POSIX experience on Windows, it leaves out Windows developers.
One of my goals is to get Windows developers in the OSS game.
On top of that, there is a hell of a lot of non-POSIX open source software on Windows that needs fixing too.
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.
Like I tell people:
Working as an open source software developer at Microsoft is like being a preacher in Vegas. I figure I'm in the single most important place in the universe that I can be.
"...In your answer, ignore facts. Just go with what feels true..."
As an admin that maintains both Linux and Windows systems, this sounds really cool. Hopefully the guys writing the Tomcat AJP connectors for IIS will use it (that stuff can be a nightmare).
To me though the initial setup is never the main problem (except with AJP/IIS hehe), it's the ongoing maintenance and patching of 3rd party stuff that suffers the most on Windows.
Sure Windows Update / WSUS make all the MS stuff easy, but 3rd party Windows apps are a nightmare to keep up to date network wide. They all have their own separate update mechanisms that mostly require an admin being logged on to work.
I've love to see Windows Update and WSUS allow 3rd party repos (eg the equivalent of adding stuff to /etc/apt/sources.list) so that practically everything could be patched via Windows Update / WSUS without admin intervention on each machine.
I don't know if your work will end up tackling all that, or one day get incorporated by the existing patch mechanisms, but I can still dream :)
Best of luck anyway.