Creating successful projects in your community is all about trust, perception, and allies
Why? Because you must create a shared context from which all members in the community can draw. There will still be plenty of disagreements, but everyone will be moving in the same general direction; everyone will be playing for the same team.
I think most people are good people, but easily mislead by a few seeking power and gain. Other leaders seek only to inspire the best in us.
What kind of leader are you? I know what kind I want to be.
Good people can make bad decisions (and often do) simply because of misinformation. This is the oldest, dirtiest trick in relationships, politics, and sales.
If people start saying things just to save face, that's a sure sign that something in your community has gone horribly wrong.
If you find yourself rationalizing draconian policies, chances are your community is suffering from a deep lack of trust. The antidote? Humility.
Discussing things "in the open" is important. But it does not necessarily engender trust in a community, especially in the absence of cognizant moderation.
Unfortunately, open discussions can sometimes lead to a culture of distrust. This happens when individuals in power publicly humiliate, intimidate, or even bully others in the community. Often this happens unconsciously or as a result of a poor choice of words. Regardless of whether the intent is actual or perceived, the damage to the community is the same, and must be quickly dealt with before it festers into a culture of enmity.
As a community grows, so does the likelihood of miscommunication and the abuse of public forums. Therefore, it is only prudent to put in place mechanisms for moderating open discussions, such that they remain positive and constructive.
Community members must hold themselves and others accountable to a high standard of conduct.
Artificially restricting choice is more often detrimental than productive.
I love being part of a team where every voice is heard and valued, whether it be the voice of an application developer, a technical writer, a sys admin, an intern, a senior contributor, a quality engineer, or any other member of the community.
Any creative endeavor of significance is the product of an extraordinary number of ideas; if you want to create world-class products, you have to become incredibly efficient at farming those ideas and crafting them together into something that delights your audience.
Martin Fowler and James Lewis share their thoughts on strict standardization in the context of microservice architectures:
One of the consequences of centralised governance is the tendency to standardise on single technology platforms. Experience shows that this approach is constricting - not every problem is a nail and not every solution a hammer. We prefer using the right to tool for the job and while monolithic applications can take advantage of different languages to a certain extent, it isn't that common.
When asking for feedback from the community, be specific. The broader your question, the more tangents it will spawn in the ensuing discussion, and the lower your signal-to-noise ratio will be.
So, instead of "here is this big huge spec, go read it and let me know what you think", take one small section of that spec at a time, and ask 2-3 pointed questions about it.
Not only will you be more likely to get high-quality feedback using this approach, but you will also hear from more voices, since many people do not have the time to dedicate to reading and digesting a large proposal.
When farming ideas, encouraging more people to speak up with honest, on-topic feedback is exactly what you want.
If you are a community leader, you will subconsciously try to shape the project in your own image. Only by becoming self-aware and bridling this instinct can you hope to farm enough ideas to make your project not just good—but great.
Politics are inescapable and necessary aspects of any community, but leaders must be vigilant to avoid inversions of priority. You don't want to get into a situation where technical excellence and serving the needs of users takes a back seat to political maneuverings.
If you find yourself forced into compromising on the quality and usefulness of your product in order to score political bonus points, your community is in trouble. Healthy communities do not force their members into playing a game of thrones in order to get anything done.
Remember why you are building what you are building, and who you are building it for. Don't mistake the game for the product.
Great leaders excel at farming ideas. They check their ego at the door, welcoming new voices and opinions that differ from their own. They facilitate constructive conversations. Great leaders help their community refine and vet their ideas until the proper solution becomes painfully obvious.
Be careful that you don't let "nobody else does that" become a crutch in your community. When applied judiciously, the phrase can be helpful. However, it can also be abused to cover up a lack of trust and open-mindedness in your group.
What if every time someone shared an idea, they could do so without fear of backlash and bullying? What if people could raise their concerns without being summarily dismissed? What if “seeking first to understand” were a core value in the culture of your community?
We need open minds to build open communities.
Alex Gaynor:
Programming languages are for people. If all the people think the feature is nonsense, the feature is nonsense.
Frank Zappa:
Without deviation from the norm, progress is not possible.
Contribution drives direction. If you want to influence the direction of a project, roll up your sleeves and contribute in a meaningful way. The more ways you contribute, the better. Strive for a mixture of hard (e.g., code, prototypes) and soft (e.g., reviews, designs, ideas) contributions.
Over time, people will come to value your opinion as you demonstrate your passion and knowledge. You will become a thought leader according to your ability to demonstrate good judgment and consistently get things done.
Too often, in our world, someone does something, something extraordinary, and we don't say, "how'd you do that?"
A healthy community has a culture of open-mindedness, by which I mean individuals are in the habit of looking at a problem through multiple lenses. The way you do this is by inviting feedback and moderating constructive discussions.
The ideal process goes something like this:
This process isn't necessarily linear; for complex problems, it is often helpful to circle back several times, reevaluating assumptions as needed, in order to avoid arriving at a local (vs. global) optimum.
If you have a very small community and/or don't have the luxury of being able to participate in realtime discussions, you may have to trick your subconscious into keeping an open mind, and not prematurely narrowing the field of possible solutions. One way to do this is to write down a defense for why you prefer one option over another. This forces you to get outside your own head and broaden your perspective, even if you don't immediately have the opportunity to share your defense with anyone else.
Let's get creative.
Based on my own experience as a developer and manager, coding standards are not necessarily evil (but they can be if taken to extremes). In your career you spend a lot more time reading code than writing it; the primary role of coding standards is to reduce context switching for your brain when reading other people’s code.
The second role of a coding style is to avoid common programming mistakes that happen just because of the way our brains work. It isn’t that we are “dumb”, it’s just that we aren’t perfect.
And, finally, the third role of a coding style is to avoid wasting time on religious wars about silly things, like tabs vs. spaces, and where the curly bracket starts. As a team you agree on something that makes the most sense according to what tools and platforms all the devs are using (e.g., tabs are no big deal for Windows devs, but suck for Linux devs, so just use spaces and/or configure your SCM to do the translation for you).
If you see a problem, and no solution, then create one. Just don't be a hypocrite and not allow others the same privilege.
Use the best tool for the job. Ostensibly identical feature sets can yield vastly different results depending on your personal style and the unique constraints of a given project.
When governing an open foundation or a large company, you must learn to balance the rights and needs of the "federal government" with that of the individual "states". Too much power concentrated at the top, and you squash innovation and productivity. Too little, and your organization wallows without vision and direction.
Every developer and community leader should watch the landmark talk, The Future of Programming by Bret Victor. In his conclusion he talks about the vital link between innovation and culture.
When you learn something new, you can either use it to manipulate other people, or to empower them. You can either share your knowledge or hoard it. Only one of these choices leads to a better world.
Which path will you choose?
When you "agree to disagree" with someone, it probably means that the set of problems you are trying to solve, and the set the other person is trying to solve do not completely intersect.
You can either work together to grow a single solution into something that covers both problem domains, or create two separate solutions. Sometimes the former is not practical. It is often helpful to start with the latter approach and then compare the two side-by-side, factoring out commonalities until there is nothing left to factor. You may end up with nothing left over, but even if you do, at least you have managed to reduce the amount of disjoint code that must be maintained in the future.
In order to collaborate on a solution, that solution must solve both sets of problems concurrently. This may sound obvious, but if you aren't in the habit of "seeking first to understand", it is easy to miss the other person's needs, subconsciously filtering out that which does not happen to intersect with your own mental model.
The best path forward is usually discovered only when you put several heads together in an environment where everyone feels safe sharing their ideas and concerns, and where there is a synthesizing force in place to funnel all of those thoughts into a cohesive plan.
This is the main idea behind the Standardization Manifesto.
"Unwritten tribal knowledge makes common code very frustrating." - paulmo
Miscommunication often masquerades as obstinacy or hubris.
I hate the term "reinventing the wheel". It is a nefarious, fallacious argument.
Case in point: http://goo.gl/1sRwkC
Can you imagine if we had stopped with this design?
