I'm back from PyCon 2007. It was a busy weekend, with 593 Pythonistas attending the conference. I took a fair amount of notes, but I've pulled out some highlights below:
Public school education is so bad that real eLearning solutions can't go to the schools -- they need to be outside of schools so that you don't have the traditional censorship that comes with public schools -- and you don't have the associates with the bad experiences kids have while at "school".
Use good tools. "Open source is better because it's better."
Avoid dogma. Don't get stuck on what language something is implemented in.
Work with (and hire) smart people. The model in open source is that if you're smart, people listen to you. That's rough if you're not smart... But also means that it's worthwhile to mention when you're an expert on a topic.
"Methodologies" suck. Ex., MVC is cool, but Django abuses it because it doesn't fit so well with the web.
DRY -- Don't Repeat Yourself. The one methodology to use.
The business case for open source. You have to make one (to your company.)
Selling open source to other companies. Microsoft's FUD had been quite successful in some areas. Counter the "communist" argument with a "freedom" argument. Focus on the freedom of data -- your data belongs to you; there is no vendor lock-in. Open vs. Lock-in is a better argument then Open vs. Closed.
Create a community. This doesn't just happen because you setup a mailing list. (Gave example of thanking people who post anti-Django blog posts and asking what they didn't like.) Don't say anything that would get you kicked out of a bar.
listen to the community. But smartly. Sometimes the vocal majority doesn't represent the wishes of the whole community. Django's magic-removal was a big risk, driven by the community. You also have to be willing to ask for help. Sometimes you don't feel comfortable delegating tasks that you think suck -- but not everyone has the same definition of "what sucks" -- sometimes there's someone who actually WANTS to do this task!
Handling community contributions. You need a defined method for how you take contributions. It helped the Django project when they adopted a system for differentiating between patches that are controversial, and those that aren't. (ie., simple bug fixes vs. design decisions.) A ticket reviewer makes this decision.
Learn to be comfortable saying 'no' -- there are plenty of Python web frameworks, and maybe someone's needs are better handled by another framework. "If everyone can check in features, you have PHP."