3 ms·

Writing software within old-school enterprises is a daunting task involving lots of proprietary systems that create a lock-in of sorts. Complex build and test s

Writing software within old-school enterprises is a daunting task involving lots of proprietary systems that create a lock-in of sorts. Complex build and test systems, complex deployment and production systems are the norm. Weird tools and libraries with their own proprietary names and conventions increase the learning curve for any new-joinee. Some even have very proprietary non-standard language, runtime etc. making the skills acquired in such environments to be largely useless outside of such environments. Open source culture changed all this drastically. This culture started with individuals loosely connected via Internet who collaborated on writing software and without much complex central infrastructure. Common conventions and standards emerged as these individuals openly discussed them and took with them to other projects – not just conventions and standards, but also the code. Without the enterprise lock-in, this has proven to be extremely successful and cost-effective. Most commercial software companies today follow this new model for their internal software development practices. Using openly available technology components lets everyone to acquire portable skills that they can continue to improve throughout their careers across many different companies. This drastically reduces the cost of software production as cost of acquiring skills is amortized over many companies and cost of development effort of these open source standardized components is also amortized over many corporations/projects. Every company I worked in has supported contributing to open-source with the selfish motive to attract talented engineers. And the engineers like contributing to open-source projects as a way of showing off their skills and building their resume.

benibela 7y ago
Unfortunately that only leads to another kind of lock-in. The culture assumes everyone is using the same tools, so you are not allowed to use any kind of non mainstream software. And any smaller project using non mainstream libraries gets killed. For example I use Mercurial rather than Git. Mercurial had better Windows support, a better command line syntax and with TortoiseHg a better Linux GUI. However, it happens all the time that linux distributions include wrong versions of Mercurial and TortoiseHg. You can use an old version of Mercurial and an old version of TortoiseHg, or a new version of Mercurial and an new version of TortoiseHg, but the distributions package a new version of Mercurial and an old version of TortoiseHg, and then TortoiseHg does not start. So they ship a completely broken package and no one cares because it is not a standard tool. (and last time I tried to install TortoiseHg from source separately, it also did not run, because was not compatible to the Python version installed by the distribution) Recently I wanted to use a tool written in OCaml. It is really well written, has a GUI, using gnomecanvas. And it does not start anymore. Debian/Ubuntu has decided, gnomecanvas from gnome2 is deprecated and will no longer be installed. But the new gnome does not seem to have OCaml bindings. I am not aware of anyone working on a update to fix that. OCaml is too small to be allowed to make GUIs. I write my software in FreePascal. After a system update, my projects do not start anymore on Android. Turns out binutils has enabled relro by default and FreePascal does not work with relro enabled. Imagine GCC could not create Android apps in the default settings. That would be fixed quickly, but with FreePascal no one cares

benibela 7y ago

Unfortunately that only leads to another kind of lock-in. The culture assumes everyone is using the same tools, so you are not allowed to use any kind of non mainstream software. And any smaller project using non mainstream libraries gets killed. For example I use Mercurial rather than Git. Mercurial had better Windows support, a better command line syntax and with TortoiseHg a better Linux GUI. However, it happens all the time that linux distributions include wrong versions of Mercurial and TortoiseHg. You can use an old version of Mercurial and an old version of TortoiseHg, or a new version of Mercurial and an new version of TortoiseHg, but the distributions package a new version of Mercurial and an old version of TortoiseHg, and then TortoiseHg does not start. So they ship a completely broken package and no one cares because it is not a standard tool. (and last time I tried to install TortoiseHg from source separately, it also did not run, because was not compatible to the Python version installed by the distribution) Recently I wanted to use a tool written in OCaml. It is really well written, has a GUI, using gnomecanvas. And it does not start anymore. Debian/Ubuntu has decided, gnomecanvas from gnome2 is deprecated and will no longer be installed. But the new gnome does not seem to have OCaml bindings. I am not aware of anyone working on a update to fix that. OCaml is too small to be allowed to make GUIs. I write my software in FreePascal. After a system update, my projects do not start anymore on Android. Turns out binutils has enabled relro by default and FreePascal does not work with relro enabled. Imagine GCC could not create Android apps in the default settings. That would be fixed quickly, but with FreePascal no one cares