Jolla store - what is the plan?

I wanted to take this opportunity to thank you for providing us with SFOS apps for years.

User matter a lot to me but my counter argument to this is that every minute wasted on trying to invent creative ways to circumvent Store validations is also time not spent on developing, maintaining the app which would benefit users as well.

4 Likes

I would like to know whether application developers really want Jolla to fulfill this obligation or prefer more APIs allowed in Harbour (accepting that it may break more often):

This poll is for all people who have written/are writing Sailfish applications:

  • stable APIs are very important, number of allowed APIs/libs in Harbour unimportant
  • something in between
  • stable APIs more important than number of allowed APIs/libs in Harbour
  • no preference
  • potentially unstable APIs ok (may break roughly once in 6 months), want more allowed APIs/libs in Harbour
  • potentially unstable APIs ok (may break roughly once in 3 months), want more allowed APIs/libs in Harbour
  • bleeding-edge APIs

0 voters

edit: can’t edit the poll anymore, but “something in between” is between “stable APIs are very important, number of allowed APIs/libs in Harbour unimportant” and “stable APIs more important than number of allowed APIs/libs in Harbour”

I think that, given the current release cycle, Jolla could allow more unstable APIs in Harbour, because releases are far away from each other. Even if each second Sailfish update breaks something, it’s not that often.

The only problem I see is communication:
As an application developer, I would like to know beforehand (even before early access, since it doesn’t give that much time) what will probably break. For this, it would be enough for Jolla publishing a “volatile” change log which gets updated as soon as the internal work on some component is done. That is, it’s clear that it will probably make it into the next release - if you are unsure, you can still add a warning like “don’t take anything written here for granted”…

And finally: Considering that most applications are open source and can be recompiled easily, Jolla should save resources and shouldn’t try so hard to maintain ABI (binary) compatibility.

3 Likes

That’s quite a developer-centric approach.

Obviously, regular users won’t be able to recompile your app. Even I am unable to compile most OpenRepos apps, although I’m quite an experienced developer. Almost every app (or at least every author) requires some special tweaks and tricks, turning the build process into an adventure for an outsider. Very rarely you can simply create a project in OBS or open it in Qt Creator on your laptop and build it. It just doesn’t work that way, let’s face it. And BTW, that makes it hard (pretty much impossible, with exception of pure QML cases) to contribute, but that’s a different topic.

In practice, if you don’t spend efforts on keeping your app compatible with earlier releases of SFOS, it will very soon only work on the exact version of SFOS which you’re developing for and maybe a release or two after that.

If you do pay attention to compatibility, then there’s no reason to not just compile it for the oldest supported version of SFOS and it will work on all subsequence versions too, thanks to ABI compatibility. And that’s what users expect - they expect to install your app on their (not your) version of SFOS and they expect it to keep working after upgrades. It’s impossible to achieve that without maintaining binary compatibility.

I’m on the user’s side in this dispute))

5 Likes

Yes, but my point is that many applications are dead many years and they are still in the store. It would be awesome to remove those apps, so the store is not cluttered by unusable apps.

And to openrepos and jolla store. I think if everybody who publishes on openrepos published also to jolla store, everybody who uses would benefit from it because more people would be attracted to use Sailfish.

2 Likes

It would be even more awesome if apps didn’t die, except perhaps by their own hand. The current approach seems to do a pretty good job with that.

True. However, my personal experience is that everybody I’ve met in meatspace using Sailfish has some kind of developer/Linux power user experience, so I am a bit biased…

I think we all are, but we are all unsure about what’s the best way. :slight_smile:

Unfortunately, these wishes are contradicting :stuck_out_tongue_winking_eye:

Would it save considerable resources (which are then free for e.g., the browser) to

  • drop maintaining ABI compatibility at all costs (which is my impression currently), so that old, unmaintained apps die after some time, but apps where the dev is still active are just recompiled by the dev; while
  • continue to enforce stable APIs in Harbour (the amount of stability could still be discussed)
    ?

But from a user perspective, what is the point of having 5 year dead app in the store? The main reason I posted this was to make Jolla and their employees have a look at it and remove those relicts, which only distract and make Sailfish look like a dead OS. Sadly no one from Jolla responded.

8 Likes

Maybe bring it up in the communitymeeting at 29th?

3 Likes

True, they should better abandon that thing altogether and point new users to OpenRepos and Storeman instead :smile:

Yeah, good idea, but I am not sure if it is enough for whole topic.

1 Like

Maybe, or just left those, which are maintained. But some cleanup would be appreciated.

2 Likes

Well, if its a short topic, its a short topic… shouldn’t be an issue I guess?

1 Like

Should we bring this up at the 12th?

Yes, thank you, if you have something, to which it can be attached, it would be awesome.

What if they would start an open accessible version control hosting for the jolla store - like github/gitlab/gitea - so that people can send pull requests for the listed apps and the developer just needs to approve them. Furthermore you would could see the source coude you are running on your device.
App problems could be reported over there too in the issue section.

3 Likes

Yeah, sounds good to me.

Can someone of you discuss the whole topic at Community meeting on IRC 12th Nov 2020? I’ll be there too and would join the discussion.

Here is the topic. If you disagree with something or want to add something, let me know.
I tried to compile questions towards a small area for now, other directions may better fit into a separate topic (at another meeting ?!)

3 Likes

Thanks, looks good to me. Yes, we can extend it on thursday or discuss at another meeting. Let’s decide in the meeting.

Very nice. Thank you!