FTG Wiki

User Tools

Site Tools

Trace:
kb:topics:software:open_vs_closed

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
kb:topics:software:open_vs_closed [2026/09/29 04:43] – robertkkb:topics:software:open_vs_closed [2026/11/06 10:33] (current) – robertk
Line 1: Line 1:
 ====== Open vs Closed Source Software ====== ====== Open vs Closed Source Software ======
  
-I just generally hate closed source software. I certainly understand the profit motive and the need to generate to revenue to build these tools, but there are some new trends that have made already shoddy software even worse.+I just generally hate closed source software. I certainly understand the profit motive and the need to generate revenue to build these tools, but there are some new trends that have made already shoddy software even worse.
  
 ===== IP ===== ===== IP =====
Line 13: Line 13:
 I think the only place closed source software sometimes beats open source projects is development velocity. This happens for two basic reasons. The first is that because corporations have some sort of top down structure, a definite priority or marching orders exist. Because of how most open source projects structure their organization, getting that cohesive direction can be much harder. That itself cuts both ways because being given marching orders isn't very useful if they are to develop anti-features or delete useful ones because they could monetize the feature. I think the only place closed source software sometimes beats open source projects is development velocity. This happens for two basic reasons. The first is that because corporations have some sort of top down structure, a definite priority or marching orders exist. Because of how most open source projects structure their organization, getting that cohesive direction can be much harder. That itself cuts both ways because being given marching orders isn't very useful if they are to develop anti-features or delete useful ones because they could monetize the feature.
  
-Similar to the problem of being directionless, sometimes open source projects just burn out. You can see months or even years of steady development and if the repo owner decides he is done, you have to just hope everyone that is left can get together and make a meaningful fork. This means a project can be hyper-relevant, but still die, whereas a company that is developing in that same niche will likely stay at it if there is still money to be made.+Similar to the problem of being directionless, sometimes open source projects just burn out. You can see months or even years of steady development and if the repo owner decides he is done, you have to just hope everyone that is left can get together and make a meaningful fork. This means a project can be hyper-relevant and still die, whereas a company that is developing in that same niche will likely stay at it if there is still money to be made.
  
 I still think that open source projects win in this area overall and I think the reason is actually that being directionless and getting burnt out are a more natural lifecycle. Companies have a tenancy to develop software endlessly into a pit of irrecoverable technical debt whereas when big open source projects do that there is usually some random dude rewriting the whole thing in the newest fastest language. I would rather switch software every 2 years when something better comes along than lock myself into the endless release cycle of some substandard product. I still think that open source projects win in this area overall and I think the reason is actually that being directionless and getting burnt out are a more natural lifecycle. Companies have a tenancy to develop software endlessly into a pit of irrecoverable technical debt whereas when big open source projects do that there is usually some random dude rewriting the whole thing in the newest fastest language. I would rather switch software every 2 years when something better comes along than lock myself into the endless release cycle of some substandard product.
Line 21: Line 21:
 Despite my willingness to switch when something better comes along, I think the most valuable thing about open source software is that it if there is every a change that breaks some part of my workflow, fixing it is as easy as reverting to the last release. Most monolithic closed source software tends to be released in a manner that it is not possible to just download the previous version. That is not always the case, but it is almost always true for subscription based software. Despite my willingness to switch when something better comes along, I think the most valuable thing about open source software is that it if there is every a change that breaks some part of my workflow, fixing it is as easy as reverting to the last release. Most monolithic closed source software tends to be released in a manner that it is not possible to just download the previous version. That is not always the case, but it is almost always true for subscription based software.
  
-It is foolish to rely on something that some junior engineer can mess up that then gets pushed as an automatic update that borks my setup. Sure there are code reviews and bureaucratic safeguards against that in most companies, but that is never that reliable. Fusion 360 is a great example of this. The number of times an update has rendered some feature broken or messed up a CAM program in the 5 years I worked at [[about:cust:idl|IDL Industries]] is mind-boggling. It is much more sound for me to decide when to update and to also be able to walk that update back whenever I feel like it, 'security' be damned. I would rather spend an hour solving my own problem rather than sitting on my hands for two days hoping someone else resolves the problem.+It is foolish to rely on something that some junior engineer can mess up that then gets pushed as an automatic update that borks my setup. Sure there are code reviews and bureaucratic safeguards against that in most companies, but that is never that reliable. Fusion 360 is a great example of this. The number of times an update has rendered some feature broken or messed up a CAM program in the 5 years I worked at [[about:cust:idl|IDL Industries]] is mind-boggling. They even had to release a feature that allowed people managing multiple licenses to pause updates for a set period of time to avoid these haphazard releases. It is much more sound for me to decide when to update and to also be able to walk that update back whenever I feel like it, 'security' be damned. I would rather spend an hour solving my own problem rather than sitting on my hands for two days hoping someone else resolves the problem.
  
 On a lot of open source projects, I can literally grab something that was part of their beta, before they even considered the project usable, if I felt like it. That is freedom you won't see with something closed source. On a lot of open source projects, I can literally grab something that was part of their beta, before they even considered the project usable, if I felt like it. That is freedom you won't see with something closed source.
kb/topics/software/open_vs_closed.txt · Last modified: by robertk

Page Tools

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki