A few words about the future of the Limba project

limba-smallI wanted to write this blogpost since April, and even announced it in two previous posts, but never got to actually write it until now. And with the recent events in Snappy and Flatpak land, I can not defer this post any longer (unless I want to answer the same questions over and over on IRC ^^).

As you know, I develop the Limba 3rd-party software installer since 2014 (see this LWN article explaining the project better then I could do 😉 ) which is a spiritual successor to the Listaller project which was in development since roughly 2008. Limba got some competition by Flatpak and Snappy, so it’s natural to ask what the projects next steps will be.

Meeting with the competition

At last FOSDEM and at the GNOME Software sprint this year in April, I met with Alexander Larsson and we discussed the rather unfortunate situation we got into, with Flatpak and Limba being in competition.

Both Alex and I have been experimenting with 3rd-party app distribution for quite some time, with me working on Listaller and him working on Glick and Glick2. All these projects never went anywhere. Around the time when I started Limba, fixing design mistakes done with Listaller, Alex started a new attempt at software distribution, this time with sandboxing added to the mix and a new OSTree-based design of the software-distribution mechanism. It wasn’t at all clear that XdgApp, later to be renamed to Flatpak, would get huge backing by GNOME and later Red Hat, becoming a very promising candidate for a truly cross-distro software distribution system.

The main difference between Limba and Flatpak is that Limba allows modular runtimes, with things like the toolkit, helper libraries and programs being separate modules, which can be updated independently. Flatpak on the other hand, allows just one static runtime and enforces everything that is not in the runtime already to be bundled with the actual application. So, while a Limba bundle might depend on multiple individual other bundles, Flatpak bundles only have one fixed dependency on a runtime. Getting a compromise between those two concepts is not possible, and since the modular vs. static approach in Limba and Flatpak where fundamental, conscious design decisions, merging the projects was also not possible.

Alex and I had very productive discussions, and except for the modularity issue, we were pretty much on the same page in every other aspect regarding the sandboxing and app-distribution matters.

Sometimes stepping out of the way is the best way to achieve progress

So, what to do now? Obviously, I can continue to push Limba forward, but given all the other projects I maintain, this seems to be a waste of resources (Limba eats a lot of my spare time). Now with Flatpak and Snappy being available, I am basically competing with Canonical and Red Hat, who can make much more progress faster then I can do as a single developer. Also, Flatpaks bigger base of contributors compared to Limba is a clear sign which project the community favors more.

Furthermore, I started the Listaller and Limba projects to scratch an itch. When being new to Linux, it was very annoying to me to see some applications only being made available in compiled form for one distribution, and sometimes one that I didn’t use. Getting software was incredibly hard for me as a newbie, and using the package-manager was also unusual back then (no software center apps existed, only package lists). If you wanted to update one app, you usually needed to update your whole distribution, sometimes even to a development version or rolling-release channel, sacrificing stability.

So, if now this issue gets solved by someone else in a good way, there is no point in pushing my solution hard. I developed a tool to solve a problem, and it looks like another tool will fix that issue now before mine does, which is fine, because this longstanding problem will finally be solved. And that’s the thing I actually care most about.

I still think Limba is the superior solution for app distribution, but it is also the one that is most complex and requires additional work by upstream projects to use it properly. Which is something most projects don’t want, and that’s completely fine. 😉

And that being said: I think Flatpak is a great project. Alex has much experience in this matter, and the design of Flatpak is sound. It solves many issues 3rd-party app development faces in a pretty elegant way, and I like it very much for that. Also the focus on sandboxing is great, although that part will need more time to become really useful. (Aside from that, working with Alexander is a pleasure, and he really cares about making Flatpak a truly cross-distributional, vendor independent project.)

Moving forward

So, what I will do now is not to stop Limba development completely, but keep it going as a research project. Maybe one can use Limba bundles to create Flatpak packages more easily. We also discussed having Flatpak launch applications installed by Limba, which would allow both systems to coexist and benefit from each other. Since Limba (unlike Listaller) was also explicitly designed for web-applications, and therefore has a slightly wider scope than Flatpak, this could make sense.

In any case though, I will invest much less time in the Limba project. This is good news for all the people out there using the Tanglu Linux distribution, AppStream-metadata-consuming services, PackageKit on Debian, etc. – those will receive more attention 😉

An integral part of Limba is a web service called “LimbaHub” to accept new bundles, do QA on them and publish them in a public repository. I will likely rewrite it to be a service using Flatpak bundles, maybe even supporting Flatpak bundles and Limba bundles side-by-side (and if useful, maybe also support AppImageKit and Snappy). But this project is still on the drawing board.

Let’s see 🙂

P.S: If you come to Debconf in Cape Town, make sure to not miss my talks about AppStream and bundling 🙂

14 thoughts on “A few words about the future of the Limba project

  1. I personally agree with Limba being the superior design compared to Flatpak or Snappy, since it very much has a “package managing approach” rather than a “just bundle it” approach.

    But I understand the decisions and different points of view, being me, I won’t ever use snappy or flatpak. I want to know what is in there.

    They’re moving the windows way where everyone needs and distributes their own version of libraries, solving the dependency hell, but leaving a app-system with security issues.

    Security issues not for the whole system due to the containers / seperation, but for the specific application having issues with a security hole not updating their libs. And that is a real issue for me.

  2. So what about AppImage? if I understand correctly it’s also a project not backed by a corpo-behemoth. What’s its future?

    1. Not sure, who knows? 😉
      But its author is nice, we were discussing AppStream integration recently, and maybe there will be plugins for software centers as well.

    1. I would love to come there, but I can’t afford to travel to Portland, unfortunately (also, getting the spare time for the conference time would be tricky).
      I am doing quite a lot of conferences and sprints this year already too 😀
      But thanks a lot for the invitation!

  3. Hi,

    My name is Peter and I am the co-founder of Heroes Inc. Heroes is the next growing mobile marketplace platform which can increase your company sales, boost exposure and help it grow nationwide.Thousands of potential customers await to do business with you – get on it before your competitor does.

    Pre-register your free business space on the Heroes marketplace platform at http://www.heroesapp.io. On the website you can find additional information on the benefits you can receive. It is free, but only for now!

    If you have any questions, feel free to contact me to this email address. Don’t forget to sign up now, thank me later. 😉

    Kind regards,
    Peter Goodwin
    Heroes Inc.
    CMO
    371 22826269

  4. Why you say connection one-runtime approach and multiple-runtime approach is not possible? Imagine Limba bundle have description of many bundle and each description contains some fixed version. Each description will contains url to download bundle too, so we connect one and multi runtime approach. 🙂

  5. Hi. I see that you don’t update your blog too often. I
    know that writing content is boring and time consuming.
    But did you know that there is a tool that allows you to create new posts using existing content (from article directories or other pages from your niche)?
    And it does it very well. The new posts are high quality and pass the copyscape test.
    You should try miftolo’s tools

  6. I have noticed you don’t monetize your page, don’t waste your traffic, you
    can earn additional cash every month. You can use the best adsense alternative for
    any type of website (they approve all websites), for more details simply search in gooogle: boorfe’s tips monetize your website

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.