Open sourcing proceeding

Greetings Sailfish Community!

Finally Sailfish Weather is out now! There are other repositories and components in the pipeline. Like discussed during community meetup at Tampere Plevna 2nd July, we’ll continue open sourcing in phases during Q3/25.

Phase 1 - Q3/25

  • Selected components to help device porting
  • Device encryption components
  • Accounts plug-ins, excluding Microsoft 365
  • Device side MDM API
  • Camera & Gallery apps
  • The (in)famous Weather app
  • Notes app

Phase 2

  • Q4/25 and forward
  • Based on phase 1, feedback and areas of interest & activity

Starting point

We’re starting from the Sailfish Weather as many of you have requested it, it used to be a really handy in the Events View and you have even changed Weather app forecast to use the OpenWeather API. Next one could be Sailfish Camera app – please share your thoughts and stay tuned :crossed_fingers:. Having Sailfish Weather on Event Views would be awesome!

Thinking is that together we can do a great camera app that we’d all enjoy to use. We started a good discussion on possible other improvements in the past community IRC meetings (referring to previous forthing). Like discussed at the Tampere community meetup, we’ll adjust these based on your needs, contributions and wishes. We surely listen them.

Contribution License Agreement

With our limited resources we decided utilize the Harmony (HA-CLA-I-ANY) Version 1.0 Contribution License Agreement (CLA) similarly as we already have in use for Sailfish Documentation. The CLA will be applied on repository basis.

Existing repositories on the Sailfish OS · GitHub will remain as they were.

Please enjoy! Let’s keep on working together!

75 Likes

Kiitos paljon! Thank you!

5 Likes

This is fantastic to see finally open sourced :tada:

Much thanks to the team.

10 Likes

Best news in a while, thanks for that! :hugs:

5 Likes

First based move in past 5 years at least

>Selected components to help device porting

what does that mean? opensourcing volte plugin? Or fingerprint plugin?

10 Likes

Building Translations

Like with many Jolla-maintained application packages, the .spec of sailfish-weather has

BuildRequires: %{name}-all-translations
Requires: %{name}-all-translations

These packages are not available on the Community OBS, hence building there will not commence.
Will these packages be made available as well?

What is the recommended workaround if not?


One WA is to have, in the same OBS project, a dummy RPM which Provides: the mentioned package.
Using prjconf to Ignore: the dependency does not seem to work.

6 Likes

This opens a rather interesting question that I failed to comprehend since I’m retarded.

Uhh, does this now allow us to possibly improve upon the apps with PRs, or just make us feel better that we got them opensourced? I guess that it would be theme like with the rest of Sailfish OS stuff, but getting stuff merged into the repos sometimes takes much longer than is needed for even some of the most basic stuff.

Just asking…

1 Like

@nephros the fix is probably like this

but I still need to check few things around that stuff.

8 Likes

Sure you can remove them, but that may make it harder for Jolla to build properly internally, right?

Maybe something like

%if 0%{?_jolla_release_build}

BuildRequires: %{name}-all-translations
%define _all_translations_version %(rpm -q --queryformat "%%{version}-%%{release}" %{name}-all-translations)
Requires: %{name}-all-translations >= %{_all_translations_version}

%endif

Or one of the %with/%without options to RPM.

1 Like

The BuildRequires on the translations package is only for getting the version for the Requires, so it does not really affect the build it self (except that it actually causes some extra rebuilds).

What I need to check is why the versioned dependency was introduced originally, because I think it is not necessary, but there must have been some reason for it.

5 Likes

This is fantastic news - thank you and much respect for walking the talk!

4 Likes

Amazing news! Thank you <3

3 Likes

Dear @Morc ! One key priority is that this enables us to work together for Weather app. Secondly, I strongly feel that openess builds trust as you can go and inspect the source code. When it comes to getting stuff merged, it is greatly process related. That said, eventually we need a merithocratic system to GitHub repos where you can gain various rights such as review rights, merge rights, component owner and so on.

22 Likes

Raine, that’s amazing to hear!

I had to ask especially because I feel like adding a feature or two to the Notes app (if not even some others like the Weather app?) and actually not having to reimplement it in a custom app from scratch would make it cooler from the OS/community standpoint where the particular features could be in the system app directly, it could be obviously nice because that would actually improve the experience for everyone else and it could especially feel cool for us contributors since we can actually get the chance to pitch in with our own things without needing to rely on the aforementioned custom apps or kinda helplessly wait for Jolla with their “limited R&D” with which you obviously can’t always fulfill everyone’s requests. Thanks again for the clarification!

p.s. btw, sorry for the harsh tone of my former message… Oops :upside_down_face:.

10 Likes

Is the process already defined? Being worked on? Documented (and published)?

Sorry if this sounds a bit annoying, but I’m very interested what the requirements/expectations here might be.

Also, publishing that will help potential contributers to know what precisely to do work on, and not to waste time with things that are not going to be accepted.

Also: can we help coming up with a good process in some way? There’s precedent of the community coming up with something like that: the Bug Coordination effort worked well (for a time) for example.

7 Likes

Yes @nephros it’s defined. You have a very valid question – I’m not taking this personally at all, don’t worry. It’s our internal policy but we likely need to be loosen that a bit without loosing code quality. I wouldn’t lay down the policy yet. Let’s see how everything starts rolling.

Meanwhile one can check Collaborate | Sailfish OS Documentation documentation. We’ll need to update that to be more fitting for us all – also you are free to propose how the policy should be for example by proposing a pull request to Collaborate doc. Also Docs review guideline (CC @vige) is very much applicable for a generic Sailfish contribution as well GitHub - sailfishos/docs.sailfishos.org: Source for the docs.sailfishos.org site . Let’s be pragmatic regarding this.

We’ll get back to this important topic. Thank you @nephros for raising this one.

18 Likes

These are great news! Thank you Jolla to open yourself after such a long time. It feels like we are now charting a course for a more transparent and collaborative horizon :sailboat: :fish:

7 Likes