Snap Store is supposed to be distribution-neutral. However, “Ubuntu SSO” is not distro-neutral.
Maybe the branding needs updating, but then it is an SSO to Ubuntu services, making it still feel not distro-neutral.
Perhaps a GitHub-based sign in would be a better idea (like Elementary OS)?
GitHub is very developer centric, but otherwise yes, I agree we need to look into other sign in options.
That is good to know.
Another question hit my head that hasn’t really been answered: What about the payments? Currently (Ubuntu Store) takes a 30% cut of store payments.
Any news on my thoughts above?
Well there’s no public plans yet for a joint ownership of the snappy store. As I said, Canonical are investing a heck of a lot of time and money into the snappy project and it would be difficult to organize some sort of joint ownership, though that would certainly be ideal! So I’m guessing there’s no progress on that yet. And, as per the snapd roadmap, there’s a heck of a lot that still needs time invested in and these are features required by people wanting to snap their applications.
Do you have a source for that? I guess that helps pay for store maintenance.
Don’t know, to be honest! I’m not aware of any such protection - but this is off-topic, you should open a new thread for that question.
What do you mean by that? Again, sounds off-topic and needs a new thread.
I know there are no plans, but I think there could be something differently done here. Yes, Canonical should not develop federation with more important things coming. However, without any plans for federation, this really could scare away potential snap users. I just wish Canonical would write up a “this is the plan, we don’t have it implemented yet, but this will happen (eventually).” Mainly to dismiss the fear of Canonical controlling everything argument.
https://www.ubuntu.com/legal/terms-and-policies/developer-terms-and-conditions
Section 4.B:
I will open up a topic for these soon. By APIs, I mean things like In App Purchases. Yes, I hate the “you can’t pay for this app, you can only buy IAPs for it.” spirit. However, I do believe that In App Purchases have a place in the Snap Store, though there should be some requirements on how they can be used.
New topics coming.
Whilst frustrating I suppose people are entitled to use that argument to avoid snaps if they please!
The Snap Store server is currently not open-source, we all know that.
There used to be an open-source Snap server implementation, but that no longer functions and has been discontinued.
Currently, it is said the reason the Canonical Snap store implementation is proprietary is because it uses so many parts and is rather complicated.
Is it part of the roadmap to make the Snap store open source eventually or not?
This was mentioned quite a few times on the External Repositories thread, but the question as to whether the server would be open-sourced was unanswered. Because it is a complicated subject (I am told), I made a separate discussion for this.
No, it’s not part of the roadmap.
Would it be hard to open source the Snap server?
Perhaps from a different angle, why isn’t the Snap store open source in the first place?
Or is this yet another question to be answered when the thing called Federation is resolved?
Yes, it would be hard to open source.
It isn’t open source because opening it would be expensive in resources, for little to no benefit for users.
Federation is distinct from the store (please don’t continue glomming different things under a single topic…), and is not something we have on the roadmap either. Again, the (arguably tiny) benefit for the user comes at a huge cost (this time in complexity of the code).
Why is the code so complicated? I thought Mr. Shuttleworth said these were “just” HTTP servers.
Also, the reason I brought up Federation is that, perhaps, each distribution would want to host their own server.
@G.S.1 I’ve provided in-depth information in this thread about those issues you brought up again, including in particular why the store isn’t open source, so I’ve moved your question here.
@niemeyer Yes, I did gain a lot from this discussion.
I was more wondering, why it is so hard to open-source the Snap store. Like, yes it is complicated, but what proprietary software is there in it?
Or at least, why can’t Canonical open source part of what is closed?
The vast majority of the project is public and open source, already!
Other bits are not open source for multiple reasons, some of which have been detailed above already in a previous response to that same question from you, two months ago.
@niemeyer Woops! Sorry, just so many discussions have gone on… forgot about that…
Interesting.
Well, this will be interesting.
Linux Mint has announced support for Flatpak instead of Snap, and the reason listed: Snap doesn’t allow external repositories.
http://www.omgubuntu.co.uk/2017/10/linux-mint-18-3-adding-full-support-flatpak https://blog.linuxmint.com/?p=3418
I started this thread, so I would say (in my opinion) as ever that we need External Repositories over convenience. However, Snap developers have their viewpoint and I respect that and understand where they are coming from. Just spreading the news this time.
Flatpak is also flexible and doesn’t rely on a middle-man between the editor and the users. Editors and users can choose to rely on centralized app stores if they wish… but they don’t have to. For instance, an editor could ask Flathub to publish its application but it could also publish it directly, or even create its own store (i.e. “remote”). And downstream users could very well set up their Flatpak client to point to either Flathub or the Editor’s store directly, or both of them even. That flexibility is key and it contrasts with Snap which wasn’t designed with multiple repositories in mind.
Aren’t snaps already supported in Linux Mint? A quick search makes it look like so.
If anyone has issues with their snaps running on Mint, please let us know and we’ll look into it.
Snaps are supported in Linux Mint mostly. However, they don’t map to bash, e.g. you have to type “snap run xyz” every time rather than just “xyz”.
Looks like /snap/bin is not in PATH then, I wonder how that happens unless snapd is modified there.
