Open Source (Programming)

Projects I should consider contributing to

Anki

http://blog.smartbear.com/programming/1 ... rock-star/

http://stackoverflow.com/questions/4364 ... ce-project
http://stackoverflow.com/questions/2284 ... ce-project

Google Talk: How Open Source Projects Survive Poisonous People
http://www.youtube.com/watch?v=Q52kFL8zVoM
2:00 - They highly recommend Karl Fogel's book "Producing Open-Source Software"
2-3 - They give an overview of four-stages of protection:
1) Comprehension
2) Fortification
3) Identification
4) Disinfection
3 min - They make the point that an open-source project's most valuable resource is the attention and focus of its community (contributing members), and that poisonous people will threaten that resource
3-4 - Poisonous people can 1) distract your developers, 2) emotionally drain your community by squabbling or starting infighting. Some people do this on purpose, others do it accidentally.
4min - OCD / perfectionists / people obsessed with progress can unintentionally derail progress [example: endless discussion]. Remember "the perfect can be the enemy of the good".
5-6min - They tell the "painting the bikeshed" story, which has the MI that the amount of discussion that a group will engage in is inversely proportional to its complexity, because the simpler it is, the more people think they know enough to say something.
7min - They start talking about fortifying.
There are four things they think make a healthy community:
1) politeness
2) respect
3) trust
4) humility
8min - Have a direction and then limit your scope, so you don't end up with limitless feature creeping.
- They give an example from their project "Subversion", where they had a big mission statement on their front page for years, so that anytime someone wanted to add a new feature, they could point to the mission and say "That's a great idea but it's outside our mission". Their statement was "To create a compelling replacement for CVS."
- They recommend that if someone comes up with a feature, you say "Come back after we've finished the stuff on our to-do list".
- They also enumerated at the beginning the exact features they wanted to do and what bugs in CVS they wanted to fix.
10min - They give a second example, from the project "Google Web Toolkit". They started by coming up with a very specific mission statement that would strictly limit the scope of the project. "If you're trying to preserve attention and focus, the best way to do that is to have something to focus on."
11min - The majority of official communication happens on mailing lists [I didn't know that]
- Send new people to the archives to dig through old discussions before starting to talk, because if they don't do that they're disrespecting everyone else's time.
- Don't respond to every message in a thread; it's annoying. Come up with one well-thought out post. And don't let people do this if you're running a project.
13min - Document your project: 1) Design decisions, 2) bug fixes, and 3) mistakes (to avoid having new people repeat them), 4) code changes
14min - They say that the usual way that open-source projects work is that someone will build up trust and get commit access, and then they'll just start committing changes and the other people in the project will just trust that the guy isn't messing things up. There aren't usually code reviews before each commit.
- They recommend having commit emails, and encouraging other members to review those email messages.
15min - Don't let people work on some huge feature on their own and then commit it all when it's too big for anyone to understand how it works. You want everyone to understand how everything works.
16min - Increase the "bus factor" of your code: the lowest number of people in your group who, if they were hit by a bus, could cripple your project.
17-19 - They say that what often happens in corporations and other places is that people will mark off their territory and make other people feel unwelcome about dealing with that part. They recommend that you not allow people to put their names at the top of source-code files. It also introduces politics re: "How much do I need to contribute to get my name at the top of the code?"