OBS shut down and next steps

It seems the announcement of closing OBS has ignited confusion. I’ll try my best to open details related to what has caused the decision. The main rationale has two factors:

  1. The cost of maintenance. The service has not been maintained in a long time. We are at a point where we need to decide if we want to invest development time to keep the OBS alive and working. When deciding on the investment, we analyzed how the service is used and how often it is currently used, by ourselves and the community. We also evaluated if the additional investment will enable us a more efficient Sailfish OS development environment. As a result we concluded that we are not using it internally or with our commercial partners and there is no clear path how we could develop the OBS so that it would solve our future needs.

  2. Jolla as a company has legal responsibilities. We do not want to carry the risk of hosting content that we do not have means to review and validate.

In addition, there are secondary factors that justify the decision. There is a need for offline development environment for adaptations and apps development, and in addition we cannot find all the build-time problems with OBS. We need to innovate new ways to solve these problems. In fact, there are already available solutions that can be used outside of OBS. Our conclusion is that we should focus on improving these new processes and ways of working.

We want to address the known issues that this causes for Sailfish OS ports. For example we are updating HADK, as a result OBS is no longer needed for porting. We will also deliver the instructions for the community on how they can host updates for their ports. We are open for workaround proposals, discussion and questions in this thread. For example we would like to understand what are other major use cases for OBS that are no longer possible - can’t promise we can address all of them, but we want to know if there are any issues where we could help.


Thank you for this explanation!

Not being a developer but a user that greatly benefits from the work of Jolla and the active community members, I see that Jolla needs to serve the paying partners first and hope that Jolla can nevertheless still motivate community members to develop and maintain apps for SFOS.

I hope I will be able to continue using Sailfish-phones as my main phone. Only once in a while, I look at my company’s iPhone or an Android phone not yet converted to SFOS only to see that I do not like these phones and that I really do not need them (yet). My impression is that this is achieved by both, Jolla and the community.

So, please, stay an good terms with the community


I don’t think there has been any confusion, the situation seems pretty clear.

Jolla has decided to unilaterally remove something widely used by the community without consulting us, and only now after noticing some backlash do you want to understand ‘other major use cases’.

I hope you have much success with your commercial partners because it seems this community isn’t high on your priority list.


@r0kk3r: How difficult or easy is it to develp apps for SFOS? And how important is (was) OBS?

Of course I notice that the native apps I use - with the exception of phone, calendar, email, messages and browser - are created by community members like you. And I am indeed worried about the development of native apps for SFOS that serve the needs of users like me.

From this perspective, the burden for the community developers should be as low as possible in order to make developing for SFOS as attractice as possible (despite the low number of users)

So what could/should Jolla do?


Just stop talking that community is important to them.


I would argue against, we have a fairly good understanding how OBS is used in the community. We also think that we are able to support or even provide solutions for the majority of scenarios it is used in. But I think there are also cases where we can collaborate. I don’t think all of these required solutions or work arounds are something that is or should be dictated by Jolla, instead they would be optimal if they would be created in collaboration and from the interest of the community.


So is the OBS shutdown happening after tools and infrastructure for devs is available and they had time to migrate or is it happening before that? To me it seems like the community doesn’t know how to not depend on OBS yet, especially regarding ports. I hope you can keep OBS and the discussion alive, until most of them found a different solution and you can make the transition as easy as possible. Otherwise I fear the community will lose a lot of competent devs and that would make sailfish a lot less attractive to me as a user (and sometimes developer).


I hope you can keep OBS and the discussion alive, until most of them found a different solution and you can make the transition as easy as possible.

Correct, this is the intention.


Let me formulate my point of view regarding OBS and reply to your question regarding the use of it outside the ports. I am going to skip the confusion part, as it has been discussed in other threads.

I develop map applications which tend to have a large number of dependencies. Currently, we are talking about a project with 17 packages. In addition, Flatpak development required 7 packages to be organized in a project. Having it all on OBS makes it simple to follow SFOS releases, allows me to deal with the actual work and not worry much about technical bits that make compilation and packaging happen. Without OBS, I would probably not start working on Flatpak and my maps apps would be way under-developed.

Let’s get to the factors.

  1. Cost. This is hard to judge for me from outside and, as such, we cannot have any idea regarding it unless there are some numbers behind. Would you mind to specify running costs that would break down personnel, hardware maintenance (such as replacing bits), and network traffic cost? I presume you have these numbers and they may reflect your valuation of community using OBS.

  2. Legal. OpenSUSE OBS has the following document: https://en.opensuse.org/openSUSE:Build_Service_application_blacklist . They are in a similar situation where they allow to develop and build on their service while being a company. In contrast to you, they prefer to keep it running and open.

You have voiced your arguments and we still don’t know what is going to happen in terms of alternative solutions. I presume, from a legal point, you want to avoid hosting as well as otherwise the legal benefit goes away. Hence, ports and apps will have to be hosted by someone else, someone who can handle that cost.

Let’s see what you are preparing as solutions outside OBS. As far as I understand, nobody knows technical details yet. One alternative, would be to

  • reconfigure OBS to follow upstream as much as possible. That should reduce the personnel costs through reduction of maintenance.
  • plaster a big warning regarding legal aspects on OBS site, in a prominent place.

Would you purge OBS repos and sources, or you will make backup of user repositories and sources uploaded directly to obs for building?


