4 ms·

Best bit of tech advice I ever got was way back in 1997 when I was building an e-commerce site. I was totally new to this, not a programmer, and needed guidanc

by sivers 7y ago

Best bit of tech advice I ever got was way back in 1997 when I was building an e-commerce site. I was totally new to this, not a programmer, and needed guidance. I was about to go with some commercial software called Drumbeat, that ran on top of some Microsoft stuff. Some experienced programmer said, “Only use truly open source choices, not anything owned by a company, because if the company turns bad or stops upgrading, you'll be screwed.” So I used PHP and MySQL and that one decision changed my life completely. Years later I swapped out the PHP for Ruby, and switched from MySQL to PostgreSQL, but I was able to because they were all just open solutions. That program called Drumbeat got bought or sold or something and eventually shut down. I'm so glad I wasn't banking my company on them. That one decision back in 1997 has helped save me so much strife over the years. Just like the comments here (that I've seen so far) there will be a bunch of commercial ecosystem fans saying, “The ecosystem is fine! Just learn to work within their boundaries!” (Don't upgrade until x.1 etc.) But it sounds like you've hit your freedom moment. Use this frustration to switch to truly open source choices, and never depend on any one company again.

_AzMoo 7y ago
On the flip-side, when relying on OSS you can often find yourself in a situation where the last maintainer of a library critical to your workflow disappears, and the only options you have are to fork it and maintain it yourself (at high cost), or switch to something else if it's available (often at high cost). OSS is not a panacea for development risk.
- Beltiras 7y ago
  At that point you have that choice. If the software was proprietary you only have the migrate option.
- SmallDeadGuy 7y ago
  It isn't, but the fact that you have two options (maintain yourself or switch to another solution) instead of a single option in the case of non-OSS (only switch to another solution) is a huge benefit. And, unless you're using some very obscure OSS or very outdated OSS (probably a bad idea), the likelihood is that there is a community around the product which consists of multiple maintainers/experts who are willing to continue development even after key maintainers move on
- chme 7y ago
  You can always choose some well supported and active open/free source product. If that gets abandoned, then you will figure that out and there will be others in the same boat as you and share the cost. Also you could just pay some open/free source developers if they provide mission critical software for you, so that it does not get abandoned. Free as in Freedom, not as in beer they say.
  - tmikaeld 7y ago
    This depend entirely on the scope of the software, take the project Rubedo CMS [0] for example, which died after funding was cut. It was simply too large for anyone to pick up where they left off. [0] https://github.com/WebTales/rubedo/issues/1477 https://github.com/WebTales/rubedo/issues/1477
- arghwhat 7y ago
  To be fair, for many libraries, maintenance is not really required. Hit a bug? Don't do that, or fix that particular bug. Doesn't require daily changes. Certain types of exposed and way too large components need constant hardening (e.g. OpenSSL, nginx) to patch CVEs, but they are the exception not the rule. We're a bit too stuck on the idea that things need to constantly change to be healthy.
- _wldu 7y ago
  Use large, well-regarded open source code/projects. They are easy to find. Prefer ones with ISO standards (C, C++, etc.) where possible. Other, non iSO, projects are reputable as well (Go, Python, etc.) but may be influenced more by vendors. If you rely on open source code that only has one developer (or a small team), fork it or write your own.
  - chme 7y ago
    > If you rely on open source code that only has one developer (or a small team), fork it or write your own. Please no. Try to pay the developer or upstream your own changes first. There are so many different active and unmergable forks of the same project already on github. That makes finding the 'right' project for yourself just much more difficult.
WA 7y ago
But what OP says is true for OpenSource as well. If the whole company uses Ubuntu, Eclipse and some Linux tools, their workflow is tied to these products. No matter if they're open source or not. If something gets abandoned that is crucial to the existing workflows, things get messy.
- UI_at_80x24 7y ago
  That's very true (I don't think OP was suggesting otherwise), but what OSS does more then closed-source is give you a way out. 99 times out of 100 there will be an option/method to migrate your data out/away from $abandoned_project. That is the real freedom OSS offers, you are not trapped.
- jononor 7y ago
  If Canonical goes belly up tomorrow, Ubuntu is likely to continue to work fine for users for a few years. Allowing a slow and gradual migration to another Linux distro.
- VvR-Ox 7y ago
  1. If Ubuntu fades away you can use another distro (if you want it can still be debian-based) 2. Take a look at Intellij or VS Code - there is no need to use Eclipse anymore 3. "Some linux" tools run on nearly all distros and also you can use a lot of them in mac and windows nowadays The openness of these products enables you to switch more easily because you aren't caught in some walled garden with proprietary file formats etc. that is just what @sivers said (e.g. mysql -> postgres). Consider Pages, Keynote etc. for example which have their own formats. If your mac dies you probably need another one just to open the files again. I saw this with MS office formats, Photoshop and many more. Some people manage to open the files with other (FOSS) tools but most of the time it doens't resemble the original layout because that's why you use proprietary formats in the first place maybe. In the end everything will be replaced some day. Your hardware, software and also file formats and layouts and everything else. In my opinion it's a good precaution to stay with open formats and build software workflows in a modular way so you can easily switch components for specific tasks. It's more work in the first place to get to your ideal workflow and maybe it's also more expensive than some commercial app that happens to provide enough features to build your workflow but you are more resilient to dying / misbehaving companies etc.
