Should SodiumSuite Be Open Source
-
@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.
-
@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.
-
@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.
-
@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.
