Julien Danjou, the project technical lead for the OpenStack Ceilometer project, had some choice words to say about github pull requests, which resonates very strongly with me:
The pull-request system looks like an incredible easy way to contribute to any project hosted on Github. You're a click away to send your contribution to any software. But the problem is that any worthy contribution isn't an effort of a single click.
Doing any proper and useful contribution to a software is never done right the first time. There's a dance you will have to play. A slowly rhythmed back and forth between you and the software maintainer or team. You'll have to dance it until your contribution is correct and can be merged.
But as a software maintainer, not everybody is going to follow you on this choregraphy, and you'll end up with pull-request you'll never get finished unless you wrap things up yourself. So the gain in pull-requests here, isn't really bigger than a good bug report in most cases.
This is where the social argument of Github isn't anymore. As soon as you're talking about projects bigger than a color theme for your favorite text editor, this feature is overrated.
After working on OpenStack for the last year, I'm completely spoiled by our workflow and how it enables developer productivity. Recently I went back to just using git without gerrit to try to work on a 4 person side project, and it literally felt like developing in a thick sea of tar.
A system like Gerrit, and pre-merge interactive reviews, lets you build project culture quickly (it's possible to do it other ways, but I've seen gerrit really facilitate it). The onus is on the contributors to get it right before it's merged, and they get the feedback to get a patch done the right way. Coherent project culture is one of the biggest factors in attaining project velocity, as then everyone is working towards the same goals, with the same standards.
There is a popular saying:
If you’re not paying for it, you’re not the customer; you’re the product being sold.
This frames our relationships with Google, Facebook, etc. All those "free" web services that are trading in your data.
But there is a corollary:
If you don't have the source code, and are willing to use it, you're not in control of your future; consumers only have control of the past.
This is a lesson lots of large and small companies and governments have learned. It's been a driving force in the rise of Linux and Open Source in general.
Recently, the new "app economy" has started to get hit by this, as this is a broad new consumption market. The sparrow acquisition by google has been a recent flash point.
Hopefully people participating in the app economy are going to start realizing that it does matter whether or not you have source code, and the right to use it to these apps.
FAIL is over. Fail is dead.
Because it marks a lack of human empathy, and signifies an absence of
intellectual curiosity, it is an unacceptable response to creative
efforts in our culture. "Fail!" is the cry of someone who doesn't
create, doesn't ship, doesn't launch, who doesn't make things.
And because these people don't make things, they don't understand the
context of those who do. They can't understand that nobody is more
self-critical or more aware of the shortcomings of a creation than the
person or people who made it.
I really like the take. It's way easier to be a critic than a creator, and people have found a winning strategy on the internet to just hate things, loudly, and cleverly. It's a pretty easy pattern to use to get fame, but at the end of the day it often just discourages new creation.
If you think something is a fail, look harder. Maybe it wasn't ever trying to do what you thought. Maybe the things that make it interesting are values and capabilities you don't understand or even knew existed. Maybe it has some real warts, but real gems as well. An open mind and the benefit of the doubt leads to much more interesting discovery of information.