[intellectable]

I think SMC will evolve to become the backend technology for empowering the textbooks of the future.

At this point in time the state of there is no github for academia. I find it strange that before the ultimately collaborative pursuit of academic knowledge can be done there exists this formality of competing for cash. In contrast I like how the opensource community has become a self organizing system independent and driven by volunteerism. Hope to see the day where academia is more like the opensource community and Sage Math Cloud becomes a platform to transform the competitive academic world into a collaborative and evolving opensource community of mathematical researchers.

I believe the hotspot for discussing academic pursits in math currently is http://polymathprojects.org/ as mentioned here https://terrytao.wordpress.com/category/question/polymath/ That is more like a blog or a forum site then per say a github for academia. So, where is the future of online collaborative academic research?

[williamstein]

One of the NSF grants that I mentioned not getting in the blog post was about using SMC as a platform for open source textbooks, just as you imagine. We haven't made the proposal public before, but here it is: http://tinyurl.com/utmost2-pdf

[plonh]

May is not programming, and math is often handwritten, so there is a lot of friction in setting up a DCVS for "scratch work". Polymath was rather awkward, and I would guess it was either (a) an easy problem for the (genius) solvers, relative to regular work, and (b) an annoying data transfer.

But here are certainly room for improvement above Blog Comments as a collaboration UI. Even a google spreadsheet would have been better.

[jacobolus]

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.

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.

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/mailing lists, internet chat, debuggers, profilers, package management, build tools, virtualization, graphical diff, version control and DVCS, blogs, wikis, ticket trackers, Q&A sites, etc. etc. (not even to mention various dynamic language features, coroutines, better garbage collectors, JIT compilers, network APIs, &c.) – has been remarkable, and software development today looks very different than it did 30 years ago.

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.

Tools for, say, CAD/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”.

To take the example of a field I’m familiar with, image editing/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/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/gimmicky, mistargeted, poorly designed, poorly explained, and ultimately used haphazardly or ignored.