The GitHub State of Open Source report highlights a fascinating trend: 80% of GitHub contributions are to private repositories, totaling around 4.2 billion contributions, compared to over 310 million for public and open-source projects. This discrepancy underscores the significant role of InnerSource within corporations.
InnerSource, unlike open source, pertains to a company's internal codebase. It encourages contributions across various departments and teams. One key aspect where InnerSource shines is in standardized development environments. Whether dealing with a mono-repo or multi-repo setup, developers often encounter internal libraries requiring modifications or bug fixes. The challenge arises when the necessary changes are cumbersome due to different tooling or version discrepancies. This situation leads to a common dilemma: either file a ticket and hope for the best or, worse, ignore the issue entirely.
The crux of the problem lies in the friction of adapting to different environments. A developer's primary environment, which caters to 80-90% of their workload, might not align with the project they need to modify. This misalignment results in deviating efforts, often perceived as time-consuming and frustrating.
However, this friction can be significantly reduced with a standardized development environment. Imagine a scenario where launching a development environment like Daytona brings up a pre-configured setup with all the necessary tools. This convenience allows developers to focus on the code rather than the setup, making contributions to internal projects much more accessible and efficient.
This approach is beneficial for regular employees and immensely helpful for onboarding new developers or contractors. These individuals often face a steep learning curve when trying to understand the intricacies of different projects. A standardized environment simplifies this process, allowing them to concentrate on coding rather than the environment setup.
The analogy of a 'developer commute' is apt here. Just like a physical commute to the office, setting up a development environment is a necessary but not inherently valuable task. The real value lies in the work done, not in the preparation. Therefore, providing a consistent, easy-to-access, and discardable standardized environment is crucial. It enables developers to focus on their work without being bogged down by the nuances of different setups and versions.
