Open source is where true innovation happens. There. I’ve said it. The free exchange of ideas, the creative juices that comes from open source and open source communities is unparalleled in proprietary businesses and software. So now that’s out of the way, let’s talk about what open source is and the advantages it can bring you and/or your business, and then we’ll talk about the core pieces of building communities.
The Open Source Initiative defines open source as:
“software that can be freely used, changed, and shared (in modified or unmodified form) by anyone” (source)
At last month’s Open Source Summit in San Francisco, the Executive Director of the Linux Foundation, Jim Zemlin, shared the following stats:
- 23 million open source developers worldwide
- 22 million accounts and 64 million repositories on GitHub
- 41 million lines of code
- 1,100 new open source projects every day
- 10,000 new versions of open source projects every day
Jim continued with the following statement:
The Linux Foundation@linuxfoundationZemlin: Today, nobody makes anything without open source. It’s a fact of how modern development works. #OSSummit16:09 PM - 11 Sep 2017
While that is a seemingly broad, subjective statement, I do believe it holds some merit. It is almost impossible for anyone to develop something without using something that is open source in one fashion or another, whether that be a library, an IDE, or as the base for their product. In addition different licenses allow for different ways of using the code, and is a whole other long, drawn out discussion to have at some other time.
Open source presents many opportunities for independent developers and companies, along with many savings — and not just monetary. As a company project/product manager you don’t need to reinvent the wheel by taking your idea and starting from scratch, when more often than not someone else had your core idea or implemented a portion of it and you can take it and use it for yourself. Standing on the shoulders of those who have come before you is a time-honored tradition within open source. By using what others have done within your idea you can shift developers to working on your core product in a place that’s likely further along in your timeline.
Another opportunity is around a potential lower cost to adoption. Depending on where you are in your implementation, you can lower the upfront costs to begin implementing your idea. This allows you to shift costs from purchasing/licensing proprietary software to customizing and then implementing your core product.
Open source projects often carry with them the virtue of being developed by distributed contributors which means they often are unbridled by internal policy and other factors. This all but translates to modern ways of working , allowing your team or project to take advantage. With everything being electronic, from issues to commits, and developed in the open, this brings about a level of transparency and intentionality to activities that can only benefit you and your project. With many different contributors to the core open source projects you may be using, multiple activities tend to be happening at once with testing being done by multiple parties at any given time. Throw in modern CI/CD tools like Gitlab, Travis CI, and others, and many of the above can be automated during your development cycle, thus ensuring that the code you’re using is alive and well.
Open source is all around us. Heck, with traditionally proprietary companies like Microsoft and Apple open sourcing their primary development environments (Visual Studio Code and Swift respectively), it isn’t hard to understand why open source participation continues to grow. In the mobile world, Android has exploded in large part due to its open source roots, and Ubuntu in the desktop world has benefited as well. Open source is the past, present, and future!
Keeping software up-to-date is essential to ensuring that bugs and security issues are mitigated as quickly as possible and limiting the effect to the public. However, when you’re relying on a proprietary software company to provide updates, you’re at their mercy in when they decide to deploy them. A great case in point would be buying a Google phone (Nexus or Pixel) as opposed to something from Samsung or HTC: you’ll get faster software updates as you’re not bridled by the OEMs need to modify everything. And we’re not even adding carriers into the mix. Often these proprietary companies don’t feel the same urgency that you do, even though the software may be mission-critical to you and your business. With open source software you’re able to either contribute the fix yourself, or pull the fix down, and patch your code on your schedule. By contributing the fixes upstream you’re illustrating the positive lifecycle that happens in open source, thus providing benefits for you and everyone else — meaning everyone wins!
We’ve all seen terms like “FOSS”, “Libre” — which all refer to free, open source software. The term “free” does not necessarily mean that the software is without cost — sometimes it is, sometimes it isn’t. What “free” more refers to the rights that the software offers to the consumer by default, with the monetary cost being something subjective to the respective developer/organization. For instance, software like Adobe Flash or Internet Explorer can be freely downloaded but is completely non-free proprietary software.
Actual free open source software (FOSS) refers to 4 core freedoms:
- The freedom to run the program as you wish, for any purpose ( freedom 0 ).
- The freedom to study how the program works, and change it so it does your computing as you wish ( freedom 1 ). Access to the source code is a precondition for this.
- The freedom to redistribute copies so you can help your neighbor ( freedom 2 ).
- The freedom to distribute copies of your modified versions to others ( freedom 3 ). By doing this you can give the whole community a chance to benefit from your changes. Access to the source code is a precondition for this.
When software is not FOSS, you have a high potential to welcome risks as a user as it’s developed in private and the publisher alone controls it. This is where we have a higher risk of spying, theft, etc. FOSS places the power back into the hands of the user and ensures that users can control the software they use, not the other way around.
Open source software is also like the “give-a-penny-take-a-penny” philosophy of software. If you use the software, whatever it is, there is an implicit obligation to give back to the community. Think of it as the Golden Rule applied to software. Some might remember the early Shareware models for software “back in the day”. Typically in the license for the software, which often was actually distributed on floppy disks between friends or on BBS’s, would be a clause which stated that you were able to share the software (hence “shareware”) with anyone, and if you found it useful and wanted to continue to use it you would need to send some amount to the developer. This has changed over time with the onset of different software licenses and online software repos like GitHub, but in the 1980s this was the norm.
Open source software projects tend to naturally facilitate community, whether something intentional or not. The Open Source Initiative has the following to say:
Whether it’s development or advocacy, open-source software and other collaborative projects benefit through, and because of, community. Unlike with traditional projects that require physical resources, sharing economies are generally only hindered by the number of people contributing to an effort and their ability to acquire and share knowledge.
Oftentimes some of the most successful communities end up being accidental as the environment happens to be right, similar to how some things just grow without any specific care given.
Quite a few years ago, when my wife was pregnant and had come home from a brief stay in the hospital, I was a bit frustrated at not being able to really do anything, so I went outside to make myself useful. In our backyard it seemed a small jungle had transplanted itself from the Amazon, and so I set about attacking the problem. A little while later, as I was tearing into a particular section, I noticed something large nestled in the weeds. Upon further investigation I was shocked: it was a watermelon. Make that TWO watermelons. I plucked one (a good size actually — and a bit too early we would find out) and took it into my wife, feeling every bit the part of the proud farmer. We racked our brains trying to figure out how this had happened, and recalled how my family had been over earlier in the year and we had eaten watermelon, and had a seed-spitting contest into that very location in the yard. It seems this was a particularly fertile spot and a few seeds had taken root. To this day, that area of the yard still yields some fantastic vegetables, but nothing matches the sheer joy at finding these two watermelons.
Sometimes communities just happen. The responsibility of the Community Manager is to water it and make sure the ground has the nutrients necessary to facilitate growth. You likely won’t know what the outcome will be, but for me that is part of the excitement of community. Nothing happens though unless people participate.
That being said, it is important to be intentional in your software project, making it easy for developers and contributors to join and get involved in the community. Every obstacle should be removed so that someone is able to move from reading about your project/community to signing up to then being put into a position where they can contribute as quickly as possible.
A community is generally defined as a group of people with unique:
I won’t go too deeply into the more foundational steps of starting a community, but I do want to mention them as I feel they are important. When starting a community these steps consist of things like Structure, Environment, Processes and Procedures, etc. For a more indepth look I encourage you to check out Jono Bacon’s Art of Community which lays out a lot more of the steps needed in the early stages, things like mission, vision, meritocracy, etc.
Feverbee, a community-consulting firm, set out to identify a typical community’s lifecycle, and came up with:
As your community makes its way through the different stages, you’ll find yourself taking steps and/or performing tasks as part of that stage and which also will move you along to the next stage.
When you’re starting your community, you’ll be inviting members to join, creating discussions and getting participation in them. Relationship-building is an important part here and you’ll need them in order to keep the community viable and give you the foundation needed to sustain it.
Content, content, content. Add to that events like hackathons, conferences, meetups, etc. and you’re helping to establish the community. You, or someone who eats/sleeps/breathes it, will need to delving into the analysis of stats about the community, and deal with conflicts and disputes (this is the Internet after all). All of those things come about as your community becomes established. During this time though it is important that you don’t forget processes and procedures — they’re important at this stage in order to set your community up for success. But don’t become too serious here, or else you’ll snuff out the excitement being generated by being overly managerial. Sometimes this can feel like the most tedious time, and you really have to be careful to avoid mood swings between “ERMAHGERD! THIS IS AMAZEBALLS!” and “I JUST BROKE THE INTERNET!” But trust me — it will get better.
The community will (eventually) reach a stage where it’s influence will grow, and along with it an influx of volunteers. These volunteers will jump in and their passion will fuel growth — it’s important here to make sure you delegate. During this time you’ll also be streamlining goals and vision with the help of the community, whose members will now start to display a strong sense of ownership and will make the community their own.
When a living cell splits into a new nuclei, or in the case of a community forms more-focused sub-groups or teams, you’ve reached mitosis. This is a very important step and should be welcomed. Because communities are unique and have their very own DNA, they really can be thought of as organisms. Organisms are both, they grow, they mature, and then they split and replicate themselves elsewhere. It’s natural, and if this isn’t happening, then you may very well be at a final stage in the lifecycle not usually addressed.
Death. It is natural. Sometimes a community will die on its own. Sometimes it will need to be laid to rest. And sometimes, after mitosis happens, the original community will just be replaced by the new one. It happens. It’s natural.
Everything that happens in a community needs to be done with transparency and openness as the default. Not only are they the hallmarks of open source, they are essential for building trust in community. There are a few great examples of communities that operate this way, with the Ubuntu Community and Gitlab being the best in my example. From the very onset of both, they have strived to be open with their direction and decision-making. It requires a conscious decision and will go a long ways to building trust which is vital for success. It also helps to level the playing field, making sure that everyone in the community knows that all have a role to play, and each are just as important and needed as the next person. There are many ways to achieve this, from using wikis to store documents and procedures, to using GitHub/Gitlab issues, IRC, Slack, and the list goes on.
Communities are just as generational as families, and you will typically see the lifecycle reflect something very similar to the below. There is no pre-determined time frame that someone might spend in each role in the community before they “upgrade”. Some will move very quickly through some or all, whereas others might consistently plod along.
“If you can enable an environment in which people can share, they will and the benefits will entice others to join.” -Susannah Fox, Medicine 2.0: Peer-to-peer healthcare, Beacon #3
It is important to not restrict people from benefiting from the community without registering ( Lurker ), e.g. free downloads or being able to read posts. It is good to require signing up in order to participate though as it shows intention and desire to enter the community ( Novice ). The next step could come quickly for some, or longer for others, where they actively start participating and reach a level as a Regular member. This would typically see them participating more, contributing new content or helping support others. Eventually you will start to see Leaders begin to emerge from the ranks, and it is a good thing to recognize this early and engage them. Give them something to do, let them take ownership, or else you run the risk of losing them. You’ll know a leader in the community as they’ll be the ones embodying the spirit and vision and values of the community, and will be the standard for what it looks like to truly participate. Not everyone is able to spend a consistent amount of time though in the community, and after awhile you will have Elders who will emerge and they tend to be those who are on their way out, usually due to things like job, family, lack of interest, new stage in life, etc. They often will impart sage advice to a situation, or provide suggestions, and when they talk, people will listen. But they also just aren’t as active anymore. You could see them as the elders in a tribe who are nearing the end of life in said tribe (not nearly as morbid as you think). It’s important to get their feedback on how things are going, but you will need to know that they likely don’t have the same passion or time as before.
For further reading on the topic of communities, I have listed some resources below which have been instrumental in the past and others that are guiding the present and future.