As development projects grow there comes a point in time when the GitHub ecosystem ceases to operate effectively, and typically the reported use issues relate to scaling up. The reported problems are related to the flow and accessibility of information amongst users, with the issue tracker becoming impossible to work with as more and more contributors/programmers join the team, resulting in increasing numbers of issues found and reported. Problems associated with the issue tracker include things like missing reproduction steps or version tested information problems; these can be fixed with a simple issue template with required fields as well as additional custom fields for pertinent information. As one GitHub user put it—We strongly feel that the code and issue tracker need to live in the same location to make it easier to manage and give people one location to visit. Those affected are a group comprised of the most successful projects on GitHub, but the question arises just because open source got your business to where it is today, do you stick with it?
As a result of a growing number of complaints from GitHub users, GitHub has issued an apology and have promised to address the issues raised. However, when a project is so big that the question as to whether to continue using GitHub comes up, then it is time to address the bigger issues in the room, such as what kind of distribution model to use and even whether to be open source or not going forward.
Of course, GitHub promotes their Enterprise version, GitHub Enterprise, but there are better alternatives for most business models. Just because a team is used to a specific tool does not make it the best choice; typically, ALM Software provides a better, more comprehensive solution.
The path forward for large open source projects is made more complicated by the fact that the very definition of what open source is, is open to debate and is in-flux. In the past, the term open source would imply that the software was free and that the money was made was through offering product customization and support. This is no longer the reality. Now, most open source vendors use a commercial license (product sold) for business use, either way–open source or proprietary. Businesses must now purchase the product and therefore, expect the same level of service and guarantees that proprietary software vendors supply (consider the requirements of industries where safety criticality is an issue).
Open Source is no-longer free for business
Therefore, it stands to reason that to supply the quality assurance and service necessary, open source development tools must be migrated away from to solutions that are more comprehensive and proven, supplying the complete traceability and transparency in development necessary to meet both the demands of industry standards and supply the level of service that enterprise clients expect. What's needed are tools that enable Agile Development at Scale (with the collaboration of 100’s+ of developers) and DevOps (continuous testing/continuous integration/continuous delivery) with unbroken traceability on every decision taken by every programmer for the entire Application development lifecycle. Considering the future of IoT and DevOps, an integrated service desk is necessary.