Sunday, January 10, 2016

Reaction to Python development moving to GitHub

If you don't know, the Python core developers are considering move to GitHub, which I believe will abandon Roundup, Mercurial and a couple of other initiatives that some of us picked, because they were used by community and were useful to it. For example I added support for Jinja2 to Roundup, tried to add a new router component for it to enable adding new web APIs more easily, and now I am doing a release of new version, because that package is valuable.

Below is my post sent to as an immediate reaction to the PEP that addresses the migration. I think that people need to consider Python as something with much better potential than just "a product to execute computer scripts". I want people to think about it as about open process with all the involved complexity and dynamics issues, a place to study and learn about different culture than following the orders of your owner founder. Some want to see it to be isolated coding playground without all that disturbances and annoying people with external world problems. But it is unavoidable. There are already diversity statement and codes of conducts. It is time to stop being ignorant to economics for the balance.

Blender is a good example. 3D editor that every two years chooses a problem that is actual for community and makes a movie together with building necessary features in the editor. They discuss economics, try to address funding issues by working with funds outside of coding domain, bringing new initiatives, communicating and still staying open - not ignoring the issues and not trying to bring the same hammer on the new "nail". Why Python fails to follow the same route?

I don't know why it bother me that much. Probably because I am jobless and living in northern country where you can't live on street and need to pay rent, so "getting paid for the useful stuff that you do" is extremely important issue for me. But also I feel that my time is limited, and that it is very sad to spend my life behind the screen of computer, reinventing some code that was written numerous time for a company that can not support something that is already written.

I realize that with reduced exposure to a projects like Roundup and Mercurial it will be much harder (if possible at all) to gather critical mass of resources around people to experiment with sustainability models for open source, and doing these things is important, because we coming into the age of extremely powerful automation where people may not be that needed anymore. For me open source is the only way to gather data on what will happen, and maybe the only way to find the balance. Open source economics right now is when resources are limited, but there are many people how could use them, but if they use them, others (who probably can do better) may feel bad about this. This is a just a single problem that needs to be addressed in the process, and I wish that there could be that sustainable working process in the list.

Here is original mail sent:

I think that the missing part is the analysis of why community (or PSF, or ...)
failed to create a streamlined development process themselves. In particular,
what steps were made to implement:

1. online code editing with patch creating through interface
2. HG plugin that can fetch a bugXXX patch and apply it to local copy
3. mercurial queue server to allow people to maintain their own queues of
patches in parallel and compare between them
4. what steps were made to make "our fork of the Rietveld code review tool"
to be the "our installation" or the "global Roundup service"
5. create testing and building infrastructure (or integrating with CI services
such as Drone.IO) for downloading patches, making sure they applied
cleanly and running the test suite

For simple things like "spelling in documentation" the whole thing with
patch production and attachment could be done in 6 months provided that
development for 4 people is funded (2 code, 1 frontend, 1 art).

The most important stuff - what are the current activities for PSF (or whatever)
to being raise funds to make it a paid work instead of relying on a really few
core developers and volunteers to do professional work on infra that requires
rather tight timely coordination and support?

For me, there is a more core problem inside. For example, why work under
GSoC 2015 for Roundup was not submitted upstream? Because it was not
part of the job. People have problems allocating their free time, because
time management practices at their HR departments are getting better and
better not leaving much for contributions.

I think that the core issue here is the money. The new generation talks
about startups and monetization, so if we don't address this, there is little
hope that new generation will be attracted, at least that's my observation.

I think that if PSF can help us with legal issues concerning funding open
source activities, we can construct a few teams through Gratipay and do
the development in open way. It will be more effective for Python in the
long run, because it will showcase that Python is capable of, and provide
people a playground to learn about good engineering practices. I am not
saying that this will 100% work - maybe there are things ahead that I do not
see as well, but what's drives me mad that it seems that nobody is even
trying to preserve the open source spirit in all of that.

If we will be sacrificing the open source so easily, then the next Python with
static typing will be 'Microsoft Python' or 'Facebook Python' will be rewritten
from scratch, and all credits gathered through all these years will be lost
behind the shiny name of another corporation. Sad.

No comments:

Post a Comment