Right, I basically picked apache randomly. Pretty much any significant open source project from the era I was a student (1997-2001) has the same problem, from a student's point of view anyway.
The problem was that an intermediate student who can use gcc and make but has questions like "what's the best way to organize my source code into directories?" there were no good answers if you were stuck at the command-line with man pages. If you didn't have a good mentor, you were figuring it out for yourself, or trying to emulate a random open source project with hundreds of source files organized into multiple subtrees with helper files, shell scripts, dozens of libraries and modules, and huge configure files that bear no resemblance whatsoever to any problems you're actually trying to solve. Or, maybe, if not a big project, then another intermediate developer who was just as clueless as you and you don't actually want to be imitating.
Meanwhile, GUI-heavy IDEs were offering sane default answers for those intermediate questions and offering tools to help manage a moderate number of dependencies, build steps, and platform targets. Unfortunately, they were also hiding important details and too often became crutches for people who didn't understand how compiling and linking actually works.
I contend that things like "the best way to organize my project into directories" is something that is discovered, and changes, over time while building a project and is specific to that project and the people working on it. Obviously, students don't know this, but they should be writing code, and working toward this discovery, rather than fretting what to name the directory where library routines are stored as The One True Way™.
The problem was that an intermediate student who can use gcc and make but has questions like "what's the best way to organize my source code into directories?" there were no good answers if you were stuck at the command-line with man pages. If you didn't have a good mentor, you were figuring it out for yourself, or trying to emulate a random open source project with hundreds of source files organized into multiple subtrees with helper files, shell scripts, dozens of libraries and modules, and huge configure files that bear no resemblance whatsoever to any problems you're actually trying to solve. Or, maybe, if not a big project, then another intermediate developer who was just as clueless as you and you don't actually want to be imitating.
Meanwhile, GUI-heavy IDEs were offering sane default answers for those intermediate questions and offering tools to help manage a moderate number of dependencies, build steps, and platform targets. Unfortunately, they were also hiding important details and too often became crutches for people who didn't understand how compiling and linking actually works.