A Packaging System for Open Source Projects on Windows

Posted by Abel Avram on Apr 14, 2010

Sections

Operations & Infrastructure,

Architecture & Design,

Development

Topics

.NET ,

Open Source ,

Windows ,

Package Managers ,

Programming ,

Operating Systems

Share |

RELATED Research

The Common Opensource Application Publishing Platform (CoApp) is intended to be a package management system for Windows, providing support for compiling, building and deploying open source projects usually developed on other platforms like Linux, Mac OS, etc.

Why porting non-Windows open source applications to Microsoft’s OS? The immediate reason is that the application is exposed to a new audience which in turn could help advancing the project. Another is that it would bridge the Windows and Linux/UX/Mac communities for the benefit of all.

Some of the problems with porting open source projects from UX to Windows are related to the different file systems, command line interfaces, underlying APIs, user interfaces, supporting libraries. While Cygwin provides an UX-like environment for Windows, it does not take advantage of all the benefits of building an application specifically for Windows. The correct solution would be to create the right tools to automate most of the process of generating binaries from source code, binaries that are packaged, stored and run on Windows like any other native application.

The CoApp project was started by Garrett Serack who works full time on this project, being paid by Microsoft, but CoApp is not dependent on the Redmond giant, according to the project initiator:

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.

Serack intends to make use of the Windows Installer (MSI) and WinSXS, the side-by-side technology developed by Microsoft to resolve the DLL hell. Some of the other features CoApp should implement are:

• Support 64 bit and 32 bit systems, without hassle or collisions.
• Place binaries, libraries and header files in a logical and consistent location.
• Facilitate sharing of components and allow multiple projects to easily both participate and consume them.
• Allow for upgrades and patching of both libraries and applications.
• Be Windows developer friendly. No forcing of building using ‘make’, but rather taking advantage of the nifty IDEs we already have.
• Also be Windows admin friendly. Even if it’s open source, you shouldn’t have to be a developer to put Open Source applications on Windows.

Perhaps the most important feature CoApp will have is providing the tools for handling dependencies. CoApp should be able to download all the dependency code and their associated header files, should solve most configuration issues and build an *.msi package that would run on all Windows flavors.

The team working on CoApp is going to start by packaging the first elements of the WAMP stack: Apache, PHP, and Python, and will learn while doing it. CoApp has a project website and a wiki and it is in its early phase.

RelatedVendorContent

Automating Error Reporting for .NET Applications

Troubleshoot Java/.NET performance while getting full visibility in production

RDBMS to NoSQL: Managing the Transition

Want to know how software releases can be stress-free and happen with one click? Try Go free!

Improving Software Delivery Cycles: Pre-requisites and Inhibitors

Related Sponsor

Go: Agile Release Management Solutions. Go enables predictable, defect-free and timely software releases.

1. Back to top

   My reservations

   by aditya yadav

   I would skip the Developer Friendly (... use IDEs...part)
   
   If it cannot be hooked onto my CI build with automatic package creation with success failure (build breaking on failure) features. I wouldn't use it everything else being the same. I don't want developers creating their own builds or to manually go into an IDE to create a build.
   
   
   Aditya Yadav
   Aditya Yadav & Associates
   Amazon Cloud Computing With C#/.Net
   Amazon Cloud Computing With Java
   Understanding Programming Languages
   Deploying HTML5
   Essays on SOA AND EAI - A Pocket Guide

   Reply

2. Back to top

   Re: My reservations

   by Garrett Serack

   I wouldn't worry--we're supporting both scenarios--automated and IDE.
   
   Garrett

   Reply