External repositories

#170

Sorry, I was a little sharp with my comment above. Of course I support the work of snap, I meant it as an illustration of how this whole conversation feels.

#171

I’m closing the topic, as it’s no longer meaningful discussion.

#172
#173
#174

re-opened. Please keep in mind this topic is controversial, so try to keep things friendly. Failing that, keep it polite.

#175

I don’t know what is controversial about this topic. Looking at the posts, I don’t see any that argue for the current position AND are not from the Canonical team. It rather looks like there is a rare unanimity about the fact that users should have the possibility to add or set up and operate independent “stores”.

I’ve been looking at (and tempted by) the Talos II Secure Workstation. Now of course Canonical’s store doesn’t build or host POWER binaries. Fair enough, it costs resources and the demand would probably be way too small to justify that. But then what? The user obviously won’t be able to access any of the open source software available from snap (such as the latest versions of LibeOffice, for example), but he (or she) also won’t be able to build them locally automatically, since snap doesn’t offer a way to download the corresponding snapcraft.yaml. And assuming he goes the trouble to retrieve upstream source code, obtain the snapcraft.yaml from the package maintainers, then build and test it on POWER, there will be no way to let the rest of the community benefit from his effort by creating a dedicated POWER store.

This is but one example of a scenario where the current model doesn’t fit legitimate expectations of FOSS users.

#176

It definitely does provide ppc64el … snaps of that arch are just rare i guess because you need to use launchpad to create them (vs simply having build.snapcraft.io pull from a github tree (which builds x86 and arm in 32 and 64 bit))

"Large container deployments" usecase - where are we at?
#177

3 posts were split to a new topic: Flatpak on Ubuntu Core

#178

Just want to leave my two cents here. I’ve read the reasoning given by @niemeyer et al regarding user experience being the central focus, as well as the Snap Store being based on internal architecture making it difficult to open source. As a software developer, I fully understand these issues and choices.

Others have already sufficiently exhausted the philosophical arguments regarding decentralization and what it means for software freedom, and I fully agree with this. The Canonical devs do not seem to concur, but I think opposing sides of this philosophy do not necessarily need to translate into mutually exclusive implementations. I think a compromise can exist, where Snapcraft can be configured by default, and most users never need to think about adding custom stores/repos. PPAs could not do this because Canonical was the sole packager for the official Ubuntu repos, but that is not the case for Snapcraft. I think in practice, even after adding the ability to have multiple simultaneous stores, the vast majority of packagers of public software will still choose the central Snap Store because that is simply the easiest thing to do, and gives the end user the best experience. But at the same time, having the ability to host one’s own store clears a big hurdle for many seeking to use snaps.

I know it was mentioned that it is possible to work with Canonical to run a “branded store”, and that may well work for many companies. But there are many where that is not a practical solution. From my own perspective, my own company would never consider such a thing. It is simply too much to manage to have to coordinate with someone at Canonical in addition to any work it takes to manage the infrastructure, especially for a small team, and especially if it comes with a significant monetary cost. For us to even consider adopting it for internal use, it must be possible to spin up and maintain a server easily using nothing but the documentation. I suspect there are many other companies that manage their own infrastructure that could not even consider using snaps internally without an option to easily run their own internal repos. And you probably won’t hear from a proportionate number of them.

Another big blocker for us is not being able to disable automatic updates, but that’s another topic.

After this discussion has been open for a couple of years, and it’s still going—not to mention countless other discussions outside of this site—I think it’s pretty clear that there is high demand for it from the community. I understand prioritizing it among the undoubtedly lots of other work around the project, but it seems like Canonical’s opposition has less to do with available resources and more to do with something else not being stated explicitly. It would help a lot if the message were “we’d love to support this, but don’t have the bandwidth right now,” but we’re not even getting that. So I can’t even keep Snaps on my radar for future use.

#179

a brandstore is a secret (or at wish, not secret) “leaf” of the global store that functions for you as a user exactly like the global store, the only maintenance overhead is a web-form where an admin user of your company manages user accounts, permissions and a few other aspects.

there is no separate infrastructure.

infrastructure, availability, security and maintenance all come for free with a brand store at the same level as the global store (and managed by the exact same teams).

a brand store also allows you to upload kernel and gadget snaps at will and gives you access to the snapd-control interface. if wanted you can also define your own (looser or tighter) security policies for single snaps in it.

not having to do any maintenance of store infrastructure (plus extra freedom and control) is exactly what the money is for. it directly tanslates to labour, service availability, security and control.

#180

@ogra thanks for the explanation! However, I fear this would not be acceptable either, as the company would not want our internal software packages hosted by an external entity that we don’t have control over. The infra maintenance isn’t the main concern by itself—that’s unavoidable in many cases—it’s having to communicate with an external company if anything goes wrong that needs fixing. We need control over it so we can fix it fast. Not to mention company wide concerns about IP.

Also, it may very well be that these are issues Canonical handles very well. You may respond very quickly to outages, and you may have tightly controlled privacy procedures in place to ensure IP leaks don’t happen. But I would have to make a convincing case up several levels of management to hope to adopt Snappy. And honestly it’s not worth the effort when other self-hosted solutions exist that work off the shelf.

#181

well, i didnt mean to talk you into buying a brand store, i just wanted to point out that the money people pay is actually spent for relatively solid return values (plus for keeping the global store up and running for free) and not for paying for marks garden parties. :wink:

#182

If being charitable and taking the developers at their word - it’s due to philosophical differences over how things should be done.

If being less charitable, possibly in addition to the above, it’s quite obvious to see that Canonical may receive less revenue to develop snappy if they allow users to easily create external repositories and adjust stop automatic updates - there would be potentially less demand for the paid branded stores and snap store enterprise proxy, respectively. They may not admit it, but perhaps we need to think of credible alternative forms of revenue generation for Canonical if us users want our own way on these two issues - and/or convincingly show that demand for branded stores and the enterprise proxy would not fall if we had our way on these two issues.

#183

I mean if anything, I would expect revenue to stay the same or maybe even increase. I am not super business savvy, so take my opinion with a grain of salt, but I see there being two different markets: those who prefer to host their own solutions and those who prefer to just pay someone to host and manage it for them. It’s a pretty common business model for open source software companies to offer their source code for free for those who want to self-host, but offer a managed solution as well for revenue. Obviously they don’t get any revenue from those in the former, but I wouldn’t expect them to anyway.

There may be some who would discontinue their subscription and move to host their own infra if the server were open sourced; but on the flip side, I think there would also be some who try out Snappy with a POC self-hosted store, decide they like it, and then make the decision to buy a hosted subscription based on their positive experience.

#184

Yes there is a possible scenario in which revenue would increase, but it’s possible (and this is just speculation as we have little choice but to resort to speculation on my less charitable interpretation of why Canonical aren’t shifting on these issues) that they have concluded, for themselves, internally, that revenue would fall. We’d have to have some pretty good evidence to convince them otherwise. Maybe there’s a case of a program that originally took snappy’s current business model and then moved to the one that you’re describing, and their revenue increased (or fell)? Examples (case studies) like that would be handy for discussing this issue further. Ideally a systematic academic paper assessing the evidence, if one exists!

#185

From my humble and personal point of view, as a developer dabbling in some parts of the stack involved, getting the whole chain-of-trust assertions thing to be obviously correct when the graph isn’t a tree would be way beyond my abilities. So I’m glad we don’t have to do that.

#187

Hi,

This thread discusses the possibility of using Branded Stores as alternatives to dedicated repositories to other Distros. However, and I don’t know the veracity of the post, it seems that Branded Stores carry significant monetary costs. This comment https://forum.snapcraft.io/t/disabling-automatic-refresh-for-snap-from-store/707/247 says 15k per year. Such cost might make this very difficult for some distros wishing to use snaps but curate the selection presented to their users.

Is there an option for distros that would like to offer a more curated snap experience?

thanks,

#188

i’m not someone who could make such a decision, but if a brand store would be considered a solution for a community project, i doubt canonical would write a bill for it :wink:

#189

That’s very good to hear. I would suggest a more official announcement could make inroads into the goal of a universal Linux store. I won’t lie, is disheartening to learn of Ubuntu derivatives choosing flatpack over Snaps.

#190

I have edited my comment in the other thread to clarify that my conversation with canonical was all in a commercial context. things might be very different in non for profit projects