4 ms·

>These sections should make companies nervous, because it means they need to assume full responsibility when relying on software in their multi-million-dollar b

>These sections should make companies nervous, because it means they need to assume full responsibility when relying on software in their multi-million-dollar business that was probably developed by a tired young parent or college student who didn't get enough sleep. But those are exactly the same people who would be developing their software if they brought the work in-house. Off topic, but doesn't the success of open source software torpedo the claims by many companies that you need on-site collaboration for this kind of work? Even here on HN you see many comments going on about magical conversations in hallways, yada yada. But in reality, many of the software projects that millions use every day were built and are currently maintained by teams who have not only never met, but probably don't even know what the other team members look like.

mtlmtlmtlmtl 3y ago
Having worked with both open source and proprietary 3rd party software, in many ways, open source is actually maybe the safest pick. Or rather, proprietary stuff probably has the worst failure mode, where you end up being dependent on a legacy product with no support and no code(and this is pretty much guaranteed to happen at some point!). And even if there is support, it could take weeks to get a support request elevated to a bug report, assigned to a dev, reviewed, tested, yadda yadda yadda. Especially if you're a smaller customer. I won't comment on overall risk of third party open source vs proprietary. But it is obviously true that open source has an advantage in that there's no problem that could arise that can't in principle be solved in-house.
bee_rider 3y ago
Re: the on-site collaboration, I think it is a different scenario? A company wants to some a particular problem, wants their solution to be the winning one, and wants to be able to stand behind the specific promises that they make regarding it. When picking an open source library from the internet, you can immediately apply a strong filter: select codes which already have an active community and ongoing development, they already do something like what they say on the tin. You only see projects that have won a couple times. Open source communities also draw in people who have the specific problem that their project solves. The need to have meetings to get everyone aligned on what the actual objective is is reduced, they showed up because they have the problem. The corporate project is, at best, trying to solve an internal company problem (so they can at least have meetings with the interested parties and maybe even dogfood a bit). Or, it might have some totally imaginary customers that sales and management think exist out there somewhere, so let’s get together and brainstorm about what they might need.

mtlmtlmtlmtl 3y ago

Having worked with both open source and proprietary 3rd party software, in many ways, open source is actually maybe the safest pick. Or rather, proprietary stuff probably has the worst failure mode, where you end up being dependent on a legacy product with no support and no code(and this is pretty much guaranteed to happen at some point!). And even if there is support, it could take weeks to get a support request elevated to a bug report, assigned to a dev, reviewed, tested, yadda yadda yadda. Especially if you're a smaller customer. I won't comment on overall risk of third party open source vs proprietary. But it is obviously true that open source has an advantage in that there's no problem that could arise that can't in principle be solved in-house.

bee_rider 3y ago

Re: the on-site collaboration, I think it is a different scenario? A company wants to some a particular problem, wants their solution to be the winning one, and wants to be able to stand behind the specific promises that they make regarding it. When picking an open source library from the internet, you can immediately apply a strong filter: select codes which already have an active community and ongoing development, they already do something like what they say on the tin. You only see projects that have won a couple times. Open source communities also draw in people who have the specific problem that their project solves. The need to have meetings to get everyone aligned on what the actual objective is is reduced, they showed up because they have the problem. The corporate project is, at best, trying to solve an internal company problem (so they can at least have meetings with the interested parties and maybe even dogfood a bit). Or, it might have some totally imaginary customers that sales and management think exist out there somewhere, so let’s get together and brainstorm about what they might need.