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.
-
@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.
-
-
@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.
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. Even with some of them using very open licensing like Apache.
But that's a red herring anyway. You said it could make internal development slower. That is what I was referencing. If no one in the community is contributing, it's not slowing you down.
-
@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.
-
@stacksofplates said in Should SodiumSuite Be Open Source:
Having it be open but having all outside work be useless to the project would just be silly and undermine the discussion.
I've never seen this in practice. I mean every once in a while you'll see someone open an issue and say they wish your tool/product did X and you have to say "no sorry that's not the direction we want to go". But is that seriously slowing you down? If so you need to fix many other things.
-
Here's a real world example. I did a pr with this tool. All of the testing and validation was done automatically. Here's their test cases. https://github.com/purpleidea/mgmt/tree/master/test They even test commit messages to ensure they meet standards. If you aren't already enforcing these standards, I'd say you're already behind the game.
edit: They even still have the tests from my pr 6 months ago. https://travis-ci.org/purpleidea/mgmt/builds/556074878?utm_source=github_status&utm_medium=notification
-
@stacksofplates said in Should SodiumSuite Be Open Source:
@stacksofplates said in Should SodiumSuite Be Open Source:
Having it be open but having all outside work be useless to the project would just be silly and undermine the discussion.
I've never seen this in practice. I mean every once in a while you'll see someone open an issue and say they wish your tool/product did X and you have to say "no sorry that's not the direction we want to go". But is that seriously slowing you down? If so you need to fix many other things.
If it is purely people adding their own features, that can be great and would rarely cause issues. 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.
