The academic community is much larger, broader, and more diverse than the open source software community. There’s much greater diversity in tools and methods, and less centralization of discussion. It is a community grounded in many centuries-old traditions, has more stakeholders involved (students, university administration, public officials, funding agencies, journal publishers), and moves relatively slowly as a body.<p>The open source community is in the wonderful unique position of having been mostly built during a time of instant and limitless free communication, and uses a set of tools and practices which are very accessible and not nearly so entrenched.<p>When you think about it, the speed of change and adoption in the whole constellation of modern software development tools – web browsers, search engines, email, usenet&#x2F;mailing lists, internet chat, debuggers, profilers, package management, build tools, virtualization, graphical diff, version control and DVCS, blogs, wikis, ticket trackers, Q&amp;A sites, etc. etc. (not even to mention various dynamic language features, coroutines, better garbage collectors, JIT compilers, network APIs, &amp;c.) – has been remarkable, and software development today looks very different than it did 30 years ago.<p>The speed of iteration and experiment in development of tools is so fast because the people building the tools and the people using them are a similar and heavily overlapping group, and because building new tools can be done relatively quickly and cheaply by small teams, and distribution and marketing of open source are cheap.<p>Tools for, say, CAD&#x2F;CAM, architectural design, structural engineering, 3d animation, video editing, chemical reaction simulation, etc. are much slower to evolve, because they take more professional expertise to work on, cost more up front to build, and have a set of users who mostly are not qualified to build the tools themselves and tool builders who don’t necessarily do professional-level work with it. Instead of “build what you need”, there are two disjoint groups whose mottos could be “buy what you need” or “build what you can sell”.<p>To take the example of a field I’m familiar with, image editing&#x2F;printing software (along the lines of Photoshop), there are at least 5 disjoint groups involved in any innovation: artists, technical authors, user interface designers, software engineers, and academic image processing researchers. New features are typically developed as a somewhat abstract mathematical model by academic researchers whose incentive is to publish papers with elegant theory, implemented by software engineers whose goals are mostly based around performance and raw function, fit into the existing interface by designers who are trying to match long-established conventions, explained by manual&#x2F;book authors who want to sell books (which usually means listing recipes instead of explaining difficult abstractions), and then used by artists who usually end up with no clue what the feature does. Along the way product managers, marketing departments, and others also get involved. None of those groups necessarily has the cross-cutting expertise to really understand the needs of everyone up and down the stack, so new features tend to be shallow&#x2F;gimmicky, mistargeted, poorly designed, poorly explained, and ultimately used haphazardly or ignored.