Self-hosting Launchpad? Dream on…

Sandro Groganz

Canonical recently announced that it open sourced Launchpad, its web-based project management and collaboration platform. This news came out while we were conducting an evaluation of Open Source collaboration platforms for a client. The client’s intent is to host a collaboration platform for its developer community. The evaluation was done based on feature sets, and was drafted before Launchpad’s source code was released. Launchpad turned out to be the slightly better choice and once it became available, we tried to install it.

Unfortunately, we began to realize that Launchpad isn’t designed or intended to be used as a self-hosting site due to the following reasons:

  • There are no release packages. You checkout the development code via a Bazaar repository and then compile it. Depending on the state of the last checkin, the code might even not compile sometimes. It took us two tries to get the installation done.
  • The working installation is meant for local use only and it’s not trivial to get it running under a normal, fully-qualified domain name.
  • Even if we had figured out how to make Launchpad serve properly via HTTP to the general public, we would have faced a maintenance nightmare by doing QA and release management ourselves.
  • Let’s not forget the fact that Canonical requires you to not use the trademark “Launchpad” and to replace all the graphic icons.

It is not without irony that an Open Source marketing agency was blinded by the fuzzy PR parlance of Canonical. Luckily, the source code always tells the truth.

After we had discussed the issue on the launchpad-dev mailing list, Canonical today added the following line to the Launchpad Development Wiki, which makes it pretty clear:

Note that our focus is on getting Launchpad to build easily so more people can participate in Launchpad development. Running a stable production instance would be ”much” harder than running a single-developer test instance, and we don’t recommend it. Unlike many open source projects, we’re not seeking to maximize the number of installations; our goal is to improve the instance we’re already running at Launchpad.net.

Obviously, Canonical really doesn’t have to worry that by open sourcing Launchpad, they licensed away their business model.

Our client has opted for FusionForge. It’s a great alternative, works out of the box, is easy to install and includes all the basic features. It runs on top of Ubuntu 9.04, an Open Source operating system backed by Canonical, which, ironically, has some proper release management 🙂

8 thoughts on “Self-hosting Launchpad? Dream on…”

  1. Sorry you were surprised. But our announcement at the time of open-sourcing clearly stated that our goal was to improve the Launchpad service we host (see https://lists.launchpad.net/launchpad-users/msg05118.html).

    “Proper” release management depends on the goals of the entity doing the management; the same is true for Ubuntu, for which we take entirely different release management approach, because in that case we are trying to maximize the number of installations. The release management we do for Launchpad works for our purposes (regular deployment at Launchpad.net); we can’t take on the burden of doing QA and release management for others’ purposes as well.

    Anyone else is free to take on that burden, but as you discovered, it’s quite large. Now you know why we don’t do it :-).

    The fact that the code didn’t compile for you when you tried it is problematic from our point of view too — we do want it to be easy to hack on, so people can develop and test patches. Trunk is normally buildable, at least in my experience; I hope the problems you encountered got fixed.

    Good luck with FusionForge!

    Best,
    -Karl Fogel

    Like

    Reply

  2. Hello Karl,

    thanks for replying on the blog directly. Wanted to send you the link, but you have been faster. 😉

    I think the problem is, that the expectations set by the press release and blog entry have been different from what was planned. I’ve talked to some other authors and LaunchPad-interested users, and I’m not alone with my feeling. Some also criticized that even just the rebranding necessary to avoid trademark violations caused too much work. They also had the impression that LaunchPad was to be released for self-hosting, like I was.

    You’re right that the posting in the mailing list makes it more clear, but not everyone is subscribed to the lists and has to rely on the information posted on the mentioned other sources – like I did. 😉

    However, it’s great that everyone on the mailing list reacted so fast when I asked my questions, and that the replies made it clear. I also appreciate that you added a note to the LaunchPad wiki on the primary goals – this surely will help a lot.

    So, thanks again! I’m still sure that open sourcing LaunchPad was the right decision, even if for our concrete plan is not suitable.

    Florian

    Like

    Reply

  3. It’s interesting — nothing in the blog post or any of the other announcements says (or even implies) that we’re aiming for self-hosting, but on the other hand, given that so many open source projects *do* measure their success by number of installations, it’s not unreasonable that you would assume we would too. If I could do it over, I’d put something in the blog post stating explicitly that that wasn’t our goal… But water under the bridge now. I’m glad it’s clarified; thanks for raising it.

    Best,
    -Karl

    Like

    Reply

  4. Hi Karl,

    sure, you are right, but when I heard that Canonical will open source LaunchPad, for sure I thought it will be in a state usable for own installation, and it seems I’m not the only one having this feeling. 😉

    However, as you said, now it’s clear and I was quite impress by the speed my inquiry on the mailing list has been answered. So, from my side, all is well, and now that you added the note to the website, it’s also clear for the rest. 🙂

    Thanks again,
    Florian

    Like

    Reply

  5. I honestly admit that I did not read all the announcements and documentation in detail, but when I first heard about “Launchpad goes OpenSource”, I sure assumed that the code was in a state that would allow me to set up a local instance by myself 🙂

    I guess that is more of a long-term goal then. I would suggest to start with removing all trademark-infringing parts first. Once the legal barrier has been lowered, it’s more likely that others will tackle the technical issues…

    Like

    Reply

  6. What do you think of Indefero? I was not very happy with the FusionForge Interface, and was looking for a similar solution. Codesion came close, but again was a nightmare to set up. I am zeroing on indefero for two reasons:
    1. its very simple – a google code clone
    2. its php-based and so easy to deploy
    (my other option was trac and its not easy to deploy it)

    But i am not sure how wise indefero might prove in the longer run. how is redmine in contrast?

    Like

    Reply

  8. In general, I think it is possible, and I even recall I found a little howto for that somewhere, but I don’t have it handy at the moment. From a gut feeling, you can either try to change the binding of the service, which by default only seems to be at 127.0.0.1/localhost; or you try to route/NAT the local device. In addition, I think the installation created some local resolver names in /etc/hosts.

    I am sorry I don’t have more details, haven’t played with it for a while, but basically this should be an approach you can try.

    Like

    Reply

Leave a comment