_wldu 7y ago
Great advice. Everyone needs to understand this fundamental fact about software. It's all about lock-in and control (no matter the vendor). This is the primary reason I only use open source programming languages (preferably ones with ISO standards not controlled by one, or a handful of companies). I can't imagine running a business or designing a system that relies on some closed source, black box code. It's just too risky and will come back to bite you and may even ruin your endeavor.

by sivers 7y ago

_AzMoo 7y ago

On the flip-side, when relying on OSS you can often find yourself in a situation where the last maintainer of a library critical to your workflow disappears, and the only options you have are to fork it and maintain it yourself (at high cost), or switch to something else if it's available (often at high cost). OSS is not a panacea for development risk.

Beltiras 7y ago
At that point you have that choice. If the software was proprietary you only have the migrate option.
SmallDeadGuy 7y ago
It isn't, but the fact that you have two options (maintain yourself or switch to another solution) instead of a single option in the case of non-OSS (only switch to another solution) is a huge benefit. And, unless you're using some very obscure OSS or very outdated OSS (probably a bad idea), the likelihood is that there is a community around the product which consists of multiple maintainers/experts who are willing to continue development even after key maintainers move on
chme 7y ago
You can always choose some well supported and active open/free source product. If that gets abandoned, then you will figure that out and there will be others in the same boat as you and share the cost. Also you could just pay some open/free source developers if they provide mission critical software for you, so that it does not get abandoned. Free as in Freedom, not as in beer they say.
- tmikaeld 7y ago
  This depend entirely on the scope of the software, take the project Rubedo CMS [0] for example, which died after funding was cut. It was simply too large for anyone to pick up where they left off. [0] https://github.com/WebTales/rubedo/issues/1477 https://github.com/WebTales/rubedo/issues/1477
arghwhat 7y ago
To be fair, for many libraries, maintenance is not really required. Hit a bug? Don't do that, or fix that particular bug. Doesn't require daily changes. Certain types of exposed and way too large components need constant hardening (e.g. OpenSSL, nginx) to patch CVEs, but they are the exception not the rule. We're a bit too stuck on the idea that things need to constantly change to be healthy.
_wldu 7y ago
Use large, well-regarded open source code/projects. They are easy to find. Prefer ones with ISO standards (C, C++, etc.) where possible. Other, non iSO, projects are reputable as well (Go, Python, etc.) but may be influenced more by vendors. If you rely on open source code that only has one developer (or a small team), fork it or write your own.
- chme 7y ago
  > If you rely on open source code that only has one developer (or a small team), fork it or write your own. Please no. Try to pay the developer or upstream your own changes first. There are so many different active and unmergable forks of the same project already on github. That makes finding the 'right' project for yourself just much more difficult.

WA 7y ago

But what OP says is true for OpenSource as well. If the whole company uses Ubuntu, Eclipse and some Linux tools, their workflow is tied to these products. No matter if they're open source or not. If something gets abandoned that is crucial to the existing workflows, things get messy.

UI_at_80x24 7y ago
That's very true (I don't think OP was suggesting otherwise), but what OSS does more then closed-source is give you a way out. 99 times out of 100 there will be an option/method to migrate your data out/away from $abandoned_project. That is the real freedom OSS offers, you are not trapped.
jononor 7y ago
If Canonical goes belly up tomorrow, Ubuntu is likely to continue to work fine for users for a few years. Allowing a slow and gradual migration to another Linux distro.
VvR-Ox 7y ago
1. If Ubuntu fades away you can use another distro (if you want it can still be debian-based) 2. Take a look at Intellij or VS Code - there is no need to use Eclipse anymore 3. "Some linux" tools run on nearly all distros and also you can use a lot of them in mac and windows nowadays The openness of these products enables you to switch more easily because you aren't caught in some walled garden with proprietary file formats etc. that is just what @sivers said (e.g. mysql -> postgres). Consider Pages, Keynote etc. for example which have their own formats. If your mac dies you probably need another one just to open the files again. I saw this with MS office formats, Photoshop and many more. Some people manage to open the files with other (FOSS) tools but most of the time it doens't resemble the original layout because that's why you use proprietary formats in the first place maybe. In the end everything will be replaced some day. Your hardware, software and also file formats and layouts and everything else. In my opinion it's a good precaution to stay with open formats and build software workflows in a modular way so you can easily switch components for specific tasks. It's more work in the first place to get to your ideal workflow and maybe it's also more expensive than some commercial app that happens to provide enough features to build your workflow but you are more resilient to dying / misbehaving companies etc.

_wldu 7y ago

Great advice. Everyone needs to understand this fundamental fact about software. It's all about lock-in and control (no matter the vendor). This is the primary reason I only use open source programming languages (preferably ones with ISO standards not controlled by one, or a handful of companies). I can't imagine running a business or designing a system that relies on some closed source, black box code. It's just too risky and will come back to bite you and may even ruin your endeavor.