Jolla store - what is the plan?

Store QA
#8

Being “well written” is always a good thing, no doubt about that, regardless of where the app is. But I wouldn’t call Jolla Store dead just yet. I submit my apps to both places, even if that sometimes involves bending the rules a bit, except when there’s no chance whatsoever to fool the evil Harbour Validator script. The motivation behind it is quite simple - the more people see my app (and hopefully find it useful) the better. But that’s just me, of course. I have no way of knowing why other people are doing it.

Yes, OpenRepos may be much more convenient for developers but quite obviously Jolla Store is more convenient for users. So I guess it’s a question of what matters more to you - the process of programming, or the end result and the overall user experience. Since we are doing these apps for free, nobody is going to blame you for doing it wrong :slight_smile: It’s your choice and you can do whatever.

The Harbour rules may seem arbitrary from the first glace but in most cases there’s logic behind those. If nothing else, every API allowed in Harbour is an obligation for Jolla to keep that API backward compatible across releases which limits the development and design choices. It’s something so natural to try to avoid when you’re a platform developer.

9 Likes
#9

This conservative approach is what makes the store a semi dead place. And it deprives the store user from some really usefull apps.
And i get that devs will be pissed if the api breaks and they’ll have to fix it. But i prefer having a few pissed devs that might have to tweak a thing or two during EA than users that cant enjoy good apps.

3 Likes
#10

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
#11

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
#12

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
#13

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
#14

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.

#15

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)
    ?
Community meeting on IRC 12th Nov 2020
Community meeting on IRC 17th Dec 2020
#16

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
#17

Maybe bring it up in the communitymeeting at 29th?

3 Likes
#18

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

#19

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

1 Like
#20

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

2 Likes
#21

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

1 Like
#22

Should we bring this up at the 12th?

#23

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

#24

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
#25

Yeah, sounds good to me.

#26

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.

#28

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