Before I reply to various points, let me preface by saying my interest is only in seeing Django succeed, because as a long time Csound user, I have watched less than ideal open source management push away really talented developers and result in unproductive fork wars. So it is not personal.
> If I were going to make up a list of "core developers" I think only > two or three of them even live in the same time zone as Kansas, and in > several cases I'd be pulling in people who don't live on the same > continent. > > So if we're going to talk about misconceptions, let's throw that one > out right away ;) Ok, this is where you are IMHO wrong. You don't get to choose which misconceptions you throw out. The perceptions are there, obviously, or there wouldn't be blog postings about it, and you saying they are wrong accomplishes nothing. The people who have the perceptions aren't reading this or the blogs. Like I said, I'm *not* talking about what the truth is, but what the *perception* is. And these things don't happen for no reason. The misconceptions exist because of various factors, but if django wants to achieve a fantastic dev community on the order of the linux kernel and such like, then the root *reasons* need to be addressed. Rebutting does no one any good. Django is an example of a closed project that was then opened, which has many advantages ( very cohesive code base, clean unified design, already tested, etc ) but disadvantages too. Overcoming the *perception* of closed doors and adjusting dev practices to greater openness being the biggest ones. > 1. The dev list gets an awful lot of traffic from people who should be > mailing django-users instead. I'm not trying to belittle anyone or any > particular issue, but Django seems to get a lot more general support > traffic on its dev list than other projects I've seen. That has a > negative impact on the signal-to-noise ratio of the list. This may be true. However, it's not pertinent to my point, which was that there is not enough discussion *relative to the level of coding going on*. My comments had nothing to do with the signal to noise ratio. As a side note though, I have also seen posts go ignored when a short reply redirecting to say ticket instructions would be better. > 2. The core developers tend to be extremely efficient at using > conferences and other organized events as a way to come together and > discuss/work on Django. Things which would take ages to work out on a > mailing list can be resolved in a matter of hours in a conference room > at PyCon or OSCon, and in fact that tends to happen a lot. Generally, > when that happens people post followups publicly somewhere, though the > followups often appear on blogs; I think that's an acceptable thing to > do. Adrian also does a great job of posting news to the official blog > when appropriate. Ok, on this point, I totally disagree. This is exactly what I mean, that is 100% an example of closed dev policy. There are scads of super smart python developers who might contribute but for very legitimate reasons will never be able to attend conferences. And blog summaries are not the same thing at all as discussion on a dev list. Yes, things get worked out faster in meetings, but at the cost of being out of view, and that really is the rub. Speed vs transparency. You have a choice in FLOSS development, you can choose to close doors and be more efficient, or spend more time to attract more developers and get the payoff of a larger coding base later. It will always cost more in time to attract more developers because it means better documentation is needed and discussions need to take longer. I believe ( and I'm not the only one ) that choosing speed over transparency is not a good plan. If Django as a community feels otherwise, that's their perogative. But they will lose potential developers over it. Fogel has a very thorough discussion on exactly this in his book. If you haven't read it, I recommend it, he makes the point a bazillion times better than I can. > then appears for public discussion. Dev threads pop up when something > hits a snag; several of our core devs are like well-behaved Unix > processes that only print output when something goes wrong ;) Again, I don't that is a good model for *attracting development*. > I guess I'm wondering what exactly we're perceived as not being open > about, and I'd be interested to hear examples; we've got open branches > and some experimental things like Oracle/MS-SQL support going, but > we've been very up-front about the fact that those can't really go > forward without people stepping up to help test and debug them (I've > lost track of the number of times I've said exactly that, on *both* > Django lists). The new forms and the model subclassing stuff have been > discussed repeatedly and at length on the dev list. Well, I guess it's a question of whether the core want to adjust further towards a more open policy. It takes more work, and the payoff comes later. It's the Cathedral and Bazaar thing again, and who the heck runs the Herd? All I'm really saying is that right now the perception exists for a reason that joining django development would be difficult and people lurking and trying to decide whether to work on it aren't near as likely to jump in as they could be. And we need to remember that the goal is not for our team to kick everyones butt, because someone can always come and fork your project. If the code is so good that everyone wants to use it but a bunch of smart people feel that they can't properly get in on the action, they'll fork, and nobody really wins from that. I like Django more than Gears because of the clean cohesive code, makes it easier to get going. But if I were seriously looking for one to develop on, I'm not sure I'd pick Django. And I'm also not sure that I would bet on Django being better than Gears in another few years. Apache took a looong time to really get going. So did the kernel. Now they improve so fast it's ridiculous. I'm sure I have made my point enough though so I'll shut up and go back to web sites. ;) Iain --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
