Should SodiumSuite Be Open Source
-
@scottalanmiller said in Should SodiumSuite Be Open Source:
@stacksofplates said in Should SodiumSuite Be Open Source:
If no one in the community is contributing, it's not slowing you down.
But it is. You are discounting the motivational and investment factors. It's easily the difference between it being a top focus or canceled project. That's a bit amount of "slowing down" at risk.
Uh what? Are you saying that if it's open sourced people will lose motivation? Is that the level of argument we are down to?
-
Obviously you can do what you want since it's your software. No one is trying to make you do one thing or another. If you want it to be closed source, fine. But don't make weird excuses for why you can't do it that are contrary to things you've said before and to real world scenarios. This thread probably wouldn't even exist if you just said "because I want it to be closed source, end of story".
-
@stacksofplates said in Should SodiumSuite Be Open Source:
@scottalanmiller said in Should SodiumSuite Be Open Source:
Ansible is under IBM though, right?
And that has what to do with anything? They weren't copied by IBM and run out of market. The exact opposite happened. They sold to make money.
Right, but the factors are all different. Huge funding, sold out to a buyer, was a loss leader (at least potentially) for other products (RHEL), was software rather than a service. Every factor that makes it make sense there, is the opposite. Not that that rules things out, but the examples of success are all "opposite" scenarios. Show me the Amazon or Azure that went OS and beat those out. Obviously I picked an arena where that didn't happen, but find one that did. What OS SaaS application, without corporate or VC funding, where the entire thing is the service, and doesn't take VC funding and doesn't want to sell out, worked out? There must be an example, but I can't think of one. All of the success is in one or many of those factors.
-
@stacksofplates said in Should SodiumSuite Be Open Source:
@scottalanmiller said in Should SodiumSuite Be Open Source:
But that means doing code reviews for things that might not be useful to anyone else, needing to support or remove those pieces, and not adding to the core that is the goal. Not terrible, maybe useful, but easily a time sink.
I'm not sure what amount of time you think you would be spending doing code reviews on something you're not going to implement. If someone opens a PR and you don't want that feature, you won't be doing a code review. You would just say "thanks we don't want to go that direction".
Oh absolutely, if they are doing it for something like that. But then that doesn't help with the project either
-
@stacksofplates said in Should SodiumSuite Be Open Source:
@scottalanmiller said in Should SodiumSuite Be Open Source:
@stacksofplates said in Should SodiumSuite Be Open Source:
If no one in the community is contributing, it's not slowing you down.
But it is. You are discounting the motivational and investment factors. It's easily the difference between it being a top focus or canceled project. That's a bit amount of "slowing down" at risk.
Uh what? Are you saying that if it's open sourced people will lose motivation? Is that the level of argument we are down to?
I'm saying that yes, the said they'd not be able to justify working on the project because it would undermine the purpose of the investment. I'm not saying they would lose motivation, I'm saying bringing it up is already demotivating and that it's flat out a show stopper. So it would require producing whole new resources if we went OS, at least at the highest level (doing it all.) We are in a meeting now discussing it, but it's a hard sell as to the benefits being questionable (potentially zero benefit) but large risk (any investor with pockets could bypass us and operate the product.) High known risk for extremely little to no reward. Is there some chance of large reward, I suppose some chance. But any reasonable chance? It feels like that's a hard "no": there is no clear benefit to trying to attract additional developers given the need to control and coordinate the core.
But we are talking. And I have some ideas that might work out. But it's tough, because even I don't see where there is any likelihood that someone will actually step up and contribute in a way that'll end up overly beneficial to a SaaS product of this nature.
-
@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.
-
@scottalanmiller said in Should SodiumSuite Be Open Source:
@stacksofplates said in Should SodiumSuite Be Open Source:
@scottalanmiller said in Should SodiumSuite Be Open Source:
It still carries risk that opening it could garner no additional assistance while making internal development slower, though
How is that possible? What is the scenario where your development would change based on no one else doing anything?
Because making any service available as software hands competitors everything, for free, to compete operationally. Those not developing the software used in the service have the staggering advantage of not needing to invest to make it work. When you are an established vendor like IBM, you can invest in marketing, operations, customer acquisition with the advantage of making the tech. As a startup, you don't have this. So anyone with some spare time can take the software and crush the project completely.
So motivating internally when you've put the project at risk of survival is a huge factor.
This is the biggest reason to not have it be open source now that I can see.
-
@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.
-
@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.
-
@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?
-
@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.
