Please address "store is not open-source" again

[BillDietrich]

I know this is a recurring topic. It blows up on reddit every week or two. Snap / Canonical could help to clarify the situation and dispel some of the FUD that detractors of snaps are throwing.

It would be helpful if someone made a new blog post similar to https://ubuntu.com/blog/howto-host-your-own-snap-store If it is possible to easily create a minimal store that basically is a web server, and set a desktop Ubuntu distro to point to that store instead of the main Snap store, that would greatly reduce the criticism. Suggestions such as manual downloading and then installing with --dangerous are not the same.

I’m trying to make suggestions to help Snap in general. Thanks.

[ogra]

there are ongoing threads on that topic, not sure if another one needs to be opened …

Linux Mint 20 disables deb2snap packages, and Snap's growing external adoption problem

The only thing the hardcoded assertions key currently enforces is that each snapd instance is only connected to a single snap store. A different distribution like Manjaro could very well ship a modified snapd to their users which points at their own store. Manjaro chose to use the snap store hosted by Canonical because they like the advantages that gives them. This is no different from how Linux Mint used to point apt on their devices to the Ubuntu repo’s in the beginning and switched to their …

[BillDietrich]

I did do some searching before creating a new topic. Didn’t see that thread.

I’m proposing a fairly simple thing: someone do a blog post explaining what an outsider can do today to create and use their own store, and what they can’t do or can’t do easily.

[ogra]

the post i linked directly (and the three/four above and below that one) explain that pretty well … there are a good handfull of older threads where this has been discussed as well …

[BillDietrich]

A nice 4-paragraph “official” public blog post would be far better than information scattered over many threads in the snap forum.

[egeeirl]

I’ve personally tried to address this topic on Reddit, Twitter, and in streams. The people that believe & spread this FUD do not care about facts. You can link them 1000 times to the Github repo but nothing will change their minds.

As they say - haters gonna’ hate.

[ivo.cavalcante]

While I do agree that, once a hater, it’ll be hard to stop hating, question is why do they hate in first place. I believe many of the criticism regarding Snap is beyond closed source (that is an issue too), but goes more to the centralized control of Canonical around the entire ecosystem. AFAIK, Canonical runs the store (ok), only Canonical employees are in charge of making the rules and vetting requests (not ok), Canonical response for some of the issues raised by community has been won’t fix (not ok_), and so on. Obviously, this is all my opinion and I may be wrong.

Someone suggested involving community in some kind of board to direct and manage store; that would be a good move, I believe. Feeling I have today is that Canonical has a very well defined goal with Snap and Snap Store and is not willing to change direction, despite community reception. While it’s within its right to do so, there will be drawbacks.

Trying to address some issues differently, like auto updates, would help. Canonical is being very strict on this - won’t do - and it may prove right on the long term; but, for now, with all the criticism involved, it’s simply bad. Maybe it would be better to allow for now and revert later, when the system is more mature and broadly accepted - and more stable, since there’s still room for improvement in this front (app refresh awareness, for instance).

Summarizing, I believe there’s a difference between being determined and stubborn. Canonical is leaning toward the second, in my opinion, and even if they’re right in all their assumptions - auto-updates, centralized store managing, etc. - community reception (and participation) should be better addressed. And there’s also the open-sourcedness thing.

Don’t want to offend, just giving my opinion.

[ogra]

@ivo.cavalcante

Maybe it would be better to allow for now and revert later, when the system is more mature and broadly accepted

This is the problem, snap packages are existing since 2014, are in use commercially since 2016 by many customers …

Ubuntu Core (the fully snap based system … read: kernel, bootloader and rootfs are also snaps) is widely used in industrial automation, IoT, medical, self driving cars, robots and embedded setups … many of these setups are mission critical, many of these customers picked snaps or Ubuntu Core exactly because of the features that are being criticized by many in the community.

Changing any aspect of the setup requires a long design process, lots of testing and very deep planning for future stability etc.

“Allow now, fix later” definitely does not fit that scheme …

[ivo.cavalcante]

Yes, I know Ubuntu Core is widely used (evaluating it myself). I don’t see how a toggle allowing disable of auto update feature would put it in danger, though. In worst case, two different versions of snapd - one that honor the flag, another that don’t, all other being the same. Just a thought.

[ivo.cavalcante]

Append: I find Ubuntu Core technologically amazing! Being capable of run a full snap system must have been a challenge. That’s part of why I praise the format, it covers a lot of scenarios. The desktop one, though, need some adjustments; it might not be possible to apply some directives to all of them.

[galgalesh]

Note: the discussion about controlling when updates happen on the desktop is here: Re-visiting update control on the desktop

[BillDietrich]

@egeeirl

You can link them 1000 times to the Github repo but nothing will change their minds.

I’ve looked at the repos and I don’t see anything in there that says “here’s how to make your own store and point your distro to it”. Please give specific links if such instructions exist in the repos.

I think a simple blog post saying “here’s how you set up a web server (if that’s what it is) with some snaps on it, and here’s how you change your snap-using system to point to that store instead of the main snap store” would go a long way. I suspect it’s actually not that simple, or the 2016 blog post and the repo it pointed to would still work; I don’t think they do. Someone should write a new equivalent of that blog post, please.

