6 ms·

> Namely that it would be expensive to open source it with little benefit in return. Would you describe exactly what will be expensive in releasing the source

> Namely that it would be expensive to open source it with little benefit in return. Would you describe exactly what will be expensive in releasing the source code to software that was developed in house? Does it have lots of dependencies on proprietary software? If so, why? > Namely they want one location to find software, and one location to serve software. And this, is the killer. This is exactly what the people at Linux Mint do not want. This is why F-Droid exists on Android. Yes, free software can be distributed on the snap store or on Google Play, but ultimately these are proprietary platforms controlled by one corporate entity whose interests may not be aligned with those of the community. Users of community Linux distros demand choice in where they obtain software. > That and the whole aspects of malware/trust goes out the window. Malware has already been successfully pushed to the Snap Store. The idea of "trust" here is also antithetical to open-source and software freedom. Rather than trusting software because it has verifiable source code, we now trust software because it came from a store that removes well known malware.

kd913 6y ago
>Would you describe exactly what will be expensive in releasing the source code to software that was developed in house? Does it have lots of dependencies on proprietary software? If so, why? Im not too sure as I don't work for Canonical. However, from an external perspective having worked with bzr and launchpad, I wouldn't be surprised if there is a bunch of aspects there that would make opensourcing a nightmare. Things like potentially giving some mechanism that could enable a user to sign/publish on behalf of Canonical snaps/packages for example. That kind of thing would probably need to be removed. Deep integration between CI/operational infrastructure for things like building images. I can imagine after Canonical's experience of launchpad that they probably did hardcode aspects and it isn't some modular thing you can just spin up on docker. >And this, is the killer. This is exactly what the people at Linux Mint do not want. This is why F-Droid exists on Android. Yes, free software can be distributed on the snap store or on Google Play, but ultimately these are proprietary platforms controlled by one corporate entity whose interests may not be aligned with those of the community. Users of community Linux distros demand choice in where they obtain software. Snaps I checked aren't there to replace apt. They don't prevent the install of flatpak, appimages or any alternative. Canonical has no agreement that prevents parties like Mozilla/KDE from only publishing on the snap store. >Malware has already been successfully pushed to the Snap Store. We now trust software because it came from a store that removes well known malware. There was one case of a snap bundled with a cryptominer. That was settled within 3 days and addressed to the community in a blog. Since then, it has been deliberately looked for. As someone who has published on the snap store, yes there are some checks present to ensure malicious software isn't being pushed. >The idea of "trust" here is also antithetical to open-source and software freedom. Rather than trusting software because it has verifiable source code, It is really easy for me to see exactly what is being run/executed on the snaps that I install. In fact I have built/used snaps successfully without even the snap store all together.
- commoner 6y ago
  > However, from an external perspective having worked with bzr and launchpad, I wouldn't be surprised if there is a bunch of aspects there that would make opensourcing a nightmare. If Canonical, as a Linux company, is not willing to spend the effort to open source their software, then Snap can continue to be rejected by Linux distributions. Canonical's most obvious reason for keeping the Snap server closed source is to lock its users into a proprietary and centralized system that it has full control over. This strategy is no different from Apple disallowing installations outside of the App Store on iOS, and Google disallowing alternative app stores in Google Play.
  - kd913 6y ago
    You haven't really at all explained any justifiable reason for Canonical to open source it. You still haven't argued at all the resource aspects which are I think the primary motivator here. Canonical has done this experiment precisely in the past, and we see the results of nobody operating their own launchpad instance. Nobody contributing back. That experience probably trumps all of this goodwill and opinions from the community. Canonical is more importantly getting users, publishers and numbers behind them. A discussion I remember reading was that every snap has 10x more installs than the corresponding flatpak. That and they have 1st party support from major publishers like Google, Microsoft, Amazon, Spotify, Mozilla, Jetbrains, KDE etc.... Those aspects are more important for usability for the average user.
    - commoner 6y ago
      > You haven't really at all explained any justifiable reason for Canonical to open source it. I've explained why it would be in the users' interest for Canonical to open source the Snap store: it reduces vendor lock-in and allows the users to enjoy the benefits of open source software (the ability to use, study, share, and improve the software with no restrictions). Whether open sourcing the Snap server benefits Canonical is irrelevant to the users.
      - kd913 6y ago
