This is the first book I abandoned and decided to put out an review. Why? Because the subject matters to me yet, the practical tips do not apply to my current situation.

Building communities is vital in computer science. Every technology I use and love has a great community behind it, and I managed to run some thriving communities over the years. Nevertheless, I have not yet researched how good communities are formed, and this book seemed to be a good starting point.

The book gave me great insides into what a community means. My take from it was: keyword is belonging. People need to few they belong to something bigger than themself.

There are great analogies between communities and the economy in the book. The money of any community is trust, according to the author. To create good communities, we need to create a trusting environment where people can come experiment, contribute, feel they are contributing, and eventually leave.

Communication is the key to belonging, and communication has to be direct and clear. Action wings over abstractions or theory. The leader of any community has to stay humble to create a space where people feel they can contribute and connect.

Use examples to communicate efficiently. Examples are the better way to express experience. The theory is great but be sure to apply them to real problems and share the results of the experiments.

Opportunities are made of belief. Therefore, one’s role as a leader is to believe in the bigger goals and give people the right problems to work towards it.

From the initial part of the book, I got one main question myself. How can I create an environment of belonging in the Nun-db community? This question is still open, but at this point, the question is what matters. The goal is clear. Nun-db has to have a belonging culture. The same applies to the teams I run and the companies I work for.

Planing community

How is it possible to plan a community? Most communities seem to run organically. It turns out that it does not. The author suggests that it is possible to plan how your community will grow and form. He suggests seeking teams for documentation, code, and advocacy.

People with multiple skills can be the glue that puts it all together. As my skills go from Dev, Operation, Architecture to Data Since, and even running my own company, I am usually good at doing the glue work. I believe that is an advantage to me in running communities.

Attracting new people is key. They need to see their contributions in use soon and make sure they get the value of the contributions they are making them. Building a positive environment will help to attract and maintain people contributing.

Passion is what brings people together. The community leader has to see each person’s passion and make sure they are given the opportunities to pursue their passion. Working together means success.

Contributors need to be able to use and enjoy what they are building. It amazes me when developers don’t use or understand the systems they are building. In open source communities, it is pretty clear that it makes a big difference.

When bureaucracy and repetition are more present than enjoyable contributions, something is wrong in the community. That is also true for the comparative work. When merge requests get too hard to complete and need too many steps, things will slow down, and progress will eventually stop.

The to-do list

The book suggests creating a to-do list to plan your community. Some of those steps apply to any team you may need to build.

Identify how we can divide our community into teams?

Think about the boundaries of the community. Here maybe the only difference between a community and a company is that you may want to separate the team by knowledge communities. On the other hand, maybe splitting teams into features-based teams seems to be the norm in companies. Isn’t that the problem? What if we separate teams into technical expertise that would not deliver better results?

Sometimes a few open-source communities work better than most companies. The comparison is unfair since the motivations are usually much stronger in open-source since people normally get together for something other than money. Maybe an open-source-based company is a good hybrid we need.

I find it hard to define roles at this point, I need to see who will get interested in the project first, and I need to make sure I will be able to support people that want to contribute.

Ensure that teams can communicate clearly?

This is so challenging. Communication is the biggest problem in big companies nowadays. I am consulting for companies with +10k employees, and I see how information does not flow well.

It does not surprise me how startups can move fast and create things so much faster than big corporations. I worked three years for a startup in Austin, and it is impressive to see how faster we could communicate and change direction compared to today.

We have many channels of real-time communication. Email and documentation are other great sources of communication. Events and get together are other great ways to connect people, but it is not always possible but help to build synergy in the community.

Today we run an investing community with like 15 friends. We have managed to run this community for over four years now. I blame the ability to get together 2 or 3 days a year to talk about investments, and that is what keeps us feeling like one team. We all benefit from the information we share, and get the community gets stronger and bigger at each event.

Attract a diverse group of people to the project?

This is also needed for both the community and the team. The more diver your team, is stronger it is. Different people think differently and solve problems differently. I have been on multiple calls with people from 3 or 4 continents at the same time, debating one single problem. It is magical how quickly we can come to smart solutions in this kind of environment. Nothing will ever be faster than having everyone in the same room. But having all these smart brains thinking about a problem at the same time and not needing to fly them across the globe is amazing.

We need Rust people that want to learn rust to contribute to the core product, JS people to drive adoption, and documentation people to help up popularize the Nun-db. How to attract them is another question. Maybe going to a conference and speaking to people is probably the best for the moment, not as a speaker yet but attending, and bringing up the subjects.

Building an environment conducive to our shared goal?

What is the common goal? Make Nun-db succeed??? That is probably my goal. Only other people will probably be interested in their own problems I need to find in common.

Produce the code of conduct

I think this is actually a great idea, a code of conduct help to drive the limits of the communication. You don’t want to be too restrictive, but make sure people treat each other with respect and that ideas win because they are better, not because one part was more aggressive than the other.

Conclusion

Great teams are communities, said the CEO of Stack overflow., and I agree 100% that is why I read this book, most of the tips int he initial chapters of the book apply to running successful teams. If open-source projects can convince smart developers to contribute for free, and create great value for humanity, don’t you think companies can learn something from it? I think they do.

Yet I abandoned the book in the middle. It may not be the correct time in my life to finish this book. I like to apply what I read. I have been working as an individual contributor for a while, and I want to continue as an individual contributor for the next years, so I may don’t have where to apply the other parts of this book.

As an observer, I like to understand the problems surrounding me and think about how I would solve them if I were in charge. This book gave me a framework to see some things differently, so it was worth reading it up to this point. I will for sure get back to it sometime in the future, but for now, I need to read something more technical, and hands-on 2022 is almost at the middle, and I need to get some of my plans out of paper, and for that, I need to build some new technical bases, so this is a see you soon book. But I would like to put this post out, so I record how I read this book with the mind I have at the moment. Looking forward to the future me reading this post.

If you run any community of any kind, comparative or open-source, I think the book will be useful, and the author has a fun way of putting the words together. But, on the other hand, if you at the moment are not planning to start or run communities, this may not be a book for you.