Is releasing the code always important?

Been briefly taking part in and watching a discussion about wether Launchpad should be released. The debate made me think about wether all code releasing is truly important or even a good thing.

Once upon a time I was writing articles for a now defunct news site called For this site a special publishing system had been written. I know Jeremy considered releasing the code we used for the site a couple of times, but in the end I remember him concluding that the code wasn’t really in a release worthy state and that he didn’t have the time or the interest to clean it up in order to add yet another half-done publishing system the world.

While we all where strong supporters of free software none of us had any problems with this decission. Part of the reason for that is that releasing the code of something doesn’t automatically make it useful for people. In fact it may only be a distraction as you get more useless crap showing up on google when you are trying to find something.

For the release of sourcecode to be truly useful the code needs to be in a state where its been prepared for consumption by anyone else than the original creator. Getting hold of a source package that do not compile or run cause you don’t have access to the 7 post-it notes with manual instructions, the 19 steps only stored in the memory of the creator and is using some database tables you don’t have an sql script to create tend to be of abysmally little value.

A lot of source code is written by one or two persons for their own private or professional use. Code written like that is often using a lot of shortcuts to achieve its tasks, like hardcoding values, no code comments, no documentation, no real build system, relying on a database structure thats been created manually and incrementally over a period of time and so on. Thus sending that code out there doesn’t make it instantly useful. So unless your application is truly special nobody will probably ever bothering spending the weeks or months it would take to make it useful to themselves or the even longer period it would take to make it useful to the world at large.

That said there are of course cases where even such code could be useful, for instance if the code documents a certain piece of hardware or fileformat. But once again it would require the code to actually correctly document the hardware or fileformat in question, sending out a file called nvidia-driver.tar.gz which contains a driver you tried to make by trial and error, but which never did anything apart from cause 4 of your graphics card to stop working permanently is probably not doing anyone any favours. At least not without a lot of code comments and a big warning.

Which brings me a back to trying to pressure someone to open source something. In many cases unless the person asked to release some code wants to release the code to the world and thus is willing to take the time and effort to make sure the world would truly be able to use the code then getting the code released would probably be of little or no value. In fact it might just be adding to the noise making googling for actually useful code a little harder.

So in terms of Launchpad. I am sure it could be a useful tool for various people or groups if released, but release means more than doing ‘tar -cvf lp.tar /var/www/’. Thus unless one can convince Canonical that there is true value for them in spending the time and the money to prepare LP for a release and maintaining that release as a public project, then all achieved is probably getting a big tarball of useless crud put onto the net and at the same time have wasted developer time on an effort of little value.

In the meantime maybe effort should instead be spent on improving existing projects already available which has a featureset similar or close to what Launchpad offers.