tyree731 6y ago
> Would you describe exactly what will be expensive in releasing the source code to software that was developed in house? Does it have lots of dependencies on proprietary software? If so, why? If all you're doing is taking an internal repository and hosting it externally, then it takes no time. But if you make sure licenses are being used correctly throughout the code, audit to make sure no internal secrets accidentally made their way into the internal repository (this happens as much in closed source as it does in open source), and you try to remove any problematic code, commit messages or references from the code, it takes time.
- kemayo 6y ago
  Isn't it a bad look for Canonical, a major open source company, to not have developed core software for their major open source product in an open source friendly manner?
  - Andrew_nenakhov 6y ago
    Why should they do everything open source? To keep happy a few bored FOSS maximalists, who have neither real interest, nor use for the code? We develop open source applications ourselves, and the amount of jerks who drop in from time to time and teach us how to do what (without contributing any code or donations, of course) is overwhelming. They don't care how you pay your bills and how much effort it takes to make things happen.
    - bananamerica 6y ago
      IDK where you work but isn’t it possible that many FOSS has significantly less resources than Canonical?
- rmc 6y ago
  they should have developed it from day 1 thinking it would be open sources, i.e. never adding any non-open source dependencies
rlpb 6y ago
> Does it have lots of dependencies on proprietary software? Not so much proprietary software (those dependencies would be owned by Canonical and therefore released in the same lot) but I understand there is considerable dependency on deployment machinery. Documentation for that machinery will need to be split out into private (contains secrets, references to customers, etc) and public (consumable by someone looking to replicate a Snap store deployment) and so on. > Rather than trusting software because it has verifiable source code, we now trust software because it came from a store that removes well known malware. The world has moved to that. I don't like it. I would prefer to install only distribution-curated software. However that doesn't help me get a bunch of software that isn't available that way. Where it is (and at the version I need), I use it. Note that this particular statement of yours applies equally to AppImage, Flatpak and everything else that isn't distribution-curated. It's not just an argument against Snaps.
- jancsika 6y ago
  > The world has moved to that. The world has also moved to casually clicking links to "install" arbitrary apps (which in turn call stacks of arbitrary libraries and frameworks the dev probably found by casually clicking links). You could give Debian and Ubuntu another decade to work on their packaging infrastructure and they still wouldn't reach parity with what we get through the web with the current browser security model.
user5994461 6y ago
I wrote a post on that, what prevents companies from open sourcing their codebase https://thehftguy.com/2020/07/07/what-prevents-companies-from-open-sourcing-their-codebase/ https://thehftguy.com/2020/07/07/what-prevents-companies-fro...

kd913 6y ago

>Would you describe exactly what will be expensive in releasing the source code to software that was developed in house? Does it have lots of dependencies on proprietary software? If so, why? Im not too sure as I don't work for Canonical. However, from an external perspective having worked with bzr and launchpad, I wouldn't be surprised if there is a bunch of aspects there that would make opensourcing a nightmare. Things like potentially giving some mechanism that could enable a user to sign/publish on behalf of Canonical snaps/packages for example. That kind of thing would probably need to be removed. Deep integration between CI/operational infrastructure for things like building images. I can imagine after Canonical's experience of launchpad that they probably did hardcode aspects and it isn't some modular thing you can just spin up on docker. >And this, is the killer. This is exactly what the people at Linux Mint do not want. This is why F-Droid exists on Android. Yes, free software can be distributed on the snap store or on Google Play, but ultimately these are proprietary platforms controlled by one corporate entity whose interests may not be aligned with those of the community. Users of community Linux distros demand choice in where they obtain software. Snaps I checked aren't there to replace apt. They don't prevent the install of flatpak, appimages or any alternative. Canonical has no agreement that prevents parties like Mozilla/KDE from only publishing on the snap store. >Malware has already been successfully pushed to the Snap Store. We now trust software because it came from a store that removes well known malware. There was one case of a snap bundled with a cryptominer. That was settled within 3 days and addressed to the community in a blog. Since then, it has been deliberately looked for. As someone who has published on the snap store, yes there are some checks present to ensure malicious software isn't being pushed. >The idea of "trust" here is also antithetical to open-source and software freedom. Rather than trusting software because it has verifiable source code, It is really easy for me to see exactly what is being run/executed on the snaps that I install. In fact I have built/used snaps successfully without even the snap store all together.

