Great to see this brought up here, and to read the constructive and thought-provoking responses from members of the Julia community. I feel this is highly important and I have thougt a lot about it recently, as I am writing an invited guest editorial for a leading ecological journal about how transferring to julia as the lingua franca for ecological scientists may affect the way we do science and work together.
I come to this from a somewhat different angle, as the ecological community is almost 100% wedded to R – the use of R has practically exploded within the last 5 years alone. So when I came to julia I was struck by how structured the package ecosystem appears to be, yet, in spite of the micropackaging. This seems to me to be a huge advantage for collaboration, creativity and methods development, and IMHO this will in the end be a stronger argument for our community to make the transition than the speed of computation. I think there are a number of reasons for this difference, but I also believe that a primary reason is the reliance on github for developing the package ecosystem from the bottom up, and the use of organizations. These organisations, like JuliaGeo, BioJulia etc in effect act like standard package distributions, both by facilitating communication within, but also by imposing a set of strict guidelines on code compatibility. Centrally, the organisations are really visible centers for where development in a given field takes place, and thus the culture encourages developers to contribute to existing packages and organisations rather than inventing new packages. In R that is not the case - instead most scientific packages are one-lab projects developed to serve a certain research program. I do hope that this can continue in the future, but one might worry: right now most julia developers are driven by a desire to help build the language itself, but when it grows over a certain size and becomes established this is sure to become less pronounced. Also, the current practice of software papers in scientific journals means that researchers get credit for developing new packages, but none for contributing to existing packages. This directly counteracts the best interests of the community. It is a new situation to have a scientific language that is built openly and communally, yet with such a high degree of integration and communication. The solution must be culture, as written by Stefan and Tom, specifically to develop the community culture to keep communicating, discussing and agreeing upon standards. Also, for instance, organizations like the biojulia community are very good at identifying new ad-hoc packages coming out that relate to their work, and invite developers to join the communal effort and build the foundation of Julia in their field instead of creating lots of partial alternatives. I think this is key. But perhaps this could be strengthened by being more explicit about building modular 'standard libraries', like in the respective organizations, but perhaps also for base (or statistics/numerical analysis, at least) that impose strict internal guidelines for conformance? These organizations, of course, would need mechanisms for ensuring renewal within the basic ideoms, so development does not die. I for one will follow this development with keen interest.
