This post that was initially conceived, and partially written while I was a part of Keen IO. I have since left the company, but I thought that these lessons were worth sharing so, I decided to finish it
Community, to put it in a single word. I think it’s important to make the distinction between what community means to the company, as a whole versus what it means to me, on a personal level.
The Cult of Open Source
One of the most radical ideas empowered by the ability for people to work on fixing and improving existing and established codebases asynchronously has been a defining paradigm of the whole coding movement. It allows us to work towards a common goal, leveraging our own individual skill sets and abilities to accomplish something that would be impossible for a single individual, and in some cases an entire company. The only cost is time, and rewards are knowing that you’ve imprinted a part of yourself in this giant organism, i.e., the product.
On a personal level, I’m a relatively new to programming on a professional level, having only coded professionally for slightly over a year now. I have a lot to learn, and a long way to go to becoming a proficient programmer. In the book, “The Fundamentals of Chess”, the author says, “You only get better by playing a better opponent”. Borrowing from this idea, in the current context, this means that I can only improve my own skill sets by working with people who are better than I am at what we do and open source is my gateway to those people. A lot of my success in terms of contributing to the open source projects has stemmed from the fact that I have the luxury of learning from those better than myself, but it’s more than just my personal success, it’s the success of everyone that makes an open source project what it is and that’s where community comes in. You build a community that fosters openness, and growth and soon you have an army of amateur programmers who, through patience and understanding, eventually become the experienced ones capable of passing on their knowledge and experience to those starting out, and so the cycle continues. In the instances where it works, it’s worked brilliantly, and in the instances where it hasn’t, has ultimately come down to weakness within the community. In fact, one of the defining principles of a fostering community is the necessity of having a strict code of conduct, to prevent those with malicious intent from disrupting the group.
In the few projects that I have contributed to, I’ve learned so much, a lot of which makes me a better developer. Specifically, in terms of processes, which become very important in order to be able to coordinate on such a large scale. Understanding how to write appropriate commit messages, and when and how to squash commits so that your commit log is clean and understandable makes life a whole lot easier for people to figure out what you’ve done and why. In turn, this makes it easier on newer folks to understand your flow when addressing an issue, or when trying to work on a new feature enhancement.
It’s hard to get a sense of how proficient you are as a developer without having someone review your work. Mostly these provide a second pair of eyes to find flaws, common mistakes or just identify bad habits that every developer tends to pick up, such as falling into the trap of perfectionism and endlessly trying to refactor code. Things like these happen even to the most experienced of programmers, so recognizing them and taking steps to correct them early on becomes vital. Contributing to open-source projects provide exactly that type of growth to an early stage developer. Even just going through the codebase and working out the application’s architecture can give a lot of insights into the principles of good design.
In terms of a company, working at Keen IO, this is what we want to achieve, the idea that we can foster and encourage a community of smart, experienced folks who pass down their experiences and knowledge to the less experienced. To us, this not only brings us closer to the community and the people who use our product, it also empowers our developers to give back, and make ideas, improvements and suggestions that benefit not only the product but in the end, the developers using our product as well.
Part of this commitment towards the open source community is to help out other communities as well, and our first focus so far has been the blogging platform Ghost. Ghost in itself is firmly rooted in the culture of open source, the brainchild of John O’Nolan and Hannah Wolfe, and soon after their blog post the product was born. The basic idea behind their vision was to create a product that would overcome the shortcomings of Wordpress, which was (and some would argue, still is) the best blogging platform at the time. The issue, however, was that Wordpress became too heavy, inundated with features that broke away from the core use case, blogging. Since its inception, Ghost has become one of the most popular Github repositories, with a massive community behind it. They host weekly Slack discussions, discussing the future of the product, allowing the other developers and users to chime in on the features, issues or ideas to be included in the next build of the platform. These discussions are where I found my footing, as well.
As the saying goes, “If you’re the smartest person in the room, you’re in the wrong room”. Well, I was most certainly in the right room. I started off as a fly on the wall, carefully trying to follow the conversation, lurking, so to speak within the channel. I finally found the courage to actually ask a question and to my amazement I found a genuine, polite response. Specifically, I introduced myself as a novice and asked them to help me find some issues suited to my skill level. Things moved forward quickly from there, and within a week, I had submitted my first PR (pull request).
Ghost has a lot of lessons to give to the rest of the community. It’s managed to create and foster one of the largest developer following of any platform while still maintaining its integrity and approachability. Its weekly discussions allow the community at large to weed out unnecessary features that deviate or bloat the platform from achieving its very specific goal. These are the lessons that we’re trying to learn at Keen IO, ones that will make our product even better while still being able to give our users the best possible experience. In a space where technology companies are a dime-a-dozen, it’s the users that really make all the difference.