Nick Coghlan

Exactly. On the Linux front, a number of us have been working with Linux vendors and major projects like OpenStack on their porting issues, and tackling those wherever it makes the most sense to do so (whether that's adding the "--py3k" mode to pylint, working to get Ubuntu and Fedora to using Python 3 as the primary system Python, or pushing for changes like making the C.UTF-8 locale a standard feature of upstream glibc). (Red Hat and Canonical actually each employ a number of CPython core developers, as do other major Python-on-Linux consumers like HP, Google and Rackspace)

As various technical barriers to porting are identified, we've either looked at ways to enhance Python 3 itself to address them (such as restoring full support for the binary transform codecs and reinstating binary interpolation support), or else looked at how to make porting tools like six, modernize and future easier to access (this is a key reason that the pip package installer now ships by default with both Python 2 and Python 3).

On the user front, the primary and secondary education sector have by and large switched to Python 3 already, and the inclusion of a dedicated matrix multiplication operation in Python 3.5 was specifically in response to feedback (and contributions) from the analytical Python community.

Aside from possible interest in the matrix multiplication operator for cleaner expression of matrix and vector operations, there unfortunately isn't a great Python 3 carrot for organisations like AutoDesk as yet (which is likely to be the tipping point for those parts of the 3D animation community that don't use Blender), but as noted in my reply to Clive, I'd like to tackle the current complexity of embedding at some point, which then becomes attractive for anyone that is currently needing to resort to complex hacks to get Python 2 to behave the way they would like it to.

As far as challenging the JVM and CLR goes, I agree that's a very interesting space, and I actually believe it's the PyPy community that are best placed to do it. Not only does PyPy embody an innovative approach to designing JIT compilers, but Armin Rigo's research into practical applications of Software Transactional Memory is genuinely groundbreaking, and offers a realistic prospect of being able to program PyPy hosted applications in an event driven model while still making use of all available cores, and without halting the entire application if you happen to make a blocking call from an event handler.

I think there's room for multiple different terms here, each emphasising different aspects of open, collaborative development. For example, "open source" focuses on specific legal requirements set out by the Open Source Initiative in the Open Source Definition, while "free software" emphasises the "four freedoms" to run, inspect, redistribute, and modify the software.

"Collaborative development" would instead focus on the fact that because duplicating a piece of software is free, contributors can put in (for example), 10% of the effort required to create the software, yet have full access to 100% of the result. With everybody able to access the whole, it makes sense to contribute to making that whole better, rather than maintaining your own additions in private, where nobody can provide constructive feedback, and where the assumption that others wouldn't be interested in using or contributing to the project becomes a self-fulfilling prophecy. Increasing your own level of contribution then makes it more likely that other contributors are willing to listen to you, thus allowing you to effectively advocate for more significant changes than you could manage to implement on your own.

In this context, it's arguable whether or not "single developer FOSS" even exists any more. Those single developer projects are likely relying on other open source components (for example, using an open source language runtime, deploying to an open source operating system, or using open source development tools), and are in turn incorporated into larger collaborative development projects (like Linux distributions, OpenStack, open source web services, etc).

I personally like the term "collaborative software", as it emphasises that these software development communities are primarily aimed at folks that are looking for a co-developer experience - those that are entirely happy with the idea that suggestions for improvements are likely to be met with "contributions welcome".

If you just want a complete, refined, pre-integrated offering under a traditional customer/vendor model, then you really do want to be dealing with the commercial side of one of the open source vendors - turning customer suggestions and complaints into upstream contributions that are acceptable to the community is one of the key services those vendors provide.

It's also worth noting that both "collaborative software" and "collaboration software" are already used as synonyms for "groupware". Hence my use of "collaborative development" above - it not only avoids conflicting with those existing terms, but also emphasises that this isn't a software specific concept. Collaborative development applies to any output where the marginal cost of reproduction has been reduced to near zero by the creation of the internet, and there is a community of potential contributors where the ability to both use the end result and influence the direction of future changes provides sufficient intrinsic gains that extrinsic compensation isn't necessarily required.