[popey]

@BillDietrich

I think a simple blog post saying “here’s how you set up a web server (if that’s what it is) with some snaps on it, and here’s how you change your snap-using system to point to that store instead of the main snap store” would go a long way. I suspect it’s actually not that simple, or the 2016 blog post and the repo it pointed to would still work; I don’t think they do. Someone should write a new equivalent of that blog post, please.

Who, exactly, does this help?

With a document such as this, end users don’t care, developers don’t care. Honestly, it’s only the obnoxiously loud peanut gallery on r/linux and click-bait Linux YouTube “celebs” who care about these things.

The vast majority of users want to press a button and an app opens. If it’s not installed, they want to press a button to install it. They don’t care what the file format is, nor the stupid politics behind it. They have work to be done, and these apps need to be easy to install, up to date, and easy to update. Hunting down a repo / ppa / snap store / flatpak repo / appimage is the absolute antithesis of usability.

Stop thinking multiple repos are the panacea fix to all app-install ills. They’re not, and the sooner the Linux nerd community stop being ludicrously and historically obsessive about it, the better.

[ivo.cavalcante]

I agree that multiple stores would do more harm than good. Nonetheless, getting the community closer to “official one” would definitely promote trust and be very beneficial, hence.

[galgalesh]

@popey

With a document such as this, end users don’t care, developers don’t care. Honestly, it’s only the obnoxiously loud peanut gallery on r/linux and click-bait Linux YouTube “celebs” who care about these things.

This is not my experience. In my local hackerspace/makerspace Ubuntu and Linux are heavily used. I frequently get the questions “why is there only one snap store” and “why is the store not open source”. When I explain the rationale and history, they often agree and their views on snaps improve significantly.

There might be a whole second demographic of Ubuntu users that I don’t have direct contact with, and they might not care about these questions, but I suspect that the people who care have a lot of influence over that second demographic. I would imagine that people who don’t care about these things are often running Ubuntu because someone who does care advised them to.

As an example; a popular Ubuntu reseller here in Belgium sells laptops to a lot of people who have never used Linux before. The default Ubuntu 20.04 installation on these laptops does not ship with the snap store; it uses Gnome Software from the deb. As a result, a whole collection of “users who don’t care” will not be able to benefit from the snap store because of how a more technical person views snaps.

I also think that the group of people who care about these questions are disproportionately likely to contribute to open source projects. I have had a case where someone asked these questions and after I answered them they said they’d look into contributing to the ecosystem because they thought the rationale behind the decisions was really neat.

[galgalesh]

I do not know what the solution is, but I think that having a canonical and updated answer to some of these questions might help. Currently, the answers to a lot of these questions are scattered over a bunch of threads on this forum, different podcasts and blogposts.

[BillDietrich]

@popey

Who, exactly, does this help?

With a document such as this, end users don’t care, developers don’t care.

By helping allay some of the FUD being thrown, it would help the Snap organization and community.

Developers (of apps and distros) may be reassured that they’re not becoming wholly dependent on Canonical, that they have a fallback position even if they never use it. It’s similar to Mint’s reasoning for producing LMDE.

People who hate Canonical / Snaps will have one less arrow in their quiver.

Guys, on this one you are fighting a public relations battle. The best way to do that is to publish simple, clear, accurate information. This should not be a huge effort for someone inside who knows the info. Just one blog post.

[sam_vde]

Can they do that and still call it Ubuntu 20.04?

[sabdfl]

We could require them to change it, but we choose not to. Odd, considering what tyrants we are

[sabdfl]

There’s a clever law which points out that the cost of responding to FUD and trolling is much higher than the cost to spread it.

In life, you have to make choices about what’s important and where you focus.

If someone finds it helpful to them to believe that Canonical are terrible people, who am I do deny them that pleasure? It seems pointless and sad to me, but I know from experience that I can’t help folks that don’t want to be helped, or worse, that it’s self destructive to get anxious about people saying toxic stuff. They have an endless supply of arrows if they are willing to invent them and distort them, and infinity minus one isn’t much different

I don’t know if the old open source store code still works.

I do know that the basic conversation between snapd and store is pretty simple - “I have this installed, what should I do?”.

There are of course a lot of things that a good store factors into it’s answers, for example, cohorts and progressive releases and epochs and bandwidth optimization and regional cache offloading etc - but a store doesn’t HAVE to do those things. A simple store could just say “here is the new version for you” and be done.

But isn’t it interesting that the open source store attracted precisely no users and no patches?

My guess is that nobody who is capable of doing that work is so irrational that they think that work is an important use of their time. Anybody who is capable of maintaining a web service like that understands that a really good experience for lots of users doesn’t hang on just having a store, it hangs on connecting a million details across multiple parts of a complex software ecosystem. That’s a lot of work, and it’s work I’m committed to doing so that more people can use more open source.

That feels like a useful way to spend my time. It’s also going to attract controversy, because people abhor a vacuum, and I’m just not going to get distracted by that.

We should engage in a healthy way with people who want to engage. There are things for us to fix, particularly in desktop integration and performance. Let’s focus on those people and those issues.