12 thoughts on “Is releasing the code always important?

  1. My argument would be, even if nobody uses it, or one person uses it, even if it’s a bitch to install, I can still see no reason to not release things. Look at Slashcode, and the few sites that actually use it, and yet it powers a site that is massively popular – we don’t have five Slashdots, but we do have MacSlash and Technocrat, both scratching itches that Slashdot doesn’t.

  2. Two comments:

    1. It doesn’t need to be a tarball, anonymous CVS or equivalent would do.

    2. In the case of launchpad access to the code would at least let people produce patches.

  3. While I agree with most of your points, it should be noted that there is quite a big difference between the source of some random website, and the source of a major piece of free software development infrastructure being closed.

    If Launchpad wants to become the central point of free software project collaboration, it just must be free. Only that way the various communities can feel secure enough to switch to it.

  4. While I do agree to the business and technical point of view in your entry you forget to mention the political aspect (that Henri brings up).

    Launchpad targets being a central point for free software development. In order to be it really has to be free itself. Of course, this is the argument that could convince Canonical that it’s in their business interest to make it so.

    Many users though have very little understanding in the costs that comes with open sourcing something. It’s an investment like any other in that respect, you invest and hope it will return the investment and be profitable.

  5. One key benefit that the Ubuntu community would gain would be that other projects that Ubuntu depends on could also use Launchpad. Right now compound mega-projects like GNOME, Debian, KDE, etc don’t use Launchpad because they can’t. If at least one of these projects used Launchpad, Mark’s idea about co-ordinated releases of mega-projects ( ) could be a lot easier to achieve. You would also be able to gain their inputs and patches for ways to improve Launchpad or make it more flexible or maintainable. For instance, does Launchpad have interoperability with all version control systems and exports and imports to and from MSProject/dotProject/…? I’m willing to bet it doesn’t because Canonical has bigger fish to fry so it’s only focused on the essentials.

    You also mentioned “A lot of source code is written by one or two persons for their own private or professional use. Code written like that is often using a lot of shortcuts to achieve its tasks, like hardcoding values….”. This is precisely another reason why open sourcing makes sense. Open sourcing forces things to be cleaned up, either by canonical or contributing “patch janitors”. Look at Star Office, for instance. It was a mess of a build system that, little extendibility, no integration with GNOME and KDE, and no chance that it’s file format could evolve into an ISO standard. Everything changed because it became open source.

    Lauchpad has the chance to make a similar splash in the compound mega-project arena like the GNOME/Debian/Apache/Fedora/Gentoo/… communities. Even if nothing is documented more than it currently is and the code is not cleaned up — if the code is shared with a few key contact people in these communities, and if they can be trained, these contacts can train others who want to configure or contribute to Launchpad.

  6. The point of ‘releasing the source’ in Free software is about proving that nobody has life-or-death control over a project.

    I would argue that linuxpower is not a centrally important piece of infrastructure for Free software, however launchpad in theory could be.

    Proponents of launchpad being released are so because it would prove that even if something were to happen and Canonical were to take their ball & go home, it wouldn’t massively disrupt the game.

  7. So let me get this straight —

    It would be a net-loss if Canonical opened the source code for Launchpad because it would pollute Google’s search results?

    The 22 people working on Launchpad, by using bad practices such as not preserving their SQL and build scripts, have created a project so poor it would take 2 months for the average free software monkey just to get it running. People like Martin Pool, who cares so much about software project management he wrote his own version control system!

    Christian, the best way for a free software company with a free linux distribution to get other free software projects and companies to comit to Launchpad is to publish the source code, using bzr…

    It really has got nothing to do with your friends old hairball of a website or an imaginary nvidia driver.

  8. So Schaller takes yet another step: from “call it Free software* not ‘open source’, to pro-DRM activist**, to preferring to keep the source closed.

    Why don’t you drop any pretense that you still give a damn about Freedom… other than the fact that it gives you, and your fellow sell-outs at Fluendo, access to a nice lump of code to rip off when you make a locked-down Trusted Computing DRM Gstreamer to sell to the likes of Nokia/Sony etc.

    * Have we all forgotten his firebrand article stating that the term ‘open source’ is a corruption and dumps the real purpose of Free software — he obviously hopes we have.

    ** writing a DRM system by stealing Free software is certainly active

  9. Your points about the lack of value of software such as the (hypothetical) non-working video card driver, or a grotty, hacked-together, undocumented pile of code produced by one person who was never thinking about a public release, are quite valid for those examples.

    However, none of those points apply to Launchpad.

    One, Launchpad is a major piece of infrastructure of a very important Linux distribution. As such, it has inherent value that the hypothetical broken video driver does not.

    Two, I cannot believe that Launchpad’s code is in such a hacked-together state that it would take months of effort to clean up.

    Furthermore, there are other points that you don’t bring up which strongly argue *for* open-sourcing Launchpad.

    First, there’s the classic “hit by a bus” scenario. Currently, if Mark Shuttleworth gets hit by a bus and his heir(s) have no interest in continuing to fund Canonical, Launchpad would go away. Open-sourcing Launchpad protects against this scenario.

    Second, there’s the fact — which other people have mentioned — that other projects, such as GNOME and Debian, currently cannot use Launchpad. Well, I suppose “cannot” is a slight overstatement (except in the case of Debian, whose bylaws would forbid it) — the GNOME project *could*, I suppose, ask Canonical to set up accounts for all their developers and then launch a massive effort to port their bugtracking info over to Launchpad. But what would that massive effort gain them? A bugtracking system that could go away at any moment under the “hit by a bus” scenario, or if Canonical suddenly pulled a BitMover.

    Finally, you ask where the value is to Canonical in open-sourcing Launchpad? One value is precisely the coordinated-launch aspect mentioned by others. If GNOME cannot trust Launchpad not to become another BitKeeper, they won’t use it. But if Launchpad becomes open-source, we might see upstream projects using it as well, which would add great value to the cross-distro and distro-to-upstream bugtracking features Launchpad offers.

    At the end of the day, infrastructure for open-source projects needs to be open-source itself, and that’s all that matters.

Comments are closed.