5 ms·

This should also be a wakeup call to anyone using closed source tools at all: DynamoDB, MongoDB, Elasticsearch, AWS Lambda, Azure, AWS, Azure Devops, SqlServer,

This should also be a wakeup call to anyone using closed source tools at all: DynamoDB, MongoDB, Elasticsearch, AWS Lambda, Azure, AWS, Azure Devops, SqlServer, Oracle, etc. While some of these tools are best in class, it's borrowed time until the owner decides to change the terms, stop offering it, or raise prices enough to damage your business. Closed source software tools are a liability, and the benefits often are only minor compared to the risks. I've been on several teams where entire projects with dozens of person years of effort had to be thrown out because tools stopped being supported or were made prohibitively expensive. This isn't about open source posturing. Relying on closed source software you can't easily switch off of just isn't worth the risk. (As an aside, I'm not a purist, I'll use tools like JetBrains, because I could easily switch off to open source tools if I had to without any disruption to my business) Edit, I do not suggest writing your own tools, I suggest using great open source tools: postgres, apache, Linux, mariadb, open source languages, Redis, couchdb, etc.

onethought 3y ago
But history has shown them get cheaper and more capable over time for nearly every example you gave.
- JackMorgan 3y ago
  Survivorship bias. These are the ones that haven't _yet_ gotten worse and are still currently popular. I'm listing them so people won't get blindsided when they do eventually bite their users. There isn't enough space to list the closed source software tools that didn't make it. Off the top of my head: Adobe Flash, MS Basic, SourceSafe, ActiveDesktop, FoxPro, J#, Oslo, IronRuby, and Silverlight.
  - Iulioh 3y ago
    The problem is that behind OS software there isn't a lot of incentive to develop. I mean, sute, but there is a reason why really good and complex software is usually closed.
  - lowbloodsugar 3y ago
    It rather looks like it depends on who makes the product. One thing to look at is who has established trust and (so far) maintained that trust. For example, AWS has said that their products will get cheaper over time and that they wont deprecate any. The fact that they've managed to do that for 15 years or so means they have a built a lot of trust - which is itself an investment that they would be foolish (financially damaged by) a decision to break that trust. Meanwhile, Google has firmly established that they will destroy any product at any time, and you would be insane to build a business on their products. Adobe and Microsoft make meh products that dominate industries, and you are at their whim, and look, these two companies provide all your examples. (And to be fair, SourceSafe went away because it was not reliable and any sane business paying for a VCS switched to perforce before eventually moving to git like everyone else). IBM will sell you anything as long as it's called "Watson" so who knows which Watson has been discontinued or not.
    - johnnyanmac 3y ago
      > which is itself an investment that they would be foolish (financially damaged by) a decision to break that trust. Yup, Unity also had that same trust for 15 years. Never underestimate greed.
  - onethought 3y ago
    That’s not what survivor bias is. You listed a set of services saying that open source is better. But the entire history of everything you said shows they are superior to the open source solutions and have gotten cheaper and more capable. Flash had a 10 year transition and was open sourced along the way, but was no longer supported by any of the open or closed source browsers… how does that help your point? No one. Listing a bunch of crap closed source projects doesn’t strengthen your point as there are equally a bunch of crap open source solutions. What’s the open source solution to S3 or DynamoDB anyway? These are software solutions that require a certain kind of infrastructure, you are saying all companies should also specialise in that infrastructure? Where do you stop? Self host in a data centre? Well now you rely on the data centre… self host in premise, now you are beholden to your ISP. Be your own ISP? Now you are beholden to government regulation? Be your own government… it gets absurd, but I’m just following your line of logic down the line.
