Since this question has come up several times before, I thought it might make sense to blog about my take on this.

First of all, please note that there is a difference between "being part of the core distribution" and "being available from a distributor's package repository". The latter one is relatively easy, the former can be hard, as you need to convince the distributor that your application is worth devoting engineering resources to maintain and support your application as part of their product. It's also a space issue – distributions need to make sure that the core packages still fit on the installation media (e.g. CD-ROMs or a DVD). Therefore they take a very close look at each package and if it's really needed to be part of the installation medium or if it's fine to provide it for download from a package repository instead.

Distributors prefer to keep their core product small and restricted to the "basic OS building blocks". While MySQL might still be considered to be a part of this, this probably does not apply to the various plugins and extensions that are available for it. Therefore the best approach is to invest some engineering time and start doing the packaging yourself, either by hiring an engineer capable of creating and maintaining the packages, or by finding someone in your community who has the required experiences and is willing to do it.

While it's of course possible to set up and maintain your own build and package hosting infrastructure for that, I recommend to make use of the existing services provided by the distributors.

The top tier distributors all provide means of offloading the maintenance of "non-core" packages to their community, offering various options for packages to be made available. For example, Novell/openSUSE provide the free "Build Service", which is capable of building packages for other distributions as well (e.g. Fedora, Mandriva, Debian/Ubuntu, etc.). In addition to automating the builds, the Build Service also takes care of the distribution via their download mirror network and ensures that your application can be found via their package search interface.

Red Hat/Fedora provide something similar, named "Koji" – but it's "Fedora only". Here's a HOWTO that outlines the process of becoming a Fedora package maintainer.

Ubuntu/Canonical have "Personal Package Archives (PPAs) – if your project is hosted on Launchpad already, that might be something to look into for providing Debian/Ubuntu packages. Alternatively you could join the Debian project and start building and maintaining your package there. They maintain a list of "Work-Needing and Prospective Packages", a description of the process on how to become a new maintainer is outlined here.

If you'd like to target Solaris/OpenSolaris as well, there is the OpenSolaris Source Juicer – a web service which allows OpenSolaris community developers to build packages (using RPM spec files) and publish them for review, so they will be included in an official package repository. The Software Porters Community Group coordinates, advocates, encourages and helps with the porting of Software from multiple Platforms to the OpenSolaris Platform.

Keep the following saying in mind, which especially holds true in the Open Source world: "You never get a second chance to make a first impression!". While the most important thing is of course to have a compelling and useful product, this blog post is an attempt to highlight some other aspects about community building and providing the adequate infrastructure. This insight is based on my own experiences and my observations from talking with many people involved in OSS startups and projects.

Matt Asay kicked off the discussion, which became more of a debate as it developed, with a consistent message about GPL’s dominance among open source software projects, which is 70% or more based on most accounts (and considering GPLv2 and GPLv3). He also referred to monetization and the fact that GPL serves as the basis for successful support and services models, such as Red Hat. However, Matt did not initially mention the strategic and defensive benefits of GPL, which is often chosen because it mitigates the threat of a fork that someone can make proprietary. I was also hoping for him to address how GPL can deliver benefits of open source without having to share as in the spirit of the license, based on whether and how the software is distributed. Nevertheless, Matt made his most compelling arguments around the fact that GPL is the primary open source model and the license that developers understand and trust most. He furthered his argument later by agreeing EPL may be better for lawyers, but GPL is better for developers. Matt reinforced these ideas with his reference to large companies using GPL software, such as Google or TiVO, that gets it to vast numbers of users.

Mike Milinkovich spoke second with some background on EPL, its origin as a ‘legal document’ and how it links open source software to commercial products. He also hit on the fact that EPL covers patent rights, which is certainly important to vendors and developers. He later referred to the meaninglessness of Matt’s 70% GPL figure, based on the idea that software on repository is something different than software in use (where other licenses do have greater representation). However, our research indicates that the most popular open source licenses among hosted code are consistent with the most popular open source licenses among code in use, with GPL, BSD and EPL all in the top. Mike also referred to commercialization and money, which is certainly important to commercial open source, but did not give equal mention to community until later. Still, Mike earned back a point when he referred to monetization of open source software among traditional vendors and organizations beyond VC-funded, open source startups, where we are seeing significant growth for open source software. While I would have liked to have heard an argument in favor of EPL based on compatibility, Mike also made a good case for EPL in government — another consistent theme of the discussion — where code would belong to the public with commercial opportunity on top.

David Maxwell signaled a more rebuttal-type response and gave it in his arguments for the BSD license, which he introduced as the oldest license given its roots to Unix and the ’80s. David scored a point for simplicity and straightforwardness when he read the actual license, something his peers would’ve had a hard time doing. David did somewhat jump the gun, though, on rebutting with his counterpoints about GPL’s strict copyleft requirements, which he called ‘enforcement-based.’ Still, David recovered with an argument for BSD based on its emulation, which he credited for other popoular licenses such as the Apache Public License and Artistic License.

The debate portion was followed by some good discussion of business models, open core and proliferation with questions from the live and Web audiences. So why does my vote for the winner go to Mike and the EPL? While it was certainly close on my card and all three made compelling arguments, Mike and his portrayal of the EPL were the most realistic and pragmatic to today’s open source software in the enterprise. Communities, copyleft and the sharing that allows developers and projects to sustain effective, productive open source efforts must be balanced with commercial interests, endeavors and aspiration. Neither open source communities nor open source commercialization would be nearly as significant without one another, and Mike’s arguments and statements seemed most closely attuned to that.

Thanks again to the panelists, participants and FOSS Learning Centre for putting on the event. Please get involved in the discussion and watch the debate, comment here or elsewhere.