For interhackt, I have the following idea/pitch:
In open source projects, growth and evolution has always been very tricky. The project maintainers have to tradeoff between increasing complexity (which will drive away new comers either using or contributing to the project) and increasing demand for features or solving common issues. Often, it ends up being that a project grows so complex that only the few people that have been active throughout the entirety of the project development are the only ones that can hope to ever make meaningful changes. Some very common examples are Tensorflow, WebKit, Babel which grow more and more complex every year and have become a different beast entirely from when they were conceived.
Casual contributors are often aware that they have little context for what is going on behind the scenes of the project. But more importantly, they do not want to spend time familiarizing themselves with a project's goals, roadmap, and contribution process. ~ Nadia Eghbal, Working in Public
My argument is that complexity of the codebase in itself is not the reason that drives new users and contributors away. After all, we can use a computer and phone perfectly fine without having to understand any of its internals. Our abstract reasoning skills are extremely efficient and it's what led to us being able to build tools any more complex than a hammer. It's the reason we can build houses, city-wide electricity distribution networks, 5G networking infrastructure, and particle accelerators spanning 20 miles. The complexity of even the biggest open source projects pale in comparison to what we've been able to accomplish as humans, so why is it so difficult for new comers to the project to understand it?
Ultimately, I think it's the way this complexity is displayed and communicated. I envision a future where a project on Github can be reasoned about in terms of its abstract components which can break down into further abstract components and so on until you get to the actual code. This is already kind of possible with division of the project into folders and subfolders and comments in the code, but the bottom line is that the hierarchical model of displaying code is not good enough. Codebases have complex dependency relationships that cannot be understood easily without a more natural way of visualization.
Up to here is my submission for Interhackt. Everything afterward shouldn't be counted.
This originally started as Program detail zooming tool
For interhackt, I have the following idea/pitch:
In open source projects, growth and evolution has always been very tricky. The project maintainers have to tradeoff between increasing complexity (which will drive away new comers either using or contributing to the project) and increasing demand for features or solving common issues. Often, it ends up being that a project grows so complex that only the few people that have been active throughout the entirety of the project development are the only ones that can hope to ever make meaningful changes. Some very common examples are Tensorflow, WebKit, Babel which grow more and more complex every year and have become a different beast entirely from when they were conceived.