The folowing is my personal opinions about joining or entering an Open Source Community. There are other versions of this, but this is my first pass.

Introduction

More often than not, I get exposed to companies or people who want to engage with different Open Source communities. This can range from Enterprise Developers to Startup CEOs to New Developers who are just starting their careers. Each of these personality types has challenges or confusion on how even to start, and they come to ask me. In this post, I’ll give some pointers that fit some general assumptions of these people and hopefully help them gain the successes they are looking for.

At the very beginning of these conversations, it’s pretty quickly realized that there are some preconceived ideas of how Open Source communities work; or strong assumptions on how they could just show up and help make things they are looking to get out of the project happen fast. Hopefully, after reading this, you’ll have some understanding that it’s not as simple as you and they might expect, and be prepared for some real work ahead.

Everyone has been part of some level of the playground or schoolyard in their life. Whether you went to a school or home school, it doesn’t matter; you’ve most likely engaged in a park playscape before. It’s important to recognize that environment before going any further because there are many parallels between that and how Open Source communities are run.

With a playscape and children playing and interacting in your mind, take it one step farther and imagine an adult cocktail party; what is a cocktail party but the same environment but with adults, and imagine that child who was on the swing. They are now an adult sipping on a martini and thumbing through the LPs by the record player. You might imagine another child playing with sand and building sand castles; instead, they are now telling a grand story about the time they trekked through Europe.

Now simply said, Open Source communities are this cocktail party. Of course, not every community is exactly this, more are like that playground from earlier, but the more you start looking at how Open Source communities interact, the closer you’ll see how they really are just cocktail parties. So, let’s examine these closer, from the view of 3 different general personality types.

New Developer

New developers can come in all different shapes and sizes, young and old, but they are (normally) very hungry to learn. This should be cultivated and engaged with; they are the new generation, and we need them. But this comes with a possible cost that causes friction if not interacted with correctly. There is a concept called the Dunning-Kruger effect, that to quote Wikipedia:

The Dunning–Kruger effect is a cognitive bias[2] whereby people with low ability, expertise, or experience regarding a certain type of a task or area of knowledge tend to overestimate their ability or knowledge.

Which can run rampant through the Open Source communities. A new Developer can come in thinking they know everything around a project, what language(s) are the “best,” and “why are you using this ‘old’ software?” type questions. They want to re-write everything in the “new” system, throwing away the “old” way of doing things.

Understandably this can cause friction and pain for the established Developers, and the new Developer won’t make any friends. In situations where I’ve seen this, there has never been a straightforward answer; but defaulting to trust in this new Developer is really the only path to success. Putting yourself in their shoes, exciting engagement, and green field learning can cause this, and they have identified things that could be wrong or that need help, but the vector they are coming in on is what is causing the problems. Have a frank and straightforward conversation with these humans, and work with them, and if they stick around, great!

Enterprise Developer

When the Enterprise Developer comes to an Open Source community, it’s usually because some massive corporation has decided one of two things. They either need to be good Open Source Citizens, which happens relatively often, or they realize that a critical portion of something they use needs someone paying attention to it. Think the log4j issue or the heart bleed CVEs, they need their voice in a dependency they use, and the only way is to assign someone to join the upstream community.

From my interactions, you can normally tag an Enterprise Developer from a mile away; they had been spending so much time in their inner source projects they forget that communities do things differently. They make assumptions about what and how things are done; they expect the same tools or processes, not understanding that the resources they have or use are no longer available to them. On the flip side, sometimes, they can’t use the toolchains the community had agreed to use, due to security policies or any other level of bureaucracy, causing only long-term heartache for both them and the community they are trying to join.

The best analogy is the person who shows up at the party who does not understand that theme or vibe or does not know the audience. They might bring or expect something at the party, not realizing it’s completely different. For instance, you’ve decided to have a wine tasting, everyone brings a bottle of wine within some parameters, and they bring a keg of beer; needless to say, that’s not what the party was aiming for and shows that they don’t understand the audience. They normally have the most challenging times adapting to be successful new members of these communities.

As easy as it is to say be nice and engage, I’ve seen so many failed times of frustration. The Enterprise Developer needs to find it within themselves to work in the new community paradigm. Normally these Developers have some level of support structure internally, so hopefully, they will engage there learn how to develop and play in an accepting environment and become productive. Unfortunately, this doesn’t happen very often, but when it does, you have a member who will be around for a long time.

Startup CEO

The Startup CEO is normally the personality trait that feels like they can just walk into a place a “buy” what they need. Normally this isn’t directly correlated to paying the Open Source community money but could be paying for the bar tab at a meetup or swag, like t-shirts, stickers, pens, or stress balls for everyone. They believe they can influence the project by using their purchasing power and build what they want or need for their downstream project if they spend enough money. Mind you, this isn’t just the Startup CEO; this can be a company too, but normally the Startup CEO does this over and over, compared to a company that does it at most a couple of times a year.

This is a good mirror to that one person at the cocktail party who brings the expensive alcohol or buys themselves into the party but doesn’t engage with the larger group. They might walk in and put something down but expect people to come to them. They spend their time being a spectacle, not learning the vibe or the way the community interacts, expecting that they come with the cash the community should do what they want. I should say that this is a greyscale of personality types, but the worst and best of these people expect and leverage their cash to be their main motivator without putting in the leg work. Take that image and imagine the Open Source communities doing it repeatedly; eventually, they’ll realize that they get little to no engagement and frankly wastes everyone’s time.

Seeing someone like this come in, be polite, find out what they are trying to do, and see how feasible it is to happen. That simple engagement often falls through the cracks and can short circuit many wasted hours. There’s nothing wrong with a bar tab picked up, it’s amazing how many times at conferences or meetups, more of the actual work and networking happens at the bar compared to the talks. Having a sponsorship for a safe and engaging environment is the lifeblood for face-to-face Open Source communities, but be fore warned, sponsorships always come with strings attached.

Conclusion and where to go from here

If you’ve read this far, first off, thank you. I should clarify that these are my opinions, but they are berthed from consistencies I’ve seen; in conversations with people from the different Open Source communities and the actual personality types. These aren’t the best or correct ways to engage, or maybe some of these ways you should not engage, but it’s just a general warning. The best thing you can do is spend the time and effort to understand what these personality types want to happen and learn their motivations. Before you know it, you’ll be interacting with these new members of your community in a positive light, being able to spend time with them and build something amazing. This will not only make you stronger and a better Open Source community member, helping grow that project you want to be a part of.