Should SodiumSuite Be Open Source
-
@Dashrender said in Should SodiumSuite Be Open Source:
@IRJ said in Should SodiumSuite Be Open Source:
@Dashrender said in Should SodiumSuite Be Open Source:
@scottalanmiller said in Should SodiumSuite Be Open Source:
@stacksofplates said in Should SodiumSuite Be Open Source:
Obviously you can do what you want since it's your software.
It's our service, that's the key. If we were just making software, this would truly be a totally different discussion. If we were going to release this for others to operate, I'd be the first to champion open sourcing it. But as a pure service with no intent to release as software, it's not open source that you are actually trying to talk me into (I know you are just making points, but you know what I mean) but rather to release the service components as software at all. Once we are doing that, sure, open source makes the most sense.
So let's reframe the discussion. The actual discussion becomes "should SS be released as software" rather than as a service? It is that that causes all of the concern. Making it available for others to operate when the value is less the software under the hood but the operational system that we are primarily looking to build. That we are making software is kind of an aside, it's all in the pursuit of building a service offering. Few people today talk about AWS software, they talk only about the service. But AWS has software under the hood putting it all together. But we overlook that as it is a pure service. It's not open or closed, because it isn't software at all in that context, just a service.
That's where we are. The arguments that you are giving are why software should be open, but the issues we are concerned about are not that but that the software exist in the wild at all. So my responses are almost purely about that aspect of it. That's why my adherence to believing in open source for software feels at odds with my position here - because it's releasing as software that I'm stuck thinking about.
Scott's company in this case is not a software vendor - they are a service provider, just like Starbucks is a place to buy premade coffee/snacks, even though the company makes it's own espresso machines, they don't sell them, Starbucks only sells the coffee made by those machines.
Makes sense to me.
Most opensource projects are not software vendors. They dont sell the software. Sure you can sell support if you would like, but you dont even have to do that. You could just sell it as SaaS and be done with it.
Your company in that case would only sell a service not software or support. So you could stagger releases and have better features on your SaaS version and have a legitimate Opensource project without selling software or even software support.
Sure you can do that, but that's super risky. As Scott said - some VC could just come along, take your code and stand up their own SaaS and undercut you all day long and never be under the costs of the original development. Of course, the new player could always just be a version or 2 behind because they solely rely on you (Scott's company in this case) releasing new versions... or they could hire inhouse and start contributing or fork, etc. But all of those things take a ton of revenue away from the original SaaS creator.
Scott asked if there is an example of a SaaS out there is the solely based on OS? He couldn't come up with any examples - can you?
Sure, MSPs host their own wazuh instances and then come to Wazuh team for support, but hey some money is better than no money.
Then you have plenty of customers who soley use the SaaS from Wazuh themselves.
-
@IRJ said in Should SodiumSuite Be Open Source:
@Dashrender said in Should SodiumSuite Be Open Source:
@IRJ said in Should SodiumSuite Be Open Source:
@Dashrender said in Should SodiumSuite Be Open Source:
@scottalanmiller said in Should SodiumSuite Be Open Source:
@stacksofplates said in Should SodiumSuite Be Open Source:
Obviously you can do what you want since it's your software.
It's our service, that's the key. If we were just making software, this would truly be a totally different discussion. If we were going to release this for others to operate, I'd be the first to champion open sourcing it. But as a pure service with no intent to release as software, it's not open source that you are actually trying to talk me into (I know you are just making points, but you know what I mean) but rather to release the service components as software at all. Once we are doing that, sure, open source makes the most sense.
So let's reframe the discussion. The actual discussion becomes "should SS be released as software" rather than as a service? It is that that causes all of the concern. Making it available for others to operate when the value is less the software under the hood but the operational system that we are primarily looking to build. That we are making software is kind of an aside, it's all in the pursuit of building a service offering. Few people today talk about AWS software, they talk only about the service. But AWS has software under the hood putting it all together. But we overlook that as it is a pure service. It's not open or closed, because it isn't software at all in that context, just a service.
That's where we are. The arguments that you are giving are why software should be open, but the issues we are concerned about are not that but that the software exist in the wild at all. So my responses are almost purely about that aspect of it. That's why my adherence to believing in open source for software feels at odds with my position here - because it's releasing as software that I'm stuck thinking about.
Scott's company in this case is not a software vendor - they are a service provider, just like Starbucks is a place to buy premade coffee/snacks, even though the company makes it's own espresso machines, they don't sell them, Starbucks only sells the coffee made by those machines.
Makes sense to me.
Most opensource projects are not software vendors. They dont sell the software. Sure you can sell support if you would like, but you dont even have to do that. You could just sell it as SaaS and be done with it.
Your company in that case would only sell a service not software or support. So you could stagger releases and have better features on your SaaS version and have a legitimate Opensource project without selling software or even software support.
Sure you can do that, but that's super risky. As Scott said - some VC could just come along, take your code and stand up their own SaaS and undercut you all day long and never be under the costs of the original development. Of course, the new player could always just be a version or 2 behind because they solely rely on you (Scott's company in this case) releasing new versions... or they could hire inhouse and start contributing or fork, etc. But all of those things take a ton of revenue away from the original SaaS creator.
Scott asked if there is an example of a SaaS out there is the solely based on OS? He couldn't come up with any examples - can you?
Sure, MSPs host their own wazuh instances and then come to Wazuh team for support, but hey some money is better than no money.
Then you have plenty of customers who soley use the SaaS from Wazuh themselves.
Still a totally different model. That's a software company that also sells a service for those that want it. They are not a service company that doesn't offer software. In this model, this works pretty consistently. It's unlike what we are doing and these examples seem to show my point - that examples don't really exist for a service company, only software ones. In this model, where the software is the "product", offering it with operations by a third party makes little sense. Wazuh is also private and they don't release funding information, but it is likely that they are VC funded or have an angel investor.
There is no business opportunity in operating Wazuh as a third party on any scale. So this example doesn't apply. We have to find examples like Amazon AWS where there is no software market, only services.
SS is an operational product, not a software product. The primary value and the point of the product, is in the operations. It's 100% services, it's not a software product.
-
@scottalanmiller said in Should SodiumSuite Be Open Source:
It's 100% services, it's not a software product.
So you might it Services as a Service then.
-
@Dashrender said in Should SodiumSuite Be Open Source:
@IRJ said in Should SodiumSuite Be Open Source:
@Dashrender said in Should SodiumSuite Be Open Source:
@scottalanmiller said in Should SodiumSuite Be Open Source:
@stacksofplates said in Should SodiumSuite Be Open Source:
Obviously you can do what you want since it's your software.
It's our service, that's the key. If we were just making software, this would truly be a totally different discussion. If we were going to release this for others to operate, I'd be the first to champion open sourcing it. But as a pure service with no intent to release as software, it's not open source that you are actually trying to talk me into (I know you are just making points, but you know what I mean) but rather to release the service components as software at all. Once we are doing that, sure, open source makes the most sense.
So let's reframe the discussion. The actual discussion becomes "should SS be released as software" rather than as a service? It is that that causes all of the concern. Making it available for others to operate when the value is less the software under the hood but the operational system that we are primarily looking to build. That we are making software is kind of an aside, it's all in the pursuit of building a service offering. Few people today talk about AWS software, they talk only about the service. But AWS has software under the hood putting it all together. But we overlook that as it is a pure service. It's not open or closed, because it isn't software at all in that context, just a service.
That's where we are. The arguments that you are giving are why software should be open, but the issues we are concerned about are not that but that the software exist in the wild at all. So my responses are almost purely about that aspect of it. That's why my adherence to believing in open source for software feels at odds with my position here - because it's releasing as software that I'm stuck thinking about.
Scott's company in this case is not a software vendor - they are a service provider, just like Starbucks is a place to buy premade coffee/snacks, even though the company makes it's own espresso machines, they don't sell them, Starbucks only sells the coffee made by those machines.
Makes sense to me.
Most opensource projects are not software vendors. They dont sell the software. Sure you can sell support if you would like, but you dont even have to do that. You could just sell it as SaaS and be done with it.
Your company in that case would only sell a service not software or support. So you could stagger releases and have better features on your SaaS version and have a legitimate Opensource project without selling software or even software support.
Sure you can do that, but that's super risky. As Scott said - some VC could just come along, take your code and stand up their own SaaS and undercut you all day long and never be under the costs of the original development. Of course, the new player could always just be a version or 2 behind because they solely rely on you (Scott's company in this case) releasing new versions... or they could hire inhouse and start contributing or fork, etc. But all of those things take a ton of revenue away from the original SaaS creator.
Scott asked if there is an example of a SaaS out there is the solely based on OS? He couldn't come up with any examples - can you?
And amazingly people in the community (myself included) have said this is the benefit of open source software. Anyone can take up the project when it becomes dead.
Also, licensing limits this. If you're AGPL, they can't just "take your code and stand up their own". They would be required to give their contributions upstream. That's a giant benefit people are ignoring here. You don't have to accept them, but they have to be made available to you.
-
@Dashrender said in Should SodiumSuite Be Open Source:
@IRJ said in Should SodiumSuite Be Open Source:
@Dashrender said in Should SodiumSuite Be Open Source:
@scottalanmiller said in Should SodiumSuite Be Open Source:
@stacksofplates said in Should SodiumSuite Be Open Source:
Obviously you can do what you want since it's your software.
It's our service, that's the key. If we were just making software, this would truly be a totally different discussion. If we were going to release this for others to operate, I'd be the first to champion open sourcing it. But as a pure service with no intent to release as software, it's not open source that you are actually trying to talk me into (I know you are just making points, but you know what I mean) but rather to release the service components as software at all. Once we are doing that, sure, open source makes the most sense.
So let's reframe the discussion. The actual discussion becomes "should SS be released as software" rather than as a service? It is that that causes all of the concern. Making it available for others to operate when the value is less the software under the hood but the operational system that we are primarily looking to build. That we are making software is kind of an aside, it's all in the pursuit of building a service offering. Few people today talk about AWS software, they talk only about the service. But AWS has software under the hood putting it all together. But we overlook that as it is a pure service. It's not open or closed, because it isn't software at all in that context, just a service.
That's where we are. The arguments that you are giving are why software should be open, but the issues we are concerned about are not that but that the software exist in the wild at all. So my responses are almost purely about that aspect of it. That's why my adherence to believing in open source for software feels at odds with my position here - because it's releasing as software that I'm stuck thinking about.
Scott's company in this case is not a software vendor - they are a service provider, just like Starbucks is a place to buy premade coffee/snacks, even though the company makes it's own espresso machines, they don't sell them, Starbucks only sells the coffee made by those machines.
Makes sense to me.
Most opensource projects are not software vendors. They dont sell the software. Sure you can sell support if you would like, but you dont even have to do that. You could just sell it as SaaS and be done with it.
Your company in that case would only sell a service not software or support. So you could stagger releases and have better features on your SaaS version and have a legitimate Opensource project without selling software or even software support.
Sure you can do that, but that's super risky. As Scott said - some VC could just come along, take your code and stand up their own SaaS and undercut you all day long and never be under the costs of the original development. Of course, the new player could always just be a version or 2 behind because they solely rely on you (Scott's company in this case) releasing new versions... or they could hire inhouse and start contributing or fork, etc. But all of those things take a ton of revenue away from the original SaaS creator.
Scott asked if there is an example of a SaaS out there is the solely based on OS? He couldn't come up with any examples - can you?
It's impossible for there to be an example. There isn't a reality where someone can give you all of their source and also only operate as a SaaS without letting you run the source. Of course you can't provide any examples. It's a self defeating statement.
-
@stacksofplates said in Should SodiumSuite Be Open Source:
@Dashrender said in Should SodiumSuite Be Open Source:
@IRJ said in Should SodiumSuite Be Open Source:
@Dashrender said in Should SodiumSuite Be Open Source:
@scottalanmiller said in Should SodiumSuite Be Open Source:
@stacksofplates said in Should SodiumSuite Be Open Source:
Obviously you can do what you want since it's your software.
It's our service, that's the key. If we were just making software, this would truly be a totally different discussion. If we were going to release this for others to operate, I'd be the first to champion open sourcing it. But as a pure service with no intent to release as software, it's not open source that you are actually trying to talk me into (I know you are just making points, but you know what I mean) but rather to release the service components as software at all. Once we are doing that, sure, open source makes the most sense.
So let's reframe the discussion. The actual discussion becomes "should SS be released as software" rather than as a service? It is that that causes all of the concern. Making it available for others to operate when the value is less the software under the hood but the operational system that we are primarily looking to build. That we are making software is kind of an aside, it's all in the pursuit of building a service offering. Few people today talk about AWS software, they talk only about the service. But AWS has software under the hood putting it all together. But we overlook that as it is a pure service. It's not open or closed, because it isn't software at all in that context, just a service.
That's where we are. The arguments that you are giving are why software should be open, but the issues we are concerned about are not that but that the software exist in the wild at all. So my responses are almost purely about that aspect of it. That's why my adherence to believing in open source for software feels at odds with my position here - because it's releasing as software that I'm stuck thinking about.
Scott's company in this case is not a software vendor - they are a service provider, just like Starbucks is a place to buy premade coffee/snacks, even though the company makes it's own espresso machines, they don't sell them, Starbucks only sells the coffee made by those machines.
Makes sense to me.
Most opensource projects are not software vendors. They dont sell the software. Sure you can sell support if you would like, but you dont even have to do that. You could just sell it as SaaS and be done with it.
Your company in that case would only sell a service not software or support. So you could stagger releases and have better features on your SaaS version and have a legitimate Opensource project without selling software or even software support.
Sure you can do that, but that's super risky. As Scott said - some VC could just come along, take your code and stand up their own SaaS and undercut you all day long and never be under the costs of the original development. Of course, the new player could always just be a version or 2 behind because they solely rely on you (Scott's company in this case) releasing new versions... or they could hire inhouse and start contributing or fork, etc. But all of those things take a ton of revenue away from the original SaaS creator.
Scott asked if there is an example of a SaaS out there is the solely based on OS? He couldn't come up with any examples - can you?
It's impossible for there to be an example. There isn't a reality where someone can give you all of their source and also only operate as a SaaS without letting you run the source. Of course you can't provide any examples. It's a self defeating statement.
Given. But that's kind of the point. It's not the source that is the real discussion, it's talking about fundamentally changing what the product is... from a service to software (that anyone can run as a service if they want, of course); moving from being an operational venture to a code development venture. It's a change of everything, fundamentally.
It's not a bad idea to kick around. But the context has to be understood. It's not a little change of how licensing and visibility is done. It's changing the very core of the business model, which in turn changes the potentially to be able to even do the project as it is a business venture.
-
@scottalanmiller said in Should SodiumSuite Be Open Source:
It's not a little change of how licensing and visibility is done
I'm not trying to say a licensing change is trivial (although a lot easier going from closed to open than from one open to another). I'm saying if you pick the correct licensing, people can't just "steal" your code without A) giving you credit, and B) contributing their changes to you. That was my point to @Dashrender .
edit: apparently you can't do A) and "B)".
-
Maybe what this thread is trying to say is that an open source RMM is something that the world is looking for and people would want to use, and that potentially people would be interested in supporting from a "helping with code" perspective?
-
@stacksofplates said in Should SodiumSuite Be Open Source:
@scottalanmiller said in Should SodiumSuite Be Open Source:
It's not a little change of how licensing and visibility is done
I'm not trying to say a licensing change is trivial (although a lot easier going from closed to open than from one open to another). I'm saying if you pick the correct licensing, people can't just "steal" your code without A) giving you credit, and B) contributing their changes to you. That was my point to @Dashrender .
edit: apparently you can't do A) and "B)".
Oh absolutely, that component is pretty standardly protected and there are standard licenses just for that that hold up in court and are well known and understood.
-
@caramel said in Should SodiumSuite Be Open Source:
Maybe what this thread is trying to say is that an open source RMM is something that the world is looking for and people would want to use, and that potentially people would be interested in supporting from a "helping with code" perspective?
That, I would say, seems sensible. Especially given that Itarian, which was free but not open, but used a lot of open source components, is no longer free leaving quite a gap in the market in multiple ways. The time is ripe if someone was to create and oversee an OS RMM project. I think that traditional RMM, which is it seems a lot of perception around SS, makes way more sense to be approached in that way for exactly reasons that @stacksofplates has mentioned... the market is already full of existing closed competitors, being open is a differentiating factor, just taking the code and running your own RMM with it would be hard to make a viable business, the need for the product in the market is already established, etc.
-
@scottalanmiller said in Should SodiumSuite Be Open Source:
@IRJ said in Should SodiumSuite Be Open Source:
@Dashrender said in Should SodiumSuite Be Open Source:
@IRJ said in Should SodiumSuite Be Open Source:
@Dashrender said in Should SodiumSuite Be Open Source:
@scottalanmiller said in Should SodiumSuite Be Open Source:
@stacksofplates said in Should SodiumSuite Be Open Source:
Obviously you can do what you want since it's your software.
It's our service, that's the key. If we were just making software, this would truly be a totally different discussion. If we were going to release this for others to operate, I'd be the first to champion open sourcing it. But as a pure service with no intent to release as software, it's not open source that you are actually trying to talk me into (I know you are just making points, but you know what I mean) but rather to release the service components as software at all. Once we are doing that, sure, open source makes the most sense.
So let's reframe the discussion. The actual discussion becomes "should SS be released as software" rather than as a service? It is that that causes all of the concern. Making it available for others to operate when the value is less the software under the hood but the operational system that we are primarily looking to build. That we are making software is kind of an aside, it's all in the pursuit of building a service offering. Few people today talk about AWS software, they talk only about the service. But AWS has software under the hood putting it all together. But we overlook that as it is a pure service. It's not open or closed, because it isn't software at all in that context, just a service.
That's where we are. The arguments that you are giving are why software should be open, but the issues we are concerned about are not that but that the software exist in the wild at all. So my responses are almost purely about that aspect of it. That's why my adherence to believing in open source for software feels at odds with my position here - because it's releasing as software that I'm stuck thinking about.
Scott's company in this case is not a software vendor - they are a service provider, just like Starbucks is a place to buy premade coffee/snacks, even though the company makes it's own espresso machines, they don't sell them, Starbucks only sells the coffee made by those machines.
Makes sense to me.
Most opensource projects are not software vendors. They dont sell the software. Sure you can sell support if you would like, but you dont even have to do that. You could just sell it as SaaS and be done with it.
Your company in that case would only sell a service not software or support. So you could stagger releases and have better features on your SaaS version and have a legitimate Opensource project without selling software or even software support.
Sure you can do that, but that's super risky. As Scott said - some VC could just come along, take your code and stand up their own SaaS and undercut you all day long and never be under the costs of the original development. Of course, the new player could always just be a version or 2 behind because they solely rely on you (Scott's company in this case) releasing new versions... or they could hire inhouse and start contributing or fork, etc. But all of those things take a ton of revenue away from the original SaaS creator.
Scott asked if there is an example of a SaaS out there is the solely based on OS? He couldn't come up with any examples - can you?
Sure, MSPs host their own wazuh instances and then come to Wazuh team for support, but hey some money is better than no money.
Then you have plenty of customers who soley use the SaaS from Wazuh themselves.
Still a totally different model. That's a software company that also sells a service for those that want it. They are not a service company that doesn't offer software. In this model, this works pretty consistently. It's unlike what we are doing and these examples seem to show my point - that examples don't really exist for a service company, only software ones. In this model, where the software is the "product", offering it with operations by a third party makes little sense. Wazuh is also private and they don't release funding information, but it is likely that they are VC funded or have an angel investor.
There is no business opportunity in operating Wazuh as a third party on any scale. So this example doesn't apply. We have to find examples like Amazon AWS where there is no software market, only services.
SS is an operational product, not a software product. The primary value and the point of the product, is in the operations. It's 100% services, it's not a software product.
OK now this I don't get - why can't it be a software product? What is so complex about running SS that someone like Evil Scott couldn't just run it himself for his own company? just like Wazuh does?
-
@stacksofplates said in Should SodiumSuite Be Open Source:
@Dashrender said in Should SodiumSuite Be Open Source:
@IRJ said in Should SodiumSuite Be Open Source:
@Dashrender said in Should SodiumSuite Be Open Source:
@scottalanmiller said in Should SodiumSuite Be Open Source:
@stacksofplates said in Should SodiumSuite Be Open Source:
Obviously you can do what you want since it's your software.
It's our service, that's the key. If we were just making software, this would truly be a totally different discussion. If we were going to release this for others to operate, I'd be the first to champion open sourcing it. But as a pure service with no intent to release as software, it's not open source that you are actually trying to talk me into (I know you are just making points, but you know what I mean) but rather to release the service components as software at all. Once we are doing that, sure, open source makes the most sense.
So let's reframe the discussion. The actual discussion becomes "should SS be released as software" rather than as a service? It is that that causes all of the concern. Making it available for others to operate when the value is less the software under the hood but the operational system that we are primarily looking to build. That we are making software is kind of an aside, it's all in the pursuit of building a service offering. Few people today talk about AWS software, they talk only about the service. But AWS has software under the hood putting it all together. But we overlook that as it is a pure service. It's not open or closed, because it isn't software at all in that context, just a service.
That's where we are. The arguments that you are giving are why software should be open, but the issues we are concerned about are not that but that the software exist in the wild at all. So my responses are almost purely about that aspect of it. That's why my adherence to believing in open source for software feels at odds with my position here - because it's releasing as software that I'm stuck thinking about.
Scott's company in this case is not a software vendor - they are a service provider, just like Starbucks is a place to buy premade coffee/snacks, even though the company makes it's own espresso machines, they don't sell them, Starbucks only sells the coffee made by those machines.
Makes sense to me.
Most opensource projects are not software vendors. They dont sell the software. Sure you can sell support if you would like, but you dont even have to do that. You could just sell it as SaaS and be done with it.
Your company in that case would only sell a service not software or support. So you could stagger releases and have better features on your SaaS version and have a legitimate Opensource project without selling software or even software support.
Sure you can do that, but that's super risky. As Scott said - some VC could just come along, take your code and stand up their own SaaS and undercut you all day long and never be under the costs of the original development. Of course, the new player could always just be a version or 2 behind because they solely rely on you (Scott's company in this case) releasing new versions... or they could hire inhouse and start contributing or fork, etc. But all of those things take a ton of revenue away from the original SaaS creator.
Scott asked if there is an example of a SaaS out there is the solely based on OS? He couldn't come up with any examples - can you?
And amazingly people in the community (myself included) have said this is the benefit of open source software. Anyone can take up the project when it becomes dead.
Also, licensing limits this. If you're AGPL, they can't just "take your code and stand up their own". They would be required to give their contributions upstream. That's a giant benefit people are ignoring here. You don't have to accept them, but they have to be made available to you.
yeah - well if I expect to fail - why would I invest in the programming in the first place? My (scott's) purpose it to create a revenue stream around this product/idea - not make software that someone else can come along and pickup and make money because they can skip the opening dev part.
-
@scottalanmiller said in Should SodiumSuite Be Open Source:
@caramel said in Should SodiumSuite Be Open Source:
Maybe what this thread is trying to say is that an open source RMM is something that the world is looking for and people would want to use, and that potentially people would be interested in supporting from a "helping with code" perspective?
That, I would say, seems sensible. Especially given that Itarian, which was free but not open, but used a lot of open source components, is no longer free leaving quite a gap in the market in multiple ways. The time is ripe if someone was to create and oversee an OS RMM project. I think that traditional RMM, which is it seems a lot of perception around SS, makes way more sense to be approached in that way for exactly reasons that @stacksofplates has mentioned... the market is already full of existing closed competitors, being open is a differentiating factor, just taking the code and running your own RMM with it would be hard to make a viable business, the need for the product in the market is already established, etc.
But could you make a business around it - which I think is the whole crux of Scott's issue - He wants to make money doing this - not just for the good of the world.
-
@Dashrender said in Should SodiumSuite Be Open Source:
@stacksofplates said in Should SodiumSuite Be Open Source:
@Dashrender said in Should SodiumSuite Be Open Source:
@IRJ said in Should SodiumSuite Be Open Source:
@Dashrender said in Should SodiumSuite Be Open Source:
@scottalanmiller said in Should SodiumSuite Be Open Source:
@stacksofplates said in Should SodiumSuite Be Open Source:
Obviously you can do what you want since it's your software.
It's our service, that's the key. If we were just making software, this would truly be a totally different discussion. If we were going to release this for others to operate, I'd be the first to champion open sourcing it. But as a pure service with no intent to release as software, it's not open source that you are actually trying to talk me into (I know you are just making points, but you know what I mean) but rather to release the service components as software at all. Once we are doing that, sure, open source makes the most sense.
So let's reframe the discussion. The actual discussion becomes "should SS be released as software" rather than as a service? It is that that causes all of the concern. Making it available for others to operate when the value is less the software under the hood but the operational system that we are primarily looking to build. That we are making software is kind of an aside, it's all in the pursuit of building a service offering. Few people today talk about AWS software, they talk only about the service. But AWS has software under the hood putting it all together. But we overlook that as it is a pure service. It's not open or closed, because it isn't software at all in that context, just a service.
That's where we are. The arguments that you are giving are why software should be open, but the issues we are concerned about are not that but that the software exist in the wild at all. So my responses are almost purely about that aspect of it. That's why my adherence to believing in open source for software feels at odds with my position here - because it's releasing as software that I'm stuck thinking about.
Scott's company in this case is not a software vendor - they are a service provider, just like Starbucks is a place to buy premade coffee/snacks, even though the company makes it's own espresso machines, they don't sell them, Starbucks only sells the coffee made by those machines.
Makes sense to me.
Most opensource projects are not software vendors. They dont sell the software. Sure you can sell support if you would like, but you dont even have to do that. You could just sell it as SaaS and be done with it.
Your company in that case would only sell a service not software or support. So you could stagger releases and have better features on your SaaS version and have a legitimate Opensource project without selling software or even software support.
Sure you can do that, but that's super risky. As Scott said - some VC could just come along, take your code and stand up their own SaaS and undercut you all day long and never be under the costs of the original development. Of course, the new player could always just be a version or 2 behind because they solely rely on you (Scott's company in this case) releasing new versions... or they could hire inhouse and start contributing or fork, etc. But all of those things take a ton of revenue away from the original SaaS creator.
Scott asked if there is an example of a SaaS out there is the solely based on OS? He couldn't come up with any examples - can you?
And amazingly people in the community (myself included) have said this is the benefit of open source software. Anyone can take up the project when it becomes dead.
Also, licensing limits this. If you're AGPL, they can't just "take your code and stand up their own". They would be required to give their contributions upstream. That's a giant benefit people are ignoring here. You don't have to accept them, but they have to be made available to you.
yeah - well if I expect to fail - why would I invest in the programming in the first place? My (scott's) purpose it to create a revenue stream around this product/idea - not make software that someone else can come along and pickup and make money because they can skip the opening dev part.
You never expect it to fail but a project run by a small team like that doesnt live forever. Look at the track record of any tool like that. It either is bought out or is abandoned. And like truecrypt it could be picked back up again.
-
@stacksofplates said in Should SodiumSuite Be Open Source:
. And like truecrypt it could be picked back up again.
Software, not a service.
-
@JaredBusch said in Should SodiumSuite Be Open Source:
@stacksofplates said in Should SodiumSuite Be Open Source:
. And like truecrypt it could be picked back up again.
Software, not a service.
Plus the authors were never trying to profit off truecrypt - Scott clearly wants to make a profit from these efforts.
-
@JaredBusch said in Should SodiumSuite Be Open Source:
@stacksofplates said in Should SodiumSuite Be Open Source:
. And like truecrypt it could be picked back up again.
Software, not a service.
We already covered that. It can't be an open source service without it also being software.
But that doesn't change the point. If it dies and people rely on it, it can be picked back up again.
-
@Dashrender said in Should SodiumSuite Be Open Source:
@JaredBusch said in Should SodiumSuite Be Open Source:
@stacksofplates said in Should SodiumSuite Be Open Source:
. And like truecrypt it could be picked back up again.
Software, not a service.
Plus the authors were never trying to profit off truecrypt - Scott clearly wants to make a profit from these efforts.
That's not the point. Even if it did make money and they decided to cancel it or it died for another reason it could be picked back up again. Making money is not a factor there.
