Should SodiumSuite Be Open Source
-
@stacksofplates said in Should SodiumSuite Be Open Source:
Yeah I mean it's almost like any of the tools like Ansible, Salt, Kubernetes, etc could have been stolen by a large vendor but amazingly haven't.
Ansible is under IBM though, right? And I think the others have VC backing. But they also are software products, not operational products. So while they have similarities, it's a different arena. Salt makes its money selling support for on premises deployments, not in hosting Salt infrastructures.
-
@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.
-
@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".
-
@scottalanmiller said in Should SodiumSuite Be Open Source:
@stacksofplates said in Should SodiumSuite Be Open Source:
@scottalanmiller said in Should SodiumSuite Be Open Source:
@Obsolesce said in Should SodiumSuite Be Open Source:
I don't see why open source has to work any differently than internally when using standard agile practices for example. Lots of great projects are open source and have been from the ground up.
Because to have any value as open source there has to be communications and documentations for a wider audience. Having it be open but having all outside work be useless to the project would just be silly and undermine the discussion. To make that outside assistance useful, there has to be a ton of communication, documentation, roadmap exposure, etc.
You need the documentation you would need internally. There isn't any extra documentation you need. You need your standards defined and that's it.
No, if you want people working on useful projects, you need a lot that you would not normally publish and not necessary have written in any complex or formal way. Taking tiny lean teams and prepping their work for wide spread anonymous or semi-anonymous assistance with coordination on work isn't trivial.
I don't believe that. I work in a small team of 10. We have a ton of documentation, so much to the point where we have pipelines to build the documentation and we don't have public software. If you don't have all of the documentation set up for team members and new employees then you're failing anyway. You still need guidelines for merge requests (pull requests), syntax, linting, testing, code coverage, etc.
-
@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.
