open source project newb seeks advice
July 2, 2012 7:08 AM Subscribe
Programming-improvement filter: So how EXACTLY do I get involved in open source projects?
I've been reading some past AskMe's about improving one's programming skills, and a lot of the suggestions have to do with working on some open source projects, both to better one's skills and to build up a portfolio of one's work. I want to take my programming skills to the next level. What I want to know is, how EXACTLY does one go about joining an open source project? I'm a complete newb in this area (open source projects, not programming itself), so please pardon me if the following questions seem stupid. I've only done solo projects while fiddling on my own and small group projects in a classroom setting.
Specifically, please address, if you can
- how does one go about picking the right project? I want to choose a project that is challenging enough that I'll still learn some stuff (shouldn't be hard, I'm not an expert or anything) but not so hard that I'll be completely useless to the project. I am intimidated by a lot of the larger projects. Would there be a way that I could still contribute something to them, or should I start (way) smaller?
- how exactly does one start working on the project, logistics wise? I imagine this will differ project-by-project, as some are much more organized than others. I've checked several websites of some large scale open source projects (and I know those are above my skill level now, I was just checking the format), but this is still not sufficiently clear to me. A step-by-step list, if you could, would be very helpful.
- what is the work flow like? what is the time scale like? Would I be communicating a great deal with others? Would I be familiarizing myself with all the code or would I likely be confined to work on a small, self-contained piece of code? I would love to hear about your experience.
If it matters, I'm comfortable with java, C, and python. In terms of web languages, I have worked with html, css, and php.
Any project recommendations, skills I should pick up, things a newb should watch out for, and other tips from more experienced programmers would be much appreciated. Thanks in advance.
I've been reading some past AskMe's about improving one's programming skills, and a lot of the suggestions have to do with working on some open source projects, both to better one's skills and to build up a portfolio of one's work. I want to take my programming skills to the next level. What I want to know is, how EXACTLY does one go about joining an open source project? I'm a complete newb in this area (open source projects, not programming itself), so please pardon me if the following questions seem stupid. I've only done solo projects while fiddling on my own and small group projects in a classroom setting.
Specifically, please address, if you can
- how does one go about picking the right project? I want to choose a project that is challenging enough that I'll still learn some stuff (shouldn't be hard, I'm not an expert or anything) but not so hard that I'll be completely useless to the project. I am intimidated by a lot of the larger projects. Would there be a way that I could still contribute something to them, or should I start (way) smaller?
- how exactly does one start working on the project, logistics wise? I imagine this will differ project-by-project, as some are much more organized than others. I've checked several websites of some large scale open source projects (and I know those are above my skill level now, I was just checking the format), but this is still not sufficiently clear to me. A step-by-step list, if you could, would be very helpful.
- what is the work flow like? what is the time scale like? Would I be communicating a great deal with others? Would I be familiarizing myself with all the code or would I likely be confined to work on a small, self-contained piece of code? I would love to hear about your experience.
If it matters, I'm comfortable with java, C, and python. In terms of web languages, I have worked with html, css, and php.
Any project recommendations, skills I should pick up, things a newb should watch out for, and other tips from more experienced programmers would be much appreciated. Thanks in advance.
Best answer: I think there's probably as many answers to this question as there are open source projects, but I'll tell you what's worked for me. As background, I live mostly in the Ruby world, and most of my open source experience has been with Ruby libraries hosted on Github. I've also generally worked on things that have a decent suite of tests, which makes contribution much easier.
1. Find something to work on. For me, this is usually a library I'm already using frequently in my own projects.
2. Find the issue tracker for the project. Pick an open bug to work on.
3. Download the source, get your development environment up and running, and make sure all the tests are are passing.
4. Spend an hour or so browsing around the source, getting an idea of the coding conventions and organization of the project. There's so specific goal in this step—just follow threads that look interesting. Keep an eye out for bits of code and tests that may be related to the bug you're going to fix. If the project has a published style guide, make sure you read that.
5. Write a failing test for the bug you're working on and then make the test pass. Make sure all the other tests are still passing too.
6. Submit your fix. Exactly how you do this will vary. If the project is on Github, you can submit a pull request. Otherwise, you'll probably need to generate a patch file and attach that to the issue.
For me, helping out is often triggered by finding a bug or missing feature that's getting in the way of what I'm trying to accomplish. I would definitely recommend starting with something you use frequently, because you'll have a better understanding of the project. I'd also recommend working on something with a decent test suite, because you can be much more confident your code hasn't broken anything else.
When you're first getting started, you can also try to separate wanting to level up your coding skills from wanting to get comfortable contributing to open source. You can always submit test or documentation patches first to get comfortable with the project, then start working on code a little later. Project maintainers will pretty much always be happy to get documentation patches!
posted by duien at 7:34 AM on July 2, 2012 [2 favorites]
1. Find something to work on. For me, this is usually a library I'm already using frequently in my own projects.
2. Find the issue tracker for the project. Pick an open bug to work on.
3. Download the source, get your development environment up and running, and make sure all the tests are are passing.
4. Spend an hour or so browsing around the source, getting an idea of the coding conventions and organization of the project. There's so specific goal in this step—just follow threads that look interesting. Keep an eye out for bits of code and tests that may be related to the bug you're going to fix. If the project has a published style guide, make sure you read that.
5. Write a failing test for the bug you're working on and then make the test pass. Make sure all the other tests are still passing too.
6. Submit your fix. Exactly how you do this will vary. If the project is on Github, you can submit a pull request. Otherwise, you'll probably need to generate a patch file and attach that to the issue.
For me, helping out is often triggered by finding a bug or missing feature that's getting in the way of what I'm trying to accomplish. I would definitely recommend starting with something you use frequently, because you'll have a better understanding of the project. I'd also recommend working on something with a decent test suite, because you can be much more confident your code hasn't broken anything else.
When you're first getting started, you can also try to separate wanting to level up your coding skills from wanting to get comfortable contributing to open source. You can always submit test or documentation patches first to get comfortable with the project, then start working on code a little later. Project maintainers will pretty much always be happy to get documentation patches!
posted by duien at 7:34 AM on July 2, 2012 [2 favorites]
Best answer: 29 ways to get started in open source. (start about 6:00 in) It's from a the recent YAPC::NA Perl conference, but is newbie friendly and rather generic.
posted by zengargoyle at 7:56 AM on July 2, 2012 [1 favorite]
posted by zengargoyle at 7:56 AM on July 2, 2012 [1 favorite]
Best answer: I'm a kernel developer who got started because I found work with a university group that had funding to add support for a new network protocol; so my experience is a bit different since I had my work cut out for me.
I'll take a stab anyway, partly based on experience on the other side trying to deal with new contributors:
"- how does one go about picking the right project? I want to choose a project that is challenging enough that I'll still learn some stuff (shouldn't be hard, I'm not an expert or anything) but not so hard that I'll be completely useless to the project. I am intimidated by a lot of the larger projects. Would there be a way that I could still contribute something to them, or should I start (way) smaller?"
duien is exactly correct. Pick something you personally already care about and have some experience with as a user. That's the most important thing.
Don't worry about size; bigger projects are collections of smaller pieces. You can find your niche in the biggest project.
"- how exactly does one start working on the project, logistics wise? I imagine this will differ project-by-project, as some are much more organized than others. I've checked several websites of some large scale open source projects (and I know those are above my skill level now, I was just checking the format), but this is still not sufficiently clear to me. A step-by-step list, if you could, would be very helpful."
I like duien's advice here too.
The main first step is learning to check out, build, and run any version of the software from source. That lets you figure out where bugs were fixed or introduced, for example. And it's just one step from that to modifying your first line of code and seeing what happens.
"- what is the work flow like? what is the time scale like? Would I be communicating a great deal with others? Would I be familiarizing myself with all the code or would I likely be confined to work on a small, self-contained piece of code? I would love to hear about your experience."
Ideally your first communication would be a contribution, however small: reporting a previously unreported bug, submitting a patch to add some documentation, etc.
You need to make that first step (building from source) on your own based on the documentation.
If you start out saying "I'd like to contribute, what should I do?" you're asking what's actually a pretty hard question of people that have no reason to know whether you're going to follow through.
That said, if you get stuck and make an obvious effort to formulate a *specific* question ("I did steps X, Y, and Z, as suggested in the README, but got this build error....")--definitely ask rather than spinning your wheels forever. It's a fact of life that documentation's always incomplete and/or out of date, so sometimes there's no other option.
It may take time (months or more depending on the project) before you get to know folks and start communicating a lot. That could feel a bit lonely. Finding some local folks as dfriedman suggests may help?
Yes, you want to start with a small piece of the code. On most projects you'll go crazy if you try to understand everything at once.
Bugs are an ideal starting point as they can force you to learn how things work without making you learn the whole project at once.
Spelling fixes or cleanup aren't so great as they allow you to avoid learning the important stuff. Reading code as an end in itself may not be so good either, as it's too passive. If you have to spend a lot of time reading code, at least take good notes.
Try to figure out what the main tools are that other folks use (Source control system? Debugging or profiling tools? cscope? etc.), and learn to use them.
posted by bfields at 8:53 AM on July 2, 2012 [2 favorites]
I'll take a stab anyway, partly based on experience on the other side trying to deal with new contributors:
"- how does one go about picking the right project? I want to choose a project that is challenging enough that I'll still learn some stuff (shouldn't be hard, I'm not an expert or anything) but not so hard that I'll be completely useless to the project. I am intimidated by a lot of the larger projects. Would there be a way that I could still contribute something to them, or should I start (way) smaller?"
duien is exactly correct. Pick something you personally already care about and have some experience with as a user. That's the most important thing.
Don't worry about size; bigger projects are collections of smaller pieces. You can find your niche in the biggest project.
"- how exactly does one start working on the project, logistics wise? I imagine this will differ project-by-project, as some are much more organized than others. I've checked several websites of some large scale open source projects (and I know those are above my skill level now, I was just checking the format), but this is still not sufficiently clear to me. A step-by-step list, if you could, would be very helpful."
I like duien's advice here too.
The main first step is learning to check out, build, and run any version of the software from source. That lets you figure out where bugs were fixed or introduced, for example. And it's just one step from that to modifying your first line of code and seeing what happens.
"- what is the work flow like? what is the time scale like? Would I be communicating a great deal with others? Would I be familiarizing myself with all the code or would I likely be confined to work on a small, self-contained piece of code? I would love to hear about your experience."
Ideally your first communication would be a contribution, however small: reporting a previously unreported bug, submitting a patch to add some documentation, etc.
You need to make that first step (building from source) on your own based on the documentation.
If you start out saying "I'd like to contribute, what should I do?" you're asking what's actually a pretty hard question of people that have no reason to know whether you're going to follow through.
That said, if you get stuck and make an obvious effort to formulate a *specific* question ("I did steps X, Y, and Z, as suggested in the README, but got this build error....")--definitely ask rather than spinning your wheels forever. It's a fact of life that documentation's always incomplete and/or out of date, so sometimes there's no other option.
It may take time (months or more depending on the project) before you get to know folks and start communicating a lot. That could feel a bit lonely. Finding some local folks as dfriedman suggests may help?
Yes, you want to start with a small piece of the code. On most projects you'll go crazy if you try to understand everything at once.
Bugs are an ideal starting point as they can force you to learn how things work without making you learn the whole project at once.
Spelling fixes or cleanup aren't so great as they allow you to avoid learning the important stuff. Reading code as an end in itself may not be so good either, as it's too passive. If you have to spend a lot of time reading code, at least take good notes.
Try to figure out what the main tools are that other folks use (Source control system? Debugging or profiling tools? cscope? etc.), and learn to use them.
posted by bfields at 8:53 AM on July 2, 2012 [2 favorites]
Best answer: I work on a few open source projects for libraries. Regarding picking a project, look for one that includes an aspect that you want to learn (for example, the problem domain, the version control system, the language or its libraries) and one or more aspects that you already feel reasonably comfortable with. If the output of the project is something you already use or would find useful in your other personal or professional pursuits, even better. Best of all is developing a small "itch" to scratch.
If the project has more than a couple people working on it, find out how they communicate publicly (e.g., mailing lists, IRC, or forums) and spend some time reading the archives to get a sense of their expectations and culture. When do you start speaking up, be respectful of folks' time -- while not all open source projects subscribe to the ruder variants of "RTFM culture," showing that you've made an effort to ask your questions in an informed fashion can go a long way.
Don't be afraid to start with a large or medium-sized project -- many large projects actively try to help out new contributors by doing things like providing good tutorials, having friendly experts on the mailing lists, and keeping lists of "bite-sized" bugs for newbies to tackle. As you gain some experience, pay it forward -- there's nothing like figuring out how to answer somebody's question to learn more about the code. Don't underestimate the contribution you could make by writing some really good documentation.
Honor your commitments in a timely fashion -- it's better to be known as somebody who reliably sends unexciting but useful bugfixes than somebody who promises a major improvement but fails to deliver.
posted by metaquarry at 9:12 AM on July 2, 2012
If the project has more than a couple people working on it, find out how they communicate publicly (e.g., mailing lists, IRC, or forums) and spend some time reading the archives to get a sense of their expectations and culture. When do you start speaking up, be respectful of folks' time -- while not all open source projects subscribe to the ruder variants of "RTFM culture," showing that you've made an effort to ask your questions in an informed fashion can go a long way.
Don't be afraid to start with a large or medium-sized project -- many large projects actively try to help out new contributors by doing things like providing good tutorials, having friendly experts on the mailing lists, and keeping lists of "bite-sized" bugs for newbies to tackle. As you gain some experience, pay it forward -- there's nothing like figuring out how to answer somebody's question to learn more about the code. Don't underestimate the contribution you could make by writing some really good documentation.
Honor your commitments in a timely fashion -- it's better to be known as somebody who reliably sends unexciting but useful bugfixes than somebody who promises a major improvement but fails to deliver.
posted by metaquarry at 9:12 AM on July 2, 2012
Best answer: There really is no "joining". It's not like there's a membership list or a signup sheet.1 Contributing to an open source project could mean as little as noticing a bug, coming up with a fix, and sending that fix in the form of a patch to the mailing list. Each project will have its own preferred method of receiving changes (patch tracker, mailing list, pull request, etc.) but that's really the least important part of the process. The main thing is that you've identified something you'd like to fix and you've fixed it.
Identifying the thing to change would ideally come to you naturally because you noticed the bug or lack of feature from your normal everyday use of the code. If you're not a user of the project, it's hard to appreciate where it might have bugs or need improvement. I always get a kick out of these questions because it's like, wow, you must really have it well off if you have to go out hunting for bugs. Most developers find them naturally just from their day to day interaction with software. You can always trawl through a bug tracker looking for things to work on, but be sure that you can reproduce the bug before doing anything else, and make sure you understand why it's a bug, or if it's a feature request, understand what's being requested and why.
The down and dirty of actually figuring out what's causing the bug and how to fix it should be where most of your time goes. Debugging can be hard, but it will pay dividends in the form of sharpened skills and better familiarity with the project. I have to caution you however that most open source projects are not interested in training people how to code. You should be self-motivated to learn on your own. Asking the mailing list is fine, but keep it to questions specific to the project -- how to set up a build environment, etc. Nobody has time to teach you the ins and outs of whatever language the code is written in, and that's one of the reasons that "just contribute to open source!" is not exactly top on my list of things to recommend to people trying to learn a language.
When you're finally ready to contribute the fix, just make sure to hang out on the mailing list long enough to pick up the culture. There will be a specific way that things are done, including coding conventions, style guides, patch formatting, commit logs, bug trackers, etc. All of that depends on the project, but all of it can be learned by just lurking for a while and seeing how it's done. You might have to go a few rounds if your patch doesn't work for technical or stylistic reasons. That's pretty normal. It can require some patience, so don't despair if you don't hear anything immediately. Sometimes patches languish for a long time before anyone with the appropriate rights can review and commit for you.
[1] Some projects require contributors to sign a legal document assigning copyright of any contributed work to the project, so in some circumstances there is a sign-up process of sorts. But this is very much the minority and you aren't likely to run into it.
posted by Rhomboid at 9:20 AM on July 2, 2012
Identifying the thing to change would ideally come to you naturally because you noticed the bug or lack of feature from your normal everyday use of the code. If you're not a user of the project, it's hard to appreciate where it might have bugs or need improvement. I always get a kick out of these questions because it's like, wow, you must really have it well off if you have to go out hunting for bugs. Most developers find them naturally just from their day to day interaction with software. You can always trawl through a bug tracker looking for things to work on, but be sure that you can reproduce the bug before doing anything else, and make sure you understand why it's a bug, or if it's a feature request, understand what's being requested and why.
The down and dirty of actually figuring out what's causing the bug and how to fix it should be where most of your time goes. Debugging can be hard, but it will pay dividends in the form of sharpened skills and better familiarity with the project. I have to caution you however that most open source projects are not interested in training people how to code. You should be self-motivated to learn on your own. Asking the mailing list is fine, but keep it to questions specific to the project -- how to set up a build environment, etc. Nobody has time to teach you the ins and outs of whatever language the code is written in, and that's one of the reasons that "just contribute to open source!" is not exactly top on my list of things to recommend to people trying to learn a language.
When you're finally ready to contribute the fix, just make sure to hang out on the mailing list long enough to pick up the culture. There will be a specific way that things are done, including coding conventions, style guides, patch formatting, commit logs, bug trackers, etc. All of that depends on the project, but all of it can be learned by just lurking for a while and seeing how it's done. You might have to go a few rounds if your patch doesn't work for technical or stylistic reasons. That's pretty normal. It can require some patience, so don't despair if you don't hear anything immediately. Sometimes patches languish for a long time before anyone with the appropriate rights can review and commit for you.
[1] Some projects require contributors to sign a legal document assigning copyright of any contributed work to the project, so in some circumstances there is a sign-up process of sorts. But this is very much the minority and you aren't likely to run into it.
posted by Rhomboid at 9:20 AM on July 2, 2012
Best answer: I haven't used it myself, but I've heard that OpenHatch is a good resource for people interested in contributing to open source projects (particularly Python).
The Drupal community is also pretty great at welcoming newcomers. See this page for some tips. They have something called "IRC Office Hours" that are for helping new contributors get started.
posted by tavish at 11:41 AM on July 2, 2012 [1 favorite]
The Drupal community is also pretty great at welcoming newcomers. See this page for some tips. They have something called "IRC Office Hours" that are for helping new contributors get started.
posted by tavish at 11:41 AM on July 2, 2012 [1 favorite]
Best answer: I'm a member of an open source project. I got involved because I used the project heavily for work and found some bugs, so rolled up my sleeves and fixed them myself. I think that's the way most people get involved, certainly jives with the stories here. You should pick something you use already. If you don't use it yourself, you're not going to have much perspective for the work. If you use something and it has bugs you find troublesome, or is missing features you would like, that's a great sign of an opportunity for you to get involved, and you'll actually reap the fruits of your labor directly instead of just as resume fodder.
I will second what everyone else says for step one, you need to figure out how to check out the code, compile it, and run the tests on it before you can successfully contribute. Also, you should get very familiar with the documentation and mailing list for the project. One of the main things that I contributed to the project early was mailing list participation, mostly through answering questions. There are certainly projects that you can participate in without knowing enough to answer questions about the project, but it's really hard to be a member of a community for a project you don't use yourself well enough to help others with it.
When you want to contribute, if they have a website with details on how to contribute, read it. Creating a tracker and submitting a patch or pull request is pretty worthless if you don't follow the community standards for testing, formatting, etc. You want to start with SMALL fixes. If you try to refactor the whole project as your first patch, prepare to be ignored. Someone has to code review your fix, and it's easier to build trust in abilities with smaller fixes before tackling very nasty bugs or big features. You don't have to know the whole code base, but you should feel good about the parts you are working with.
A good project will have a lot of communication. Comments on JIRAs, mailing list traffic, IRC channels, etc. In my observation, it's a bad sign if a project has very little active participation. If you can get involved in the community around the project before submitting patches etc, I think that is generally a good thing. Open source software is all about distributed development, and that is really all about trust.
Don't expect things to move fast. You may submit a patch or pull request and have to ask a few times before one of the project maintainers has time to review it for you. If they don't look at your patch the first time, a gentle nudge in the form of a comment or polite email is a good idea. Be patient but persistent. People are really busy and most of them have day jobs in addition to their OS work. You're an unknown participant at this point. You have to build trust, and it takes time. I think that I started on the OS project I'm now a core member of back in the summer of 2010, first bug fixes that fall, and was promoted to committer in the spring of 2011. This is for a fairly established project so smaller, newer efforts will probably move faster.
Good luck, and have fun! This isn't an extra curricular activity that you must undertake to get into college. Do it because you care about the project and you want to participate. Otherwise it really isn't worth the time.
posted by ch1x0r at 6:28 PM on July 2, 2012
I will second what everyone else says for step one, you need to figure out how to check out the code, compile it, and run the tests on it before you can successfully contribute. Also, you should get very familiar with the documentation and mailing list for the project. One of the main things that I contributed to the project early was mailing list participation, mostly through answering questions. There are certainly projects that you can participate in without knowing enough to answer questions about the project, but it's really hard to be a member of a community for a project you don't use yourself well enough to help others with it.
When you want to contribute, if they have a website with details on how to contribute, read it. Creating a tracker and submitting a patch or pull request is pretty worthless if you don't follow the community standards for testing, formatting, etc. You want to start with SMALL fixes. If you try to refactor the whole project as your first patch, prepare to be ignored. Someone has to code review your fix, and it's easier to build trust in abilities with smaller fixes before tackling very nasty bugs or big features. You don't have to know the whole code base, but you should feel good about the parts you are working with.
A good project will have a lot of communication. Comments on JIRAs, mailing list traffic, IRC channels, etc. In my observation, it's a bad sign if a project has very little active participation. If you can get involved in the community around the project before submitting patches etc, I think that is generally a good thing. Open source software is all about distributed development, and that is really all about trust.
Don't expect things to move fast. You may submit a patch or pull request and have to ask a few times before one of the project maintainers has time to review it for you. If they don't look at your patch the first time, a gentle nudge in the form of a comment or polite email is a good idea. Be patient but persistent. People are really busy and most of them have day jobs in addition to their OS work. You're an unknown participant at this point. You have to build trust, and it takes time. I think that I started on the OS project I'm now a core member of back in the summer of 2010, first bug fixes that fall, and was promoted to committer in the spring of 2011. This is for a fairly established project so smaller, newer efforts will probably move faster.
Good luck, and have fun! This isn't an extra curricular activity that you must undertake to get into college. Do it because you care about the project and you want to participate. Otherwise it really isn't worth the time.
posted by ch1x0r at 6:28 PM on July 2, 2012
Best answer: I'd echo people who say find a project you're interested in, find an open bug, fix it and submit a patch. I would suggest doing this on Github just because it makes the whole thing easier.
If there's a feature you want in something you use, even if it's a small tweak, that also makes a good first patch.
My first open-source commit to an existing project, a three-line edit to a low-profile project on Github, resulted in a contact from a recruiter a week later. I wasn't looking for a job at the time, but it's surprising the ripples that even a small effort can throw off.
posted by 23 at 6:51 PM on July 2, 2012
If there's a feature you want in something you use, even if it's a small tweak, that also makes a good first patch.
My first open-source commit to an existing project, a three-line edit to a low-profile project on Github, resulted in a contact from a recruiter a week later. I wasn't looking for a job at the time, but it's surprising the ripples that even a small effort can throw off.
posted by 23 at 6:51 PM on July 2, 2012
Best answer: I maintain a number of open source projects connected to OpenStreetMap and geographic data. I’ve accepted numerous small patches from contributors via Github, and I usually greenlight them after a brief review. Small patches are best because they’re easy for a maintainer to understand, and also help build up trust over time. If someone sends me a deep rearchitecture of some critical component out of blue, I’m probably not going to accept the patch. Generally the helpful contributions get submitted to scratch someone’s itch for a particular feature.
An alternative model I’ve seen work well was getting involved at the documentation level. A good friend with minimal programming experience joined a project he used heavily by fixing documentation, answering user questions, and generally being helpful in a secretarial/administrative capacity. He built up a great deal of trust with the reclusive, overextended creator of the project and over the years has built up a substantial reputation as a primary author and become an accomplished C++ developer with excellent knowledge of building on deployment on a variety of systems.
posted by migurski at 9:47 PM on July 2, 2012 [1 favorite]
An alternative model I’ve seen work well was getting involved at the documentation level. A good friend with minimal programming experience joined a project he used heavily by fixing documentation, answering user questions, and generally being helpful in a secretarial/administrative capacity. He built up a great deal of trust with the reclusive, overextended creator of the project and over the years has built up a substantial reputation as a primary author and become an accomplished C++ developer with excellent knowledge of building on deployment on a variety of systems.
posted by migurski at 9:47 PM on July 2, 2012 [1 favorite]
This thread is closed to new comments.
If you're not in an area with such meetups, go to stackexchange or a similar site and ask the same questions you ask above. Another resource is Quora.
And, I'm sure others here will also have suggestions.
posted by dfriedman at 7:13 AM on July 2, 2012