Should SodiumSuite Be Open Source
-
@IRJ said in Should SodiumSuite Be Open Source:
You probably wont catch a marlin on your first cast, but eventually you will find someone who starts using SS as a daily driver and really starts contributing
Yeah, that's great when it happens. It's boot strapping right now that's the challenge (core team being tied up.)
-
@scottalanmiller said in Should SodiumSuite Be Open Source:
@IRJ said in Should SodiumSuite Be Open Source:
Alot of the ML community was interested in helping troubleshoot bugs with SS. So why wouldnt they be interested in making minor contributions.
Presumably because willingness to contribute as IT professionals in an IT community wouldn't imply willingness to code. One is the expected skill set of a community of target users. The other is not unexpected, but not directly correlated skill that isn't what the community is about.
I am not a dev myself, at all. I am able to improve code sometimes on open source projects. Not in a major way, but every little bit helps.
-
@scottalanmiller said in Should SodiumSuite Be Open Source:
@IRJ said in Should SodiumSuite Be Open Source:
You probably wont catch a marlin on your first cast, but eventually you will find someone who starts using SS as a daily driver and really starts contributing
Yeah, that's great when it happens. It's boot strapping right now that's the challenge (core team being tied up.)
Hmm maybe you should hire a contractor with both salt and development experience....
-
@scottalanmiller said in Should SodiumSuite Be Open Source:
@IRJ said in Should SodiumSuite Be Open Source:
@Obsolesce said in Should SodiumSuite Be Open Source:
@scottalanmiller said in Should SodiumSuite Be Open Source:
It's been kicked around but adds a ton of complication to any monetization strategy.
You can't monetize something that doesn't exist!
That is true as well. Open Source will dramatically reduce your development costs as you have interested parties actually contributing to project
Open source will potentially do that, it could also make it higher. It's not as clear cut as that. The first struggle would be attracting open source developers interesting in contributing who produce more than they cost in additional communications and direction needed.
If there were an existing body of open source people clamouring to do this who wanted to get involved, we'd be having a very different discussion. But the assumption is that the interest, at least up front, is extremely small and would undermine the existing interest without generating anything new.
We don't even know which language... or at least I don't.
-
@IRJ said in Should SodiumSuite Be Open Source:
Not in a major way, but every little bit helps.
Every little bit helps to get the code done, yes.
But it is also an increase in cost to the company doing the actual core work.
That is the point that @scottalanmiller has stated o many times in this thread that you all seem to have no grasp of.
-
@JaredBusch said in Should SodiumSuite Be Open Source:
the actual core work.
...which is not being done because there's nobody available to do it.
-
@IRJ said in Should SodiumSuite Be Open Source:
I am not a dev myself, at all. I am able to improve code sometimes on open source projects.
Having been a developer, professionally, I can assert with confidence that this kind of "help" is the most expensive.
Now, on full open source projects with little to no business backing, this is all hidden as even the core dev time is "donated" to the project also.
But when you are a business actually attempting to get software written, the time to review submissions and clean them up to standards for your code will likely outweigh any benefit.
-
@Obsolesce said in Should SodiumSuite Be Open Source:
@JaredBusch said in Should SodiumSuite Be Open Source:
the actual core work.
...which is not being done because there's nobody available to do it.
And outside of the people with the core idea and skills suddenly becoming free to work on it, it will never move forward. This is certainly true.
But paying people takes real money you know.
-
@JaredBusch said in Should SodiumSuite Be Open Source:
@IRJ said in Should SodiumSuite Be Open Source:
Not in a major way, but every little bit helps.
Every little bit helps to get the code done, yes.
But it is also an increase in cost to the company doing the actual core work.
That is the point that @scottalanmiller has stated o many times in this thread that you all seem to have no grasp of.
Of course getting amateur help makes code reviews much more difficult, but you either have hundreds of thousands of dollars to put into the project to get somewhere or you dont. I am assuming that $500k investment probably wont happen here.
So what are the choices?
-
Make it opensource. Get increased visibility and have some good help and bad help. At the end of the day, you dont have to implement any commits, however. Monetize using a SaaS model after a year or so of a community edition.
-
Let it sit and wait until money comes, so you can monetize it better.
-
Keep working on it bits and pieces at a time closed source with no testers. If it takes 5 years, it takes 5 years
-
-
@scottalanmiller said in Looking for free RMM kind, or at least with H/W and S/W inventory software with agent.:
The biggest deal for us with MC are these two features...
- No license limits. All staff get unlimited capacity.
- Speed. It dramatically cuts the time to use the product. Everything from login, to finding the machine, to accessing it are fractionally as cumbersome as anything else.
It seems like those would be biggest reason for your customers to use SS in it's infancy as well.
You have done alot of contribution to MC and have been part of the process of making it usable. You probably wouldn't have chosen MC if it were closed sourced because you know that licensing would certainly change once it becomes more mainstream.
I think that is sound reasoning for getting involved in a project in it's early stages. I would assume the devs long term plan is associated with selling a SaaS version of it, but still keeping open source for those who want to run themselves.
-
@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?
-
@JaredBusch said in Should SodiumSuite Be Open Source:
review submissions and clean them up to standards for your code will likely outweigh any benefit.
You shouldn't be cleaning them up to your standards. That should be on whoever submitted the pull request. You give them the standards in your README and have the testing to ensure the standards are met. If you don't have that in place it means you don't really have standards.
-
@IRJ said in Should SodiumSuite Be Open Source:
@JaredBusch said in Should SodiumSuite Be Open Source:
@IRJ said in Should SodiumSuite Be Open Source:
Not in a major way, but every little bit helps.
Every little bit helps to get the code done, yes.
But it is also an increase in cost to the company doing the actual core work.
That is the point that @scottalanmiller has stated o many times in this thread that you all seem to have no grasp of.
Of course getting amateur help makes code reviews much more difficult, but you either have hundreds of thousands of dollars to put into the project to get somewhere or you dont. I am assuming that $500k investment probably wont happen here.
So what are the choices?
-
Make it opensource. Get increased visibility and have some good help and bad help. At the end of the day, you dont have to implement any commits, however. Monetize using a SaaS model after a year or so of a community edition.
-
Let it sit and wait until money comes, so you can monetize it better.
-
Keep working on it bits and pieces at a time closed source with no testers. If it takes 5 years, it takes 5 years
Waterfall all the way!
-
-
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.
You can't say the same for closed source projects nobody is working on.
-
@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.
-
@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.
-
@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.
...there has to be communications and documentations for a wider audience. ... To make that outside assistance useful, there has to be a ton of communication, documentation, roadmap exposure, etc.
...and?
-
@IRJ said in Should SodiumSuite Be Open Source:
I think that is sound reasoning for getting involved in a project in it's early stages. I would assume the devs long term plan is associated with selling a SaaS version of it, but still keeping open source for those who want to run themselves.
MC is funded my a Fortune 500 who get massive amounts of marketing, PR, etc. out of it and already were building it to interface with their own, unique product. MC makes money by selling vPRO enabled Intel chipsets. So their motivations for open sourcing it, and for funding it, are wholly different. As a product, it's value is in its use, not in making money directly. It's a loss leader for the real products. SS is the product, not the loss leader.
-
@Obsolesce 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.
...there has to be communications and documentations for a wider audience. ... To make that outside assistance useful, there has to be a ton of communication, documentation, roadmap exposure, etc.
...and?
And that costs time and money and if it doesn't have a clear return, is a problem.
-
@IRJ said in Should SodiumSuite Be Open Source:
-
Make it opensource. Get increased visibility and have some good help and bad help. At the end of the day, you dont have to implement any commits, however. Monetize using a SaaS model after a year or so of a community edition.
-
Let it sit and wait until money comes, so you can monetize it better.
-
Keep working on it bits and pieces at a time closed source with no testers. If it takes 5 years, it takes 5 years
- I'm talking to people about it, but right now skepticism is the predominant feeling.
- This is part of the plan, other projects being worked on like crazy in order to fund it. It's an active thing being worked on every day.
- This is where it has been and while it isn't ideal, not sure that we can get around the limitations.
There is a little more to consider, just for visibility. This project could pretty easily get VC funding. It doesn't require so much as to make it difficult to fund. But doing so would risk control and profits. That's not to say it's about greed, but with a VC you generally are going to need 300% or more, often 10,000% or more (real numbers) of revenue to cover operational costs. If we run it purely as an in house funded project we hit full viable financial success as soon as it makes enough to cover the cost of the team's salaries and necessary equipment. That's it. If we could cover that today in revenue, this is all that we would work on. If we bring on a VC, we can do that sooner, but the company has to make millions to pay off the VC and likely becomes a company and project that we don't want in doing so.
Nothing against VCs, they are great for funding ideas that you want to execute and move on from. They are bad for building a passion based project that we don't want being sold off to whatever high bidder.
Not that anyone is talking about VC funding, but the VC vs. PE funding approaches are part of what makes the higher level code discussions happen like they do.
-
