Share via

What’s this ‘CoApp’ all about?

  • Article

Last week, I blog’d about a new open source project that I’ve launched called “CoApp” (The Common Opensource Application Publishing Platform). As I’ve mentioned on the project site, “CoApp aims to create a vibrant Open Source ecosystem on Windows by providing the technologies needed to build a complete community-driven Package Management System, along with tools to enable developers to take advantage of features of the Windows platform.”

Ugh—a mouthful—and all chocked full of them shiny marketing words.(Uh.. yeah, I know wrote that.).

 

So, what does that mean?

Well, while Windows provides some pretty good stuff for packaging applications in the form of Windows Installer* technology (aka “MSI”), the down side is that the open source community hasn’t really picked it up in the same way that they have picked up packaging on other platforms where they create repositories and distributions of software, and so we’re missing out on having these nice, consistent collections of all these great open source apps.  That’s where I really want to be.

‘Course, my pappy always used to tell me “it don’t take a genius to spot a goat in flock of sheep” … Sure, it’s easy to see what the problem is, question is, how do we go about fixin’ it?

 

Last fall, I started to sketch out what that should look like, and what it would take to get there.  After a few months of poking the right people, I started to get agreement here at Microsoft that this really is a great idea, and we should be spending time on it. (And, ‘course, by ‘we’ I mean ‘me’)  I know from personal experience with building open source software on Windows, that things are not only sometimes tricky, but often downright impossible to build correctly, and even harder to make sure the software is built in such a way that anyone on Windows could use it.  I’ve come up with a plan for building a set of tools to help open source software build better on Windows, along with automating the packaging in such a way that will allow us to build yet more shiny tools to locate and install them.

Along with the tools, we’re going to need to lay down some guidance on how to use them to build packages that play nice with each other—I want to make sure that I’m never running into “DLL Hell”, never having to search for missin' bits, and always getting the right package for the right job.  At the same time, I really want to use some optimization techniques to help open source software run better on Windows.

 

Starting with ApacheCon last fall, I began to reach out to people I know in open source communities, not only to get their buy-in that this is a good idea, but solicit their help. I’ve already secured a handful of folks who are interested in helping, and I can always use a few more.

Over the course of the next month or so, we’ll be the filling in the details on what all of this looks like on the project site, and discussing the merits on the mailing list. From there, we’ll begin to build the tools, and with a bit of luck, we’ll start producing packages a few more months after that. We’ll probably start with the packages that make the most sense (Apache, PHP and Python) and work our way out from there.

 

And just how does Microsoft fit into all of this?

Well, the folks here at Microsoft have recognized the value in this project—and have kindly offered to let me work on it full-time.  I’m running the project; Microsoft is supporting my efforts in this 100%. The design is entirely the work of myself and the CoApp community, I don’t have to vet it with anyone inside the company. This really makes my job a dream job—I get to work on a project that I’m passionate about, make it open source, and let it take me where it makes sense.

 

Sure, it’s a large project, but I’m pretty sure that we’re headed in the right direction—if you’d like to come out and help (or even just come get more details about what I’m talking about), you can start at https://coapp.org.

 

* I know, some people don’t particularly like MSI, but trust me, it’s all in how it’s used—ya don’t blame the horse for throwin’ a shoe.

Comments

  • Anonymous
    April 08, 2010
    I thought of a slogan. Windows Installer - "if you're losing fingers you're placing your hands too close to the huge whirling blade"(tm) ;)

  • Anonymous
    April 08, 2010
    Also, this sounds like a great idea and I hope it's a success.

  • Anonymous
    April 08, 2010
    Are you going to use other good open source technologies like cmake, gcc etc. as these would make porting to Linux/Unix easier?  ie. build on one platform, know that it will build with only minor changes on all.

  • Anonymous
    April 08, 2010
    @Chris I've tried that. Unfortunately, Windows ain't unix. automake is not really not designed to work with Windows, and even if it did, the results are not really compelling. What's needed is a slightly different approach. Most of the software already builds for Windows, admittedly with a bit of pain and suffering. I'm looking to fix that by streamlining and organizing it all.

  • Anonymous
    April 09, 2010
    I would like to point out two critical pieces of tech that you will need in order to use WinSxS appropriately with OSS libraries. You need to establish a clear mapping from libtool-style library interface version numbers to WinSxS compatibility information. Then, you will need to modify pkg-config such that it produces the right -l and -L arguments to gcc (or cl) to direct the compiler into the correct WinSxS directories.  Finally, you will need to modify either collect2 or GNU ld to generate SxS manifest information for the compiled DLL's and EXE's based on the manifests of the linked-in SxS DLL's. While some OSS will work with MSVC, most do not have the requisite project files and MSVC does not support C99. If you want to support the broadest variety of OSS, then you should aim towards standardizing on the use of MinGW+MSYS as the standard build environment.

  • Anonymous
    April 09, 2010
    @Jonathan Brandmeyer -> part of the CoApp project is building out a repository of shallow-forked OSS apps and libraries to build MSVC build scripts and optimizations. of the 100+ OSS libraries and apps I've been working with in the lab, every one will compile on MSVC given enough love. The CoApp toolset will address and automate most of the hassle around these.

  • Anonymous
    April 09, 2010
    There's a reason why most UNIX-based software is hard to build on Windows - it's a different platform! I would be much more interested to know what Microsoft are doing to foster/encourage open source development on their own platform rather than simply making it easier to 'steal' the work of all those UNIX guys. ;)

  • Anonymous
    April 09, 2010
    The comment has been removed

  • Anonymous
    April 09, 2010
    The comment has been removed

  • Anonymous
    April 09, 2010
    I actually have an idea that would make building UNIX/Linux software easy. While i have tried cygwin and do not like the solution i have done some thinking. Generic Linux Compatibility Layer (http://brainstorm.ubuntu.com/idea/22842/). The ability to run Linux applications in Windows the way Wine run Windows applications in Linux. "Ubuntu/OSS Desktop" Application suite (http://brainstorm.ubuntu.com/idea/22840/). With the Linux Compatibility Layer the applications of full distributions like Ubuntu or RHEL could run even without recompiling the packages. It would give the flexibility of a Virtual Machine but run with native speed as it is only a compatibility layer.

  • Anonymous
    April 11, 2010
    Fear not the almighty M$ will do the right thing by Unix/Gnu/Linux. "NOT" And the writer of this article will be treated fairly when M$ rams it up his rump!

  • Anonymous
    April 11, 2010
    The comment has been removed

  • Anonymous
    April 11, 2010
    I'm glad to hear of this project. Centralized package management is one of the (perhaps not the most important, but still) things that makes Linux/Unix more secure than Windows. Increased security, by any amount, benefits everyone. Furthermore, "Embrace, Extend, Extinguish" can work both ways. By getting people used to F/OSS on Windows, they may be more willing to try the total Free experience (Linux). Even if they do not, it hurts no one for Free Software to be more easily used on Windows.

  • Anonymous
    April 12, 2010
    The comment has been removed

  • Anonymous
    April 12, 2010
    I maintain an application which I cross compile on Linux for Windows. The reason I don't generate MSI or others is that they don't work fine in a cross compiling environment. Do you plan to make the software being able to work on Linux in a cross compiling environment?