To developers moving from a relatively closed system, such as Windows or OSX environment, to the open Linux architecture, the learning curve involves far more than adding a new language or architecture to your repertoire. It usually means fundamentally changing how things are done from an engineering perspective.
Coding in a restricted or closed environment, where access to the source code for related apps and the core platform itself is limited, often means making guesses as to how things will interact and spending a lot of time (and lines of code) working around those interactions or restrictions. A wise computer science instructor once said that “programming is mostly just re-inventing the wheel.. repeatedly”.
In the open-source community, the problem-reaction and work-around culture dissipates and is replaced with an environment of predicting problems by examining source code in possible interactions and in ignoring work-arounds in favor of utilizing existing solutions instead.
For developers in the Linux community, for instance, emphasis is often on examining code (or pseudo-code) to find solutions without all of the cloak and dagger than can be involved in proprietary and legally-binding systems of development in which developers cannot speak with the community at large without being in danger of breaching contract.
Learning To Become Open
Learning to let go of the often closed-door background many developers move out of when entering the open-source community can be a difficult process. Further, going from close-knit, small teams into an open community of hundreds can also be a shock. Especially for those used to using their own team’s way of organizing code and markup, as the open community has a lot of standardization for things in order to keep code readable and usable by everyone in the community.
Further, suggestions for improvement, additions, changes, or modifications will nearly always be ignored if they are not accompanied by sample code, suggested code changes, or test code suggestions. Theoretical ideas abound in the Linux community, of course, but most of the energy and focus is on the real-world, actual application of ideas rather than on theories out in the ether.
The greatest advantage to open-source and the Linux development community at large, however, is that the trade off for all of this is a thriving community of experts who are more than happy to share ideas or help you work out problems, often by simply pointing to how it’s already been done elsewhere so you can just copy-paste and then hone your solution rather than build it from scratch. Since the community is open and most of the source code is as well, there’s little reason to reinvent the wheel.
Why the Difference Is Generally Better
The best part of working in open-source, and Linux specifically, is that code and solutions tends to be far smaller, more compact, and cleaner than its closed-source counterparts. It’s for this reason that most Linux distributions are far lighter weight than their competitive operating systems. Further, the open community surrounding Linux allows for both diversity (anyone can “spin off” their own version of Linux for their own use or distribution) and absorption (good ideas generally get absorbed into the core kernel quickly).
The heart of the Linux development model is open discussion and sharing. This means that Linux is fundamentally different than almost every other platform.