commoner 6y ago
> However, from an external perspective having worked with bzr and launchpad, I wouldn't be surprised if there is a bunch of aspects there that would make opensourcing a nightmare. If Canonical, as a Linux company, is not willing to spend the effort to open source their software, then Snap can continue to be rejected by Linux distributions. Canonical's most obvious reason for keeping the Snap server closed source is to lock its users into a proprietary and centralized system that it has full control over. This strategy is no different from Apple disallowing installations outside of the App Store on iOS, and Google disallowing alternative app stores in Google Play.
- kd913 6y ago
  You haven't really at all explained any justifiable reason for Canonical to open source it. You still haven't argued at all the resource aspects which are I think the primary motivator here. Canonical has done this experiment precisely in the past, and we see the results of nobody operating their own launchpad instance. Nobody contributing back. That experience probably trumps all of this goodwill and opinions from the community. Canonical is more importantly getting users, publishers and numbers behind them. A discussion I remember reading was that every snap has 10x more installs than the corresponding flatpak. That and they have 1st party support from major publishers like Google, Microsoft, Amazon, Spotify, Mozilla, Jetbrains, KDE etc.... Those aspects are more important for usability for the average user.
  - commoner 6y ago
    > You haven't really at all explained any justifiable reason for Canonical to open source it. I've explained why it would be in the users' interest for Canonical to open source the Snap store: it reduces vendor lock-in and allows the users to enjoy the benefits of open source software (the ability to use, study, share, and improve the software with no restrictions). Whether open sourcing the Snap server benefits Canonical is irrelevant to the users.
    - kd913 6y ago

tyree731 6y ago

> Would you describe exactly what will be expensive in releasing the source code to software that was developed in house? Does it have lots of dependencies on proprietary software? If so, why? If all you're doing is taking an internal repository and hosting it externally, then it takes no time. But if you make sure licenses are being used correctly throughout the code, audit to make sure no internal secrets accidentally made their way into the internal repository (this happens as much in closed source as it does in open source), and you try to remove any problematic code, commit messages or references from the code, it takes time.

kemayo 6y ago
Isn't it a bad look for Canonical, a major open source company, to not have developed core software for their major open source product in an open source friendly manner?
- Andrew_nenakhov 6y ago
  Why should they do everything open source? To keep happy a few bored FOSS maximalists, who have neither real interest, nor use for the code? We develop open source applications ourselves, and the amount of jerks who drop in from time to time and teach us how to do what (without contributing any code or donations, of course) is overwhelming. They don't care how you pay your bills and how much effort it takes to make things happen.
  - bananamerica 6y ago
    IDK where you work but isn’t it possible that many FOSS has significantly less resources than Canonical?
rmc 6y ago
they should have developed it from day 1 thinking it would be open sources, i.e. never adding any non-open source dependencies

rlpb 6y ago

> Does it have lots of dependencies on proprietary software? Not so much proprietary software (those dependencies would be owned by Canonical and therefore released in the same lot) but I understand there is considerable dependency on deployment machinery. Documentation for that machinery will need to be split out into private (contains secrets, references to customers, etc) and public (consumable by someone looking to replicate a Snap store deployment) and so on. > Rather than trusting software because it has verifiable source code, we now trust software because it came from a store that removes well known malware. The world has moved to that. I don't like it. I would prefer to install only distribution-curated software. However that doesn't help me get a bunch of software that isn't available that way. Where it is (and at the version I need), I use it. Note that this particular statement of yours applies equally to AppImage, Flatpak and everything else that isn't distribution-curated. It's not just an argument against Snaps.

jancsika 6y ago
> The world has moved to that. The world has also moved to casually clicking links to "install" arbitrary apps (which in turn call stacks of arbitrary libraries and frameworks the dev probably found by casually clicking links). You could give Debian and Ubuntu another decade to work on their packaging infrastructure and they still wouldn't reach parity with what we get through the web with the current browser security model.

user5994461 6y ago

I wrote a post on that, what prevents companies from open sourcing their codebase https://thehftguy.com/2020/07/07/what-prevents-companies-from-open-sourcing-their-codebase/ https://thehftguy.com/2020/07/07/what-prevents-companies-fro...