What CoApp packages would you like to see?

May 5th, 2010 Categories: CoApp

(cross-posted from the mailing list)

I’m doing some initial work for long term planning today—really this will help drive my focus over the next year or two.

Assuming that CoApp produces a beautifully functioning package manager and ecosystem, what open source packages would you like to see made available for Windows via CoApp?

 

I’ve stated before that my personal focus is around PHP, Apache and Python (courtesy of the folks kind enough to pay for my time on the project).

 

What would you like? What software or libraries would you find compelling? What is #1 in your list? On the server? On the client? In the cloud?

What is the priority of that (say on a scale of one to five stars)?

 

Feel free to tweet your answers tagged with #CoApp #PackageIdea


Hey, rather than commenting here, come join mailing list (join the team at https://launchpad.net/~coapp-developers) and continue the conversation!

Tags: ,
  • karellen

    I’d really like to see a bunch of the core FLOSS "system" and "desktop" libraries as CoApp packages. glib. gtk2. qt4. boost. cairo.

    There are so many little FLOSS apps out there which provide a tiny rpm or deb for Linux, but a large installer for Windows because they need to provide their own version of, e.g. GTK2, in order for installation to be easy enough for people to bother with. If the authors of these apps could rely on CoApp packages of these core libraries being available (at least for automatic dependency resolution download, if not already installed) then this would allow/encourage them to make their own CoApp packages, which would be much smaller and more streamlined than their existing installers. As a result, I think much more software would suddenly become accessible to "normal users" under Windows.

    After that, it’d be really nice to see KDE or Gnome, although I think those projects have enough manpower to make their own CoApp packages once the tech becomes available. They pretty much have Windows installers of one form or another anyway, and this is going to make things so much easier. (Not that the system libraries I mentioned previously don’t have manpower, but I get the feeling that library authors are less concerned with doing their own packaging than app authors)