Worst case, would Jolla either
a) hand over the whole OBS infra as-is to community ?
b) document the whole OBS settings/configuration/targets so community can set up its own instance ?


The underlying problem appears to be that the community is small and not even growing. At least this my impression, not knowing any figures.

In this situation, Jolla has to decide how to deal with the community. Apparently Jolla is trying to reduce the effort spend for community issues to a minimum - which of course has a negative impact on the community.

@atlochowski has clearly expressed the impression: community does not matter (anymore) to Jolla. Please let me be clear: I mean, this is the impression. Maybe it is not, what Jolla is intending. However, just saying the community is important will not be enough.

At the beginning we all had hopes that Jolla would be successfull in the consumer market (Jolla 1, Tablet, Aquafish were all addressing the consumer market). For reasons I do not know - and despite a good UI, access to at least some Android apps etc. - these hopes did not materialize. Does this mean, Jolla should stop dreaming and cutting ties with the community as a consequence? I do not know, but leting the ties slowly die is even worse.

@rinigus correctly addressed to economic aspect. If Jolla cannot afford to maintain an infrastructure that helps developing apps for Sailfish, then this might be bitter truth and might kill Sailfish X - and even this forum would be obsolete.

The migration to this forum indicates that Jolla has not yet decided against the community. To give Sailfih X a chance, Jolla should make developing apps for SFOS as easy as possible.

So it is not (only) a question of communication, but also (and even more so) a question of mere facts (i.e. tools for devs, for instance)


That’s exactly what we are trying to do. What seems to be forgotten in this discussion is that we have quite a rich set of tools for developing apps: https://sailfishos.org/wiki/Application_Development#Software_Development_Kit

OBS is not used by the majority of app developers, and it can not be considered easy to use, at least if you compare it to our SDK. We have spent quite a lot of effort improving the SDK - during the last two years we have introduced command line tool sfdk, cmake support, docker based build engine for improved performance (while improving also the VirtualBox based build engine). It’s definitely not perfect yet, and we will keep on improving it in the future as well.


We try to use the efforts in efficient way. Many of the public services we provide need maintenance, improvement and updates: Shop, Jolla Store, jolla.com, sailfishos.org, harbour, this forum and so on. The services all need time and effort from the same team and we haven’t been able to keep up with maintenance needs as well as we would like. That is why we believe that we need to reduce effort on the less used services, so that we can spend more time on maintaining the more popular ones.


If the maintenance is the main reason, we could look into how to share OBS administration with the community members. We would probably have to look into reduction of admin effort required by OBS, but this is completely different approach when compared to shutting it down. In particular, it would keep ability to build from source to distribution of the packages in one go. As mentioned above, such stack as provided by OBS, allows to work on complex apps, in addition to the well-known ports case.

@vige, the stack for apps development is good, indeed. Especially for regular apps. We are over here talking about more complex cases and ability to distribute the work (ports and apps) through OBS. Surely it is not used by majority of app developers, as there is no need. But it does benefit some apps. As for ports, OBS is something that is highly recommended before publishing the port.


The fact that everyone here seems focussed solely on apps development shows you’re missing the point.

OBS is useful for developing and extending the sailfish platform itself, with a number of community contributions being developed on there.

There is also nemomobile who use it as their primary package source, with lots of work going into testing with newer Qt, GCC, and full arm 64 builds.

All of this has material benefit for sailfish, and removing OBS as a central workspace will make it harder to build upon the work of others and collaborate on things which benefit sailfish as a whole


So far, rinigus has nicely covered how OBS is useful for managing complex apps with many deps, and r0kk3rz has covered how OBS is used by other parts of our community such as nemo.

Im sure you know the use cases already, but I just want to ensure that whatever you come up with as a replacement also meets the needs of porters.

  1. OBS allows us to easily manage development and release builds and promote from one to the other
  2. OBS allows us to easily maintain releases for different sailfish versions, and allows users to use this to upgrade between releases
  3. OBS provides a common location to host releases. I cannot stress enough that I would not want the hassle of maintaining my own server space for the release repositories. All ports get to share the same format URL and this provides consistency across the platform. As you are concerned about the legal issues of hosting on OBS, im intrigued how this will be managed in the future.
  4. OBS provides the community common: and native-common: repos. Will the community continue to be able to feed into these repositories that are common across ports?
  5. OBS allows us to quickly update and rebuild mw libraries (usually in the quick but hackish _service edit), and have dependant packages rebuilt automatically. This makes it pretty easy to trigger mass rebuilds. I wouldnt want to do this locally … im sure some porters have server setups, but im running on a 6th gen core i5 laptop, and remote builds are a dream!

Non-porter related:
6. While the SDK is great for most application development, it is not so great for building support/mw libraries. For example, Amazfish uses several KDE libraries which are built on OBS.

I hope that whatever solutions you look into will cover all these requirements for a seamless-as-possible transition.


That’s an interesting suggestion worth considering, but we would also need to find some solutions to other concerns.


Are the other concerns the legal part?


When managers hold endless meetings, the programmers write games waste their time. When accountants talk of quarterly profits, the development budget is about to be cut. When senior scientists talk blue sky, the clouds are about to roll in.

Truly, this is not the Tao of Programming.

When managers make commitments, game programs time wasters are ignored. When accountants make long-range plans, harmony and order are about to be restored. When senior scientists address the problems at hand, the problems will soon be solved.

Truly, this is the Tao of Programming.