Magnus Lycka wrote:
>
It seems to me that an obvious advantage with either Roundup
or Trac, is that if the Python project used it, the Python
project would have a significant impact on how this product
developed. Even if the Jira people seem eager to please us,
I'm pretty convinced that it will be easier to get Roundup
or Trac improved to fit our particular needs.
Yes, because Roundup and Trac are open source projects: there is no
barrier to prevent the users taking the code in a direction appropriate
to their own needs. And just to make it clear that I'm not picking on
Jira, it should be noted that even with their apparent willingness to
make a useful "community" product (and their otherwise remarkable open
source credentials), the Launchpad developers can't offer the kinds of
assurances implicitly provided by Roundup, Trac or any of their open
source brethren.
That's valuable in two ways:
1) The Python project would get a bug tracker which is
developed with the needs of the Python project as a
prime concern. (Being the major "customer" of a product
has benefits. Jira on the other hand, might get more
and more integrated with other Java stuff that we don't
really care about.
As has been said already, there's supposedly no guarantee that people
will want to develop Roundup at a hectic tempo in order to satisfy the
needs/desires of the Python developers. But then again, other pieces of
infrastructure have a high community investment, notably Mailman (which
uses Jira as its issue tracker, as it turns out).
2) We'd help making a good Python product even better, and
probably more widely used, thus spreading the use of
Python even further.
It seems to me that with all the fuss about marketing Python [1],
instead of ranting about how other products and technologies are
stealing all the thunder, one might instead want to start closer to
home. In this respect, several opportunities are being missed or
squandered either because people think marketing is all about press
releases, or they want Python to retain its stealth label (the
"competitive advantage" people mention constantly).
Take python.org as the place to start. One can claim all one likes
about how Web applications aren't special enough to warrant special
mentions or coverage in the context of persuading people about Python's
advantages, but many people presumably visit python.org and wonder...
* How they can develop Web applications using Python in a way they
recognise either from intuition or previous experience. Where can
they find a good solution and get started quickly?
* Whether python.org, as some kind of content platform, is some kind
of convenient answer to their own Internet/intranet site project.
Can they download the code and run the same kind of thing
themselves?
The answers aren't too clear to these questions. I've revisited some of
the material available via python.org [2] in order to attempt to
provide clearer answers to the first question, but the topic of
standardisation is currently stagnant (so it's every framework for
itself), and the community is split between hyping the most popular
frameworks whilst emphasizing the modest achievements that led to WSGI
(which doesn't really answer the first question entirely). Meanwhile,
despite the python.org codebase presumably running various commercial
sites, it would surprise me if there would ever be a convenient
downloadable package of that codebase available prominently from
python.org itself (even though the components are all openly
available). So the Python project - the power behind content management
solutions like Zope, Plone and (at a different angle) MoinMoin - offers
an incoherent response to the second question.
Then, there are the other recommendations under the "Using Python
For..." heading - advocacy points to show how Python can be really
useful - which mentions under "Software Development" the following:
Buildbot, Trac, Roundup and IDEs. If one ignores the current issue
tracker debate for a moment and follows the "Software Development"
link, one reaches a general Python applications page which mentions
amongst other "choices for web development" the CPS project, and
following the provided link swiftly delivers another advocacy own-goal:
"We're switching to JAVA!" state the CPS people proudly, still
blissfully unaware that "Java" isn't an acronym; "Read why" they
suggest.
It's tempting to label what I've written above as just some
opportunistic criticism of the maintenance level of the python.org
content, that the core developers should just choose their tools and
get on with things, and that this thread has attempted to politicize
the decision under discussion from the start. Indeed, as someone who
merely browses python-dev, perhaps I shouldn't care how the core
developers track their bugs: if they struggle to manage that
information in future, why should I care? Well, the reason I should
care is related to the reason why the core developers should care about
more than purely technical issues: the wider community and the core
developers do not exist by themselves in isolation; the well-being of
the community is related to how Python is managed and portrayed by the
custodians of the language, and the well-being of the development
effort is related to how much community effort can be directed towards
improving the language and its image. If this were not so, Python would
have vanished like many of its contemporaries.
Perhaps the decision makers evaluated the above and much more in depth,
although us outsiders are not in a position to say, but perhaps the
discussion around the decision wouldn't have been so inflammatory in
places if there had been an acknowledgement of this "bigger picture" of
the community, its influences and that in a large open source project
no moderately significant decision is without a political dimension.
Paul
[1]
http://www.artima.com/forums/flat.js...&thread=150515
[2]
http://wiki.python.org/moin/WebFrameworks 