tschellenbach 3y ago
While it's true that this can happen to external tools, it doesn't happen very often. Companies have a very strong incentive to ensure their products are supported long terms and work well. For in-house developed software it happens frequently that past employees leave the codebase in a state, where new team members end up rewriting it. So it's a bit weird to say you shouldn't use closed source since there is a small chance things change in a way we don't like, and then your alternative is to use in-house software, where maintenance issues in the future are pretty much guaranteed.
- JackMorgan 3y ago
  My alternative is to use battle tested open source software. I don't suggest writing a database in house. Also, I would say the opposite, it happens all the time. There's only a few closed source software tools that have been around for more than fifteen years, and countless that didn't make it.
- Draiken 3y ago
  >Companies have a very strong incentive to ensure their products are supported long terms and work well. I would say that's not quite accurate. They have only one incentive: profit. Long term supported products are one way of getting money, but it's most definitely not the only way. Many times it's not the most profitable one either. Companies don't make shitty decisions because they are scheming on how to screw customers up. They do it because when push comes to shove, only profit matters. One guy will plot a chart saying if we screw customers this way (with pretty words, of course) we can get X% more profit. Then they get promoted and this cycle repeats itself. Or a pandemic hits and suddenly your margins decrease drastically. Now screwing the customer is back on the table. Unless your company only plans to be running for a few years, those are not as rare as we may think.
- dehrmann 3y ago
  If AWS actually tried to abuse its power, it would really damage the tech industry. Tech companies would see the risk and start treating the cloud as rented machines (EC2), and stop realizing all the benefits of their provider managing a complex system on their behalf. If I were AWS, I'd willingly write into contracts that costs can go up no faster than the PPI + 5%, barring some sort of force majeure. Hardware gets cheaper, so I'd expect costs to come down, but this essentially "we're not going to screw you" clause.
fragsworth 3y ago
> DynamoDB, MongoDB, Elasticsearch, AWS Lambda, Azure, AWS, Azure Devops, SqlServer, Oracle, etc. At least with these individual tools, it's usually not your entire codebase written around that thing. For instance, you can generally switch from one database to another if they decide to overcharge you. You can even switch from one cloud service to another. In other words, they (usually) don't have you nearly as locked in. With Unity, it is a much bigger ordeal to switch to something like Godot and Unreal and most people who have already finished their games can't even really consider it as an option. This is why it was so egregious.
- JackMorgan 3y ago
  Of course you can switch databases, but in practice it is extremely expensive. That's a big reason why it is pretty rare. Why use a closed source tool and take on that risk when great open source ones exist?
  - fragsworth 3y ago
    Usually the only good reason is because you already have developed lot of experience with with it. I'm just saying it's not as bad because it's quite a bit easier to switch a database than to switch a game engine.
    - dan_mctree 3y ago
      For a lot of companies, switching databases is effectively impossible. Perhaps not quite as impossible as switching game engines, but certainly impossible enough that it would kill the business. A lot of companies use database specific functionality that's far from trivial to replicate in another database. A lot of that database specific functionality can also be legacy that no one really understands anymore. Migrating without an option to keep these poorly understood but critical systems will set you up for unexpected data loss, corruption or availability issues. And that's after spending a year on your migration. If Oracle pulls anything like Unity here, this will kill off a lot of companies
wilsonnb3 3y ago
It is a wake up call, I don't think open source is the only solution though. You just need good business practices. Work with vendors that you trust, vet your dependencies, decide how much risk you want to tolerate, pay attention to the licenses that you are using. Especially for something as critical as a game engine is to game development companies.
- tombert 3y ago
  I agree that it's not the only solution, but it's the only way to (somewhat) guarantee a lack of bullshit. There are companies like The Omni Group that I think are, generally speaking, bullshit-free. They make (in my opinion) pretty good products, I can buy them once, I get the normally-expected number of updates, and it's about as ideal a transaction you'd want. I don't mind them charging money for a good product, and I'm grateful that products like OmniFocus exist. That said, one thing that continues to bother me is that Omni could change things whenever they want. They could decide to start charging 10x the price if I use OmniFocus for anything involving business, or they could make it so that my flat-fee purchase of OmniFocus no longer works. Do I think Omni is going to do that? No, I think they're generally pretty decent people, but open source guarantees that I can always take a snapshot of the "current state" of the project, and also guarantee that there's not retroactive strings being attached to things I'm making with that software.
manquer 3y ago
> MongoDB, Elasticsearch > Redis You suggest that mongo and elastic search are not open source and redis is ? While all three have a company backing them and sell or have some restrictions (usually targeted towards cloud providers not self hosting ) i would have said all of them are open enough in their current versions not to have a vendor lock in risk
- yjftsjthsd-h 3y ago
  Redis is open core (that is, redis itself is Open Source, only extensions aren't), the others are outright not Open Source. That's a meaningful difference, depending on whether you're using the non-FOSS extensions.
  - manquer 3y ago
    What are you on about ? https://github.com/elastic/elasticsearch https://github.com/elastic/elasticsearch https://github.com/mongodb/mongo https://github.com/mongodb/mongo How are ES and mongoDB not open source ? Mongo switched from GPL v3 to SSPL in 2018 the only difference is whether you can offer mongoDB as a service , all other GPL clauses are the same , there is no difference for app developers I.e no vendor lock-in Elastic moved from Apache 2 to ESL v2 for the same reasons with same restrictions against managed offerings again no restrictions for a app developer to host modify or do they want . Redis splits between 3-BSD , SSPL and RSAL v2 and closed source for redis , Redis stack and Redis enterprise. Just cause OSI does not consider restrictions on competing with the author Open source doesn’t make elastic or mongo less open source ( redis also uses these ) certainly not for anyone not a cloud vendor
    - yjftsjthsd-h 3y ago
      > Just cause OSI does not consider restrictions on competing with the author Open source doesn’t make elastic or mongo less open source ( redis also uses these ) certainly not for anyone not a cloud vendor Okay, sure, if we allow people to redefine words whenever they feel like it they can be open source. Which is to say, no, that's not what those words mean. It can be https://en.wikipedia.org/wiki/Source-available_software https://en.wikipedia.org/wiki/Source-available_software but not FOSS.
bastardoperator 3y ago
That's great in theory, but most people don't have the funds for a rack, let alone a cage, or people to stack and maintain it all. The hardware alone to run a proper DB cluster is going to be prohibitive for most startups.
fendy3002 3y ago
While I support using the open source counterparts, most of the time the closed source tools price change doesn't happen retroactively. It's usually go together with new version or new contacts. Unity pricing though, happens retroactively in a sense that older, released games will be tracked the install numbers too. As if when SQL Server having the price changes to gb-based pricing happens too to 2005 version and forward. I can assure that even government will decline that kind of retroactive change.

onethought 3y ago

But history has shown them get cheaper and more capable over time for nearly every example you gave.

JackMorgan 3y ago
Survivorship bias. These are the ones that haven't _yet_ gotten worse and are still currently popular. I'm listing them so people won't get blindsided when they do eventually bite their users. There isn't enough space to list the closed source software tools that didn't make it. Off the top of my head: Adobe Flash, MS Basic, SourceSafe, ActiveDesktop, FoxPro, J#, Oslo, IronRuby, and Silverlight.
- Iulioh 3y ago
  The problem is that behind OS software there isn't a lot of incentive to develop. I mean, sute, but there is a reason why really good and complex software is usually closed.
- lowbloodsugar 3y ago
  It rather looks like it depends on who makes the product. One thing to look at is who has established trust and (so far) maintained that trust. For example, AWS has said that their products will get cheaper over time and that they wont deprecate any. The fact that they've managed to do that for 15 years or so means they have a built a lot of trust - which is itself an investment that they would be foolish (financially damaged by) a decision to break that trust. Meanwhile, Google has firmly established that they will destroy any product at any time, and you would be insane to build a business on their products. Adobe and Microsoft make meh products that dominate industries, and you are at their whim, and look, these two companies provide all your examples. (And to be fair, SourceSafe went away because it was not reliable and any sane business paying for a VCS switched to perforce before eventually moving to git like everyone else). IBM will sell you anything as long as it's called "Watson" so who knows which Watson has been discontinued or not.
  - johnnyanmac 3y ago
    > which is itself an investment that they would be foolish (financially damaged by) a decision to break that trust. Yup, Unity also had that same trust for 15 years. Never underestimate greed.
- onethought 3y ago
  That’s not what survivor bias is. You listed a set of services saying that open source is better. But the entire history of everything you said shows they are superior to the open source solutions and have gotten cheaper and more capable. Flash had a 10 year transition and was open sourced along the way, but was no longer supported by any of the open or closed source browsers… how does that help your point? No one. Listing a bunch of crap closed source projects doesn’t strengthen your point as there are equally a bunch of crap open source solutions. What’s the open source solution to S3 or DynamoDB anyway? These are software solutions that require a certain kind of infrastructure, you are saying all companies should also specialise in that infrastructure? Where do you stop? Self host in a data centre? Well now you rely on the data centre… self host in premise, now you are beholden to your ISP. Be your own ISP? Now you are beholden to government regulation? Be your own government… it gets absurd, but I’m just following your line of logic down the line.

tschellenbach 3y ago

While it's true that this can happen to external tools, it doesn't happen very often. Companies have a very strong incentive to ensure their products are supported long terms and work well. For in-house developed software it happens frequently that past employees leave the codebase in a state, where new team members end up rewriting it. So it's a bit weird to say you shouldn't use closed source since there is a small chance things change in a way we don't like, and then your alternative is to use in-house software, where maintenance issues in the future are pretty much guaranteed.

JackMorgan 3y ago
My alternative is to use battle tested open source software. I don't suggest writing a database in house. Also, I would say the opposite, it happens all the time. There's only a few closed source software tools that have been around for more than fifteen years, and countless that didn't make it.
Draiken 3y ago
>Companies have a very strong incentive to ensure their products are supported long terms and work well. I would say that's not quite accurate. They have only one incentive: profit. Long term supported products are one way of getting money, but it's most definitely not the only way. Many times it's not the most profitable one either. Companies don't make shitty decisions because they are scheming on how to screw customers up. They do it because when push comes to shove, only profit matters. One guy will plot a chart saying if we screw customers this way (with pretty words, of course) we can get X% more profit. Then they get promoted and this cycle repeats itself. Or a pandemic hits and suddenly your margins decrease drastically. Now screwing the customer is back on the table. Unless your company only plans to be running for a few years, those are not as rare as we may think.
dehrmann 3y ago
If AWS actually tried to abuse its power, it would really damage the tech industry. Tech companies would see the risk and start treating the cloud as rented machines (EC2), and stop realizing all the benefits of their provider managing a complex system on their behalf. If I were AWS, I'd willingly write into contracts that costs can go up no faster than the PPI + 5%, barring some sort of force majeure. Hardware gets cheaper, so I'd expect costs to come down, but this essentially "we're not going to screw you" clause.

fragsworth 3y ago

> DynamoDB, MongoDB, Elasticsearch, AWS Lambda, Azure, AWS, Azure Devops, SqlServer, Oracle, etc. At least with these individual tools, it's usually not your entire codebase written around that thing. For instance, you can generally switch from one database to another if they decide to overcharge you. You can even switch from one cloud service to another. In other words, they (usually) don't have you nearly as locked in. With Unity, it is a much bigger ordeal to switch to something like Godot and Unreal and most people who have already finished their games can't even really consider it as an option. This is why it was so egregious.

JackMorgan 3y ago
Of course you can switch databases, but in practice it is extremely expensive. That's a big reason why it is pretty rare. Why use a closed source tool and take on that risk when great open source ones exist?
- fragsworth 3y ago
  Usually the only good reason is because you already have developed lot of experience with with it. I'm just saying it's not as bad because it's quite a bit easier to switch a database than to switch a game engine.
  - dan_mctree 3y ago
    For a lot of companies, switching databases is effectively impossible. Perhaps not quite as impossible as switching game engines, but certainly impossible enough that it would kill the business. A lot of companies use database specific functionality that's far from trivial to replicate in another database. A lot of that database specific functionality can also be legacy that no one really understands anymore. Migrating without an option to keep these poorly understood but critical systems will set you up for unexpected data loss, corruption or availability issues. And that's after spending a year on your migration. If Oracle pulls anything like Unity here, this will kill off a lot of companies

wilsonnb3 3y ago

It is a wake up call, I don't think open source is the only solution though. You just need good business practices. Work with vendors that you trust, vet your dependencies, decide how much risk you want to tolerate, pay attention to the licenses that you are using. Especially for something as critical as a game engine is to game development companies.

tombert 3y ago
I agree that it's not the only solution, but it's the only way to (somewhat) guarantee a lack of bullshit. There are companies like The Omni Group that I think are, generally speaking, bullshit-free. They make (in my opinion) pretty good products, I can buy them once, I get the normally-expected number of updates, and it's about as ideal a transaction you'd want. I don't mind them charging money for a good product, and I'm grateful that products like OmniFocus exist. That said, one thing that continues to bother me is that Omni could change things whenever they want. They could decide to start charging 10x the price if I use OmniFocus for anything involving business, or they could make it so that my flat-fee purchase of OmniFocus no longer works. Do I think Omni is going to do that? No, I think they're generally pretty decent people, but open source guarantees that I can always take a snapshot of the "current state" of the project, and also guarantee that there's not retroactive strings being attached to things I'm making with that software.

manquer 3y ago

> MongoDB, Elasticsearch > Redis You suggest that mongo and elastic search are not open source and redis is ? While all three have a company backing them and sell or have some restrictions (usually targeted towards cloud providers not self hosting ) i would have said all of them are open enough in their current versions not to have a vendor lock in risk

yjftsjthsd-h 3y ago
Redis is open core (that is, redis itself is Open Source, only extensions aren't), the others are outright not Open Source. That's a meaningful difference, depending on whether you're using the non-FOSS extensions.
- manquer 3y ago
  What are you on about ? https://github.com/elastic/elasticsearch https://github.com/elastic/elasticsearch https://github.com/mongodb/mongo https://github.com/mongodb/mongo How are ES and mongoDB not open source ? Mongo switched from GPL v3 to SSPL in 2018 the only difference is whether you can offer mongoDB as a service , all other GPL clauses are the same , there is no difference for app developers I.e no vendor lock-in Elastic moved from Apache 2 to ESL v2 for the same reasons with same restrictions against managed offerings again no restrictions for a app developer to host modify or do they want . Redis splits between 3-BSD , SSPL and RSAL v2 and closed source for redis , Redis stack and Redis enterprise. Just cause OSI does not consider restrictions on competing with the author Open source doesn’t make elastic or mongo less open source ( redis also uses these ) certainly not for anyone not a cloud vendor
  - yjftsjthsd-h 3y ago
    > Just cause OSI does not consider restrictions on competing with the author Open source doesn’t make elastic or mongo less open source ( redis also uses these ) certainly not for anyone not a cloud vendor Okay, sure, if we allow people to redefine words whenever they feel like it they can be open source. Which is to say, no, that's not what those words mean. It can be https://en.wikipedia.org/wiki/Source-available_software https://en.wikipedia.org/wiki/Source-available_software but not FOSS.

bastardoperator 3y ago

That's great in theory, but most people don't have the funds for a rack, let alone a cage, or people to stack and maintain it all. The hardware alone to run a proper DB cluster is going to be prohibitive for most startups.

fendy3002 3y ago

While I support using the open source counterparts, most of the time the closed source tools price change doesn't happen retroactively. It's usually go together with new version or new contacts. Unity pricing though, happens retroactively in a sense that older, released games will be tracked the install numbers too. As if when SQL Server having the price changes to gb-based pricing happens too to 2005 version and forward. I can assure that even government will decline that kind of retroactive change.