What ever became of that discussion? I seem to recall Jacob Kaplan-Moss being interested in actually implementing it. I should ping him…

1> Yup. I know you didn't single licensing out; it's a sensitive topic for me, as I obviously fall in the more-permissive-is-good-and-helps-me-put-bread-on-the-table group. Maybe you're right; people will be more consumers than collaborators in a more permissive model, but as I said before, I wouldn't trade that for anything. You have to pick one, and take the good with the bad. *shrug* Sure, there's been plenty of GPL-and-the-like projects which are *huge* successes, that's simply undeniable, but I don't think it's impossible to have great success with a more permissive license, see Free/Open/etc BSD for an example.

2> Wikis are a tough thing. I firmly believe the only reason wikipedia is successful is because of stringent guidelines, and a massive staff of editors constantly patrolling and ensuring quality and factual information. Yes, wikis are good for a low-barrier-to-add, but that's *also* the drawback. A low barrier means a need for constant policing. I'm not saying I don't want people to collaborate, but how much of the information there is of good, high quality?

3> I like your ideas around cleaning it up, and making it a better user experience. I'd also like to add that adding links into the python documentation which references wiki pages or something which says “see wiki topics on xxxx” would make things a lot better too. For example a link in the multiprocessing documentation that says “see addition information at wiki/python_version/multiprocessing/” or wiki/multiprocessing” where the top-level multiprocessing page had information about all of the releases, and pointers to more information.

I'm looking forward to Georg and the GSoC project around the sphinx docs – I am definitely one of those people who prefers structured, high quality documentation (ergo us discussing it), but I am definitely pro making it easier to contribute and find additional information.

I don't know if you have the time, or the will – but maybe someone does need to step up and volunteer to be the BDFL (or a period shorter than life) for the python wiki experience, and be the one to unify/make the hard decisions. Sometimes making those decisions makes you unpopular, but having a good, singular view does make for a more unified experience.

My remark about permissive licences didn't single them out as the only factor – if you want an example of a project with good momentum and a certain amount of community interaction with the core developers, I suppose you could also consider PostgreSQL – but the kinds of community that form around projects using different styles of licences are often quite different. I have it on good authority that when the licensing of a project becomes more permissive, you do get an influx of people who are more “consumers” of the code than collaborators around the code. Perhaps the people who feel more “comfortable” about a permissive licence are also the people who are less likely to interact with the development community around that code, who possibly don't see the value in contributing, and who don't feel a common sense of ownership of the project.

I note that your feelings about Wiki solutions has appeared more than in one context during this debate: “And I hate wikis, it's impossible to find anything in them, information is spread all over the place, etc.” Although the API documentation probably doesn't belong in a Wiki, there isn't anything better for getting people to contribute or for letting them go off and do something that the documentation maintainers didn't expect. Information about alternative solutions for accessing remote services, for example, is precisely the kind of thing Wikis work well at recording and presenting. Various alternative initiatives around the Python documentation seem to have had all the hallmarks of up-front planning and narrow, predetermined methods of contribution which probably create a queue of change suggestions with a bottleneck similar to what we already have, and leave people wanting to expand the documentation (as opposed to change small pieces of it) out in the cold.

I'm one of the people who administers the Python Wiki, and although I'll admit that it could be better organised, the policy so far has been to tread lightly and not be too severe with the editing. If I had a greater say in the python.org “assets”, I'd make a refined version of the Wiki front the whole site experience, dropping the dated and inconvenient-to-edit main site with its glacially paced changes and increasing saturation of links to the Wiki. And I'm not really a Wiki advocate – I just remain baffled at the obsession that exists in various quarters that Wiki solutions are “all very well” but there has to be a “proper site” fronting the whole affair with little concrete justification for that position.

1> I agree. I think it's easy for people to throw rocks at the XML handling then to find someone willing to step up (as Tarek did for disutils) to take something and improve it incrementally over time, and volunteer to be it's shepherd. The stdlib *needs* something for XML, finding someone to do it is another thing entirely.

2> Again; someone needs to step up. To replace something, or even be added to the stdlib, it now has to be “best of breed” (see brett's post on this here: http://sayspy.blogspot.com/2009/05/staleness-of...). As for people ignoring other things that have happened, that's par for the course, and sometimes (not all the time) even if something has happened elsewhere, it may not be the right solution. It happens. And I hate wikis, it's impossible to find anything in them, information is spread all over the place, etc.

3> The barrier to change things is high: you not only have to have a good idea, you have to be willing to fight for that idea. And yeah, I know we're all on borrowed time, and it is demanding, so things that could change, simply don't.

“Python's Neglect” is largely a side effect of this – the core developers are few, people have to be willing to convince many other people that their idea has not only merit, but that the person proposing the idea will be willing to help create, test, document and maintain the thing they are offering. And Python, because it is in widespread use, has to evolve slowly and relatively carefully.

It is a product of a number of things. Low resources (people, time), high barrier (you have to be willing to fight if you believe in it) and resistance to change (we've always been at war with eurasia).

I do not, however, agree that this is somehow a side-effect of the licensing. One of the reasons I contribute, and have been able to convince my employers to let me contribute to python-core is *because* of the permissive licensing. In my discussions with others, I have heard this anecdotal evidence repeated time, and time again.

Python core does nothing to deny participation, except limit commit privileges to a select group of people who have gained an amount of trust. Everything is open; all discussions are a matter of public record, all checkins are public. Anyone can step up and write a pep (even me) and anyone can submit a patch to the tracker which can find it's way in.

I wouldn't trade the openness, and permissive licensing of the code for something which “forced” (ala the GPL) people and companies to give back. While that has worked for other projects, and continues to do so, I and many other people using python get the luxury of using it, and sometimes giving back to it where we might not be able to do so with something with a forced-participation license.

Part of the beauty of it, is that it's good for individuals, and companies. Companies with half a brain (ala Google, companies I have worked for, etc) give back what they're comfortable with, and when they can. They use python to Get Things Done – and that's what Python is about, getting things done, and not adding restrictions or forced-participation clauses when it simply isn't needed. Part of the reason I love it is this fundamental pragmatism.

Would I like it if people/companies contributed more? Yes. Do I wish we had more people in core dev getting paid to give back? Sure. If I won the lotto tomorrow I'd probably start a small group of people whose sole job was to do nothing but improve the hell out of it. But I see no reason to force this.

There's a lot of things at work here, and a long road to hoe to get “big” changes into python-core, but in the immortal words of Jay-Z: “I got 99 problems but licensing ain't one”.

With urllib, on the other hand, there's a need to look around and see what else is available. I believe itools has modules of a similar nature, and there are third-party HTTP libraries, too. So in this case, the inspiration has to come from elsewhere, and perhaps urllib and urllib2 merely need to live on in some kind of compatibility library. The problem here is that there's a small industry in the Python scene in ignoring what people have already done: expect a PEP or two which ignore most of the work out there, despite there probably being a Wiki page on python.org with all the relevant projects listed.

I'd really like to improve the standard library, but given that any previous advice I've offered has been more or less been brushed aside, and given that we all have only a finite amount of time to do interesting stuff, I don't feel that it's rewarding work. And I guess that you know how demanding the work is, too. Maybe this discussion will change my attitude for a short period of time and I'll do something, but I can't help feeling that “Python's Neglect” is a product of a number of factors including but not limited to things like the way Python is “consumed” by its community and the way the permissive licensing encourages such consumption (as opposed to participation).

I'm just starting with python and it is a little annoying having to google for things because they are hard to find in the manual.