DEV Community: COSS Media

Open Source Creator Series, Part 6: How to Measure Community Building

Kevin Xu — Mon, 24 Feb 2020 19:58:34 +0000

This is Part 6 of our Open Source Creator Series on “How to Measure Community Building" to help you – the open source technology creators – understand and bootstrap some of the essential non-technical elements of building a successful project.

(See Part 1 – Licensing Fundamentals; Part 2 – Product Marketing; Part 3 - How to Choose an Open Source License; Part 4 -- Documentation and Technical Writing 101; Part 5 -- Understanding 'Distribution' in Open Source Licensing)

Community building is table stakes in the success of any open source project.

Even outside of the open source context, community is considered a competitive advantage and moat in many industries, from retail to gaming to fitness. (For a deeper dive, see “When Community Becomes Your Competitive Advantage” in the Harvard Business Review.)

However, open source community building, especially offline activities, is notoriously hard to measure, track, and analyze. While we’ve all been to our fair share of meetups, conferences, and “summits” (and probably hosted a few of them ourselves), were they worth it? Did the community meaningfully grow? Was printing all those stickers and swags worth the money? Did we collect and track the right numbers to measure progress?
Conference stickers

To develop a better framework for measuring community, we can look to a different industry for guidance and fresh ideas: political campaigns.

Some Personal Context

I started my career in political campaigns in the U.S., as a field organizer for then candidate Senator Obama in 2008. Thinking back, a field organizer’s job was basically community building. My day consisted of calling supporters to do volunteer activities, hosting events to drum up more support, bringing in guest speakers (called “surrogates” in politics) to these events, and selling the vision and plan of our candidate (essentially our “product”).

Another big chunk of my day was data entry. We logged everything: interactions on my phone conversations, contact rate, event attendance, volunteer recruitment rate, volunteer show up rate, and a myriad of other numbers to constantly measure the effectiveness of what we do everyday.

Regardless of your misgivings about politics in general or specific politicians, the winning campaigns that produce political victories are all giant community building exercises that are data driven, meticulously measured, and constantly optimized. They are well-oiled community building machines.

When I entered the world of open source a few years ago, the community building part felt familiar and natural. What surprised me was how little community building as an operation, especially the offline activities, is quantified and measured.

Three Metrics to Track

Taking a page from the best-run political campaigns I’ve seen, here are the three most important metrics to track and optimize for an open source community:

# of community ambassadors
# of return attendees (defined as: people who attended your activities two or more times)
rate of churned attendees (defined as: percentage of people who attended your activities only once, or said they would come but didn’t show up)

Community Ambassadors

The function of a “community ambassador” is a user or enthusiast of your project, who is willing to consistently host local meetups or activities where she or he lives. Growing the number of community ambassadors and supporting them with resources and guidance is core to your community’s strength and scale. You can probably hire for these if you have a lot of funding, but pure volunteers speak more to the allure of your project.

These ambassadors should be your best friends, where you understand inside and out why they are motivated to evangelize your project in front of both peers and strangers. Their feedback on your project is also valuable and should be a critical part of your roadmap development process. You can strategically cultivate ambassadors in different tech hubs geographically around the world, so your project can count on someone with local knowledge to reach and serve users of different business cultures with different needs. The beauty of open source is that it’s global by default; take advantage of it!

Some developer hubs to consider: SF/Bay Area, New York City, Seattle, Vancouver, Toronto, Berlin, Beijing, Hangzhou, Shenzhen (especially hardware), Bangalore, Seoul, Singapore, Amsterdam. (Please ping me if I missed any!)

There’s an adage in political campaigns: “meet voters where they are.” The same concept can be re-appropriated to open source communities: “meet developers where they are.”

An example of this is the Cloud Native Ambassadors program of the Cloud Native Computing Foundation. (Note: not every ambassador on this page is consistently active; your community can do better!)

Return Attendees

The number of return attendees is crucial to measuring the usefulness or stickiness of your community activities. Tracking return attendees is how you can draw a meaningful line between “the curious” and “the serious.”

Trying to grow this number should be an obvious goal. However, that’s not the only goal. This is the group whose motivation you want to understand the clearest. This is the group who reflects your project’s user persona. This is the group that can probably give you the most valuable feedback. This is the group who will become your future community ambassadors.

Putting it differently: this is your 1,000 true fans (if you can keep them).

Having hosted and attended my fair share of community meetups, my observation is that most people participate to learn about a technical topic, search for tools to solve problems at work, or network for their next job opportunity. What they are not looking for is “being marketed to”.

There is a growing trend of developer community events becoming marketing events, especially when participants are from companies flushed with funding or have a strong marketing department who wants to “control messaging”. I personally find this trend troubling, because it undermines the core purpose of any open source community: learning.

Thus, be laser-focused on “technical education”. If a developer community gets taken over by marketing campaigns, your “return attendees” metric won’t be pretty.

Churned Attendees Rate

Tracking “churned attendees” is the flip side of the same coin as “returned attendees”, so I won’t belabor the point.

One note of caution: be brutally honest when measuring this number and don’t fool yourself (or others). If someone signed up but didn’t show up, it doesn’t mean much. If someone showed up once and never came back, it doesn’t mean much. Routinely sit down and assess why someone isn’t showing up to re-evaluate and refine your community program and activities.

Don’t build the wrong incentives into your community building operation to reward the wrong metric.

Of course, there are other things you can track, but more data does not necessarily mean clearer insight. Focusing your energy on these three metrics will make the most impact on your community building operation. An open source community, where the number of ambassadors and return attendees are trending up, and churned attendees rate is trending down, is one that’s healthy and growing in the right way.

(For the politically curious, the corresponding terms on a political campaign for these three metrics are typically: neighborhood captains, super volunteers, and flake rate.)

Value of In-Person Connection

I purposely focused this post on measuring offline community activities, not online, because online activities are inherently more trackable and intuitive to digital-native open source creators.

Offline community activities are essential to any project’s journey to reaching traction and prominence. I have yet to see a successful project that does not have a sizable offline presence, regardless of its online popularity.

Why is this the case? Why can’t an open source community, usually born online, just stay and grow online?

Because technology choice is ultimately a human decision, thus face-to-face interaction is an irreplaceable element of new technology adoption. No one wants to be the guinea pig. No one wants to be the “first”. The most effective way to not feel like the “first” is to literally see other human beings trying out or learning about the same thing.

Being in the same room as other developers, doing exercises on the same technology, and doing that regularly is the most effective way to build trust towards that project.

And with trust comes traction.

Open Source Creator Series, Part 5: Understanding "Distribution" in Open Source Licensing

Kevin Xu — Thu, 20 Feb 2020 19:51:45 +0000

This is Part 5 of our Open Source Creator Series on "Understanding ‘Distribution’ in Open Source Licensing" to help you – the open source technology creators – understand and bootstrap some of the essential non-technical elements of building a successful project.

(See Part 1 – Licensing Fundamentals; Part 2 – Product Marketing; Part 3 -- How to Choose an Open Source License; Part 4 -- Documentation and Technical Writing 101)

Once again, this post is based on an informative and concise video presentation (~7 minutes) by Heather Meeker, who is the preeminent open source licensing expert and is a partner at OSS Capital. (If licensing, as a topic, is completely new to you, I would recommend first watching Heather's video in Part 1 of this series on Licensing Fundamentals and Part 3 on How to Choose an Open Source License.)

“What is distribution?” is a question Heather gets frequently from open source creators and commercial open source software (COSS) founders. It’s directly connected to “share”, which is the most nuanced of the four freedoms of open source. The others: “run”, “study”, “improve”, are more straightforward.

Knowing what “distribution” means is important before it’s a common trigger for various open source licensing requirements. In short: distribution is triggered when a copy of something (in our case software) is transferred to another person. However, “distribution” as a term is actually not defined in the U.S. Copyright Act, thus at least when applied in the United States, it’s often up to legal analysis and interpretation.

Hope you find Heather’s video useful. And don’t hesitate to reach out via Twitter or LinkedIn if you have questions.

Please note: This presentation does not constitute legal advice and does not create an attorney-client relationship. The principles presented here may not apply to the facts of your situation.

Resources:

Heather Meeker's Book, "Open Source for Business"

Open Source Creator Series, Part 4: Documentation and Technical Writing 101

Kevin Xu — Wed, 12 Feb 2020 21:26:32 +0000

Special thanks to Luc Perkins, Developer Advocate at the Cloud Native Computing Foundation, for his invaluable input.

This is Part 4 of our Open Source Creator Series on "Documentation and Technical Writing 101" to help you – the open source technology creators – understand and bootstrap some of the essential non-technical elements of building a successful project.

(See Part 1 – [https://dev.to/coss-media/open-source-creator-series-part-1-licensing-fundamentals-4529); Part 2 – Product Marketing; Part 3 - How to Choose an Open Source License)

A project’s documentation gets the most amount of traffic, by far. It’s the place where people decide whether to continue learning about your project or move on. Thus, spending time and energy on documentation, technical writing, and focusing on the most important section, “Getting Started”, will do wonders for your project’s traction.

Why Is Documentation and Technical Writing Important?

Unfortunately, good code won’t speak for itself. Even the most elegantly-designed and well-written code base that’s solving the most pressing problem in the world won’t just get adopted on its own. You, the open source creator, need to speak for your code and breathe life into your creation. That’s where technical writing and documentation come in.

Writing may feel uncomfortable, even daunting, to many of you. As engineers, we are trained more to write code than to write about code. Many of you also speak English as a second or even third language, and may feel insecure or intimidated about writing in English. (I learned English as a second language, and my mother tongue is Mandarin Chinese, so I feel your pain.)

But we can’t get around the reality that if you want your project to have a broad, global reach, English is the language you must use. Don’t fear. I wrote this post with those challenges in mind. You don’t need to be the next Shakespeare to find the advice here useful.

Five Actionable Writing Tips

Here are five actionable writing tips you can apply today. They may seem painfully simple and obvious, yet we see them ignored over and over again in technical writing.

Use active voice (e.g. “You can change these configurations by…” [Active] vs. “These configurations can be changed by…” [Passive])
Use simple, short sentences (The Hemingway App is a helpful tool.)
Use headings, bullet points, and links to break up information into chunks, not long explanatory paragraphs
Use tables and diagrams, not sentences, to represent information with multiple dimensions
Always always always spell check for typos and grammar check for polish

By applying these tips consistently in your writing and editing workflow, you achieve two big goals: efficient communication and trust building.

Efficient communication. Engineers don’t want to read long-winded, meandering paragraphs in a documentation (they have novels for that). They want to get technical information or instructions (when it’s a guide) as efficiently as possible. Thus, your writing needs to be lean and useful. Thus, your writing needs to be lean and useful. This approach drives down reading cost for your technical audience. (That being said, it’s fine to apply some humor, emojis, and “fluff” here and there to give your project some “personality” and make it more memorable. How exactly you would do that would depend on your personality.)

Trust building. The most valuable currency you must accrue, especially in the early days of building your project, is trust. Trust comes not only from your code quality, but also the quality of your writing that talks about your code. Thus, please apply the same polish to your writing that you would to your code. This is the main reason for the last bullet point above on spell and grammar check.

Invest in “Getting Started”

With these fundamental writing techniques baked into your writing, the one section you should spend the most time on in your documentation is the “Getting Started” section. This is by far the most important section and a classic example of the “80/20 rule” in action. Most of the web traffic to your project land on your documentation, and most of that land on “Getting Started”. If it is well-constructed, you will get a new user right away. If not, the visitor will bounce and likely never come back.

How do you construct a good “Getting Started” section? I propose this three-step process:

Make it a Task: An effective “Getting Started” guide should be task-oriented -- a discrete mini-project that a developer can accomplish. It should not contain too much information about the architectural design, core concept, and other higher level information. A single, visual architectural overview is fine, but don’t devote multiple paragraphs to how and why your project is the best-designed solution. That information belongs somewhere else (more on that below). Instead, the “Getting Started” section should be mostly a list of steps and commands to...well get your project started!
Can be finished in less than 30 minutes: The core takeaway here is that the time to completion should be as low as possible; 30 minutes is the upper bound. This time limit also assumes the user has relatively little context about your project. This is important to keep in mind. Most people who would bother to go through your “Getting Started” guide would be a technical audience with a vague understanding of your project, but not much more than that. They are here to try something out, before they decide to spend more time digging deeper. “Time to completion” is a metric you should measure to continuously improve your “Getting Started” guide.
Do something meaningful: What “meaningful” means depends on the open source project. It is important to think hard about what that is, tightly define it into a task, and allow a developer who completes your “Getting Started” guide to achieve that meaningful task. This meaningful task must speak directly to your project’s value, otherwise it will leave developers feeling like they just wasted their time.

For inspiration: If you are a distributed database project, perhaps “meaningful” means the whole cluster remains available with no down time after you kill some nodes. If you are a data analytics or business intelligence tool, perhaps “meaningful” means quickly generating a dashboard with different visualizations after loading some data. Whatever “meaningful” means to your project, it should be achievable quickly and locally on a laptop.

A good example is Linkerd’s “Getting Started”. Linkerd is an open source service mesh for Kubernetes. I’m a novice in Kubernetes and even less familiar with service mesh. Yet, I completed Linkerd’s Getting Started guide on my laptop without much hassle, and the experience gave me a taste of what operating a service mesh is all about.

This three-step process could be a helpful framework for designing a highly efficient “Getting Started” section in a measurable way. It is also related to the “Time-to-Value” metric when it comes to productizing your open source project later on, which I’ve written about in more detail here.

Other Core Components

Besides carefully calibrating and optimizing your “Getting Started”, there are five other top-level components that are necessary to build a full-fledged documentation: architectural design, in-production usage guide, use cases, references, and roadmap.

Architectural Design: This is a deep dive into your project’s architecture and the rationales behind your design decisions, full of the details that you strategically glossed over in your “Getting Started” guide. This section is a big part of your overall Product Marketing plan, which you can read more about in Part 2 of this series. This section, usually filled with visuals and drawings, is meant to turn a casual hobbyist into an expert enthusiast, who is interested in investing time in your project for the long term.

In-Production Usage Guide: There is a world of difference between trying something out on a laptop and deploying it in-production. Guiding a user who wants to use your project more seriously becomes an important next step. Demonstrating in-production operational knowledge is also how you attract your initial business customers, who may like the promise of the technology but don’t know, or don’t feel confident, using it in a production environment.

Use Cases: The value of social proof is obvious, so listing out your in-production adopters is important. The key here is to make sure this information is easy to find. It will likely be the second most popular link after “Getting Started”.

References: This section explains the project in detail and allows your user to examine and understand it under a microscope. It also functions as a dictionary, where people look up information when needed. Some open source creators spend an inordinate amount of time spelling out every nuance and edge case of their project here. The motivation is understandable, but unnecessary at the outset when your time is limited. It’s more effective to reach a balance between detail and ways to get help: links to your community forum, Stack Overflow tag, or a separate FAQ page would do.

Roadmap: Laying out your future vision and plan with a rough timeline will keep users interested and incentivized for the long-term. Your project may not be perfect now, but you have a plan to per*fect* it. The Roadmap section is also a great place to get your community involved to build a strong ecosystem, so make sure you have a link that tells people how to voice their thoughts and opinions regarding the roadmap. (I’ll write about community-building specifics in a future post.)

You may not have all these components fully fleshed out yet, and some parts may materialize later than others, especially the use cases. However, be intentional about building these out over time. Addressing these five elements is the critical next step to your user’s journey into your project, assuming she had a good experience with “Getting Started”.

One last note: include a clear one-sentence statement on what license you are using (probably either in “Getting Started”, README, or somewhere highly visible). This small touch will make vetting your project for adoption from the end user side much more efficient. (For more information on licensing, see Part 1 – Licensing Fundamentals and Part 3 - How to Choose an Open Source License of this series.)

How Much Time Should You Spend Writing?

Generally, I recommend spending 10-20% of your time writing. Putting it in context: if you are working on your project full-time, it’s about half a day to one full day per week. The more nuanced point here is you should work writing into your normal workflow, so it becomes a routine, not an isolated choir. Making incremental progress over time, rather than doing all the writing in one giant sitting, is what will help your project reach that ultimate goal: traction and trust.

(If you need help auditing, improving or designing your documentation, feel free to reach out on Twitter, LinkedIn or DEV. Always happy to help!)

Open Source Creator Series, Part 3: How to Choose an Open Source License

Kevin Xu — Wed, 29 Jan 2020 19:53:23 +0000

This is Part 3 of our Open Source Creator Series on "How to Choose an Open Source License" to help you – the open source technology creators – understand and bootstrap some of the essential non-technical elements of building a successful project.

(See Part 1 – Licensing Fundamentals; Part 2 – Product Marketing)

Below is a ~20 minute video presentation by Heather Meeker that explains how you should choose an open source license. Heather is the preeminent open source licensing expert, wrote one of the definitive books on the topic "Open Source for Business", and is a partner at OSS Capital. (If licensing, as a topic, is completely new to you, I would recommend first watching Heather's video in Part 1 of this series on Licensing Fundamentals.)

Choosing a license for your creation can be stressful, so if you are feeling that way it's completely normal. What I love about Heather's info-rich presentation, from an entrepreneur's perspective, is it breaks down this seemingly complicated choice by answering some basic questions about your project:

How will the software be used and delivered: on-premises, Software-as-a-Service (SaaS) or a combination of the two?
Are you building the technology with the intention of building a business out of it? (This impacts whether you'd seek patent protection later on among other things.)
Who are your target users? (Fortune 100? Regulated industries, e.g. healthcare, financial services? Small and medium-sized businesses?)

Having answers to these core questions, which you should have anyways regardless of the licensing decision, will make choosing the right license much easier.

Please note: This presentation does not constitute legal advice and does not create an attorney-client relationship. The principles presented here may not apply to the facts of your situation.

Resources:

Heather Meeker's Book, "Open Source for Business"

Open Source Creator Series, Part 2: Open Source Product Marketing

Kevin Xu — Thu, 16 Jan 2020 20:19:56 +0000

Recently, we launched the Open Source Creator Series to help you – the technology creators -- understand and bootstrap some of the essential non-technical elements of building a successful project. (Part 1 of this series was on licensing fundamentals by Heather Meeker.)

In this post, we will focus on Product Marketing.

About every other week, I get questions from an open source project creator or a new founder of a commercial open source software (COSS) company on “how do I do product marketing?” Implicit in that inquiry lies some more foundational questions: “What the hell is product marketing? How much time should I spend on it?”

My goal with this post is to share our knowledge and some specific action items to help you understand “product marketing” as a concept and how to bootstrap it yourself productively until your project reaches the next level of traction.

What is Product Marketing?

Product marketing, in the COSS context, is materially different from product marketing for proprietary software and general marketing practices (e.g. ads, lead generation, sponsorship, booth at conference, etc.). Because the source code is open for all to see and the history of the project’s evolution is completely transparent, you need to articulate how your project works and why from a technical level to a technical audience.

Having the word “marketing” here is in fact misleading. It’s about product education. Your role is akin to a coach, mentor, or a teaching assistant in a computer science class or a code bootcamp -- not a “marketing person.”

This level of technical education isn’t something proprietary software products tend to need, because no one can see the source code anyway. Thus, these companies focus exclusively on educating its audience on the business value.

To build a successful open source project (and any commercial product that may be derived from it), you must educate your audience on both the technical details and business value.

While this may sound like extra work, it’s an advantage inherent to COSS because so much of the buying power of technology products are shifting to the developers. They care deeply about technical details and want to see and understand the source code themselves. Being able to learn, appreciate, and have confidence in the technical design, architecture, and future roadmap of a project is key to its adoption.

Developers also often treat the use of open source technology as a way to scratch their technical itch and stay sharp in a fast moving technology landscape. It’s an audience who yearns for education above all.
Being able to speak to this audience with these goals and desires is what product marketing/education in the COSS context is all about.

How to Bootstrap Product Marketing

So you (or maybe one or two other engineers) are laboring away to create your open source project, likely in the evening after your day job or on the weekends. How do you bootstrap some effective product marketing on your own?

I propose a three-stage process that could yield the best return for your time:

Online Forum
Writing
In-Person Meetup

Forum

Rummaging through forums from general ones like HackerNews and Reddit, to Discourse or Slack channels of projects that are closely related to what you are building, is a great way to figure out what questions developers have in your space. Starting with this step is less about inserting your project into the discussion directly, but more about gathering ideas on what you should focus on when putting together educational materials about your project.

Effectively, what you are doing is akin to “listening to your customer”.

Let’s be honest, we already spend a lot of time on these forums anyways. The only change is mindset not behavior: have more focus, jot ideas down actively, practice absorbing critiques (you may see threads critical of your project), and develop some intuition about what developers are thinking about.

(This is assuming you don’t already have an active community, where developers are asking questions directly. The long-term goal is to build your own community, which good product marketing directly helps with.)

Writing

Now that you have gathered some ideas, it’s time to produce. We recommend writing as the highest leveraged medium versus other forms like videos, podcasts, etc. This is because writing as a format has the best long-tail benefits, is most suited as reference material for people to go back to repeatedly, and can be more easily repackaged into other mediums. Also, open source has a global audience by default, many of whom might speak English as a second (third, or fourth) language, thus written content is most easily consumable at one’s own pace.

Your writing should focus on three categories that answer three fundamental questions:

What problem does your project solve? (Answers: why should it exist?)
How is the project architected and why? (Answers: is this a technically well-designed solution that has potential, thus worth investing time in continuously?)
How do I get a taste of it? (Answers: how quickly can I get some value out of it? NOTE: This is crucial to reducing your time-to-value metric to the shortest time possible. For a detailed elaboration on this topic, please read my post on deriving commercial product from an open source project.)

Your first set of writing could simply be three blog posts that address the above three points. These posts are canonical to your specific project, thus repackaging them into different formats, e.g. slide decks, Quora answers, Twitter threads, podcast interviews, etc., for different channels should be straightforward.

After you publish them, work the materials into your GitHub (or GitLab, Bitbucket) repos along with the project’s documentation. This is important because your public repo will likely be the face of your project for a long time, even if you have a dedicated website as well. A repo with strong educational content will go a long way in building social proof in the form of stars, forks, downloads, and even yield some contributions.

One note on writing: be patient! Your words likely won’t go viral overnight (unless you are a celebrity developer). But if the material is educational, useful, and accessible (no need for fancy language), it will draw attention to your project over time. You do your part, and let Google’s SEO do its part.

In-Person Meetup

With a few posts out in the wild, the next step is to find an in-person meetup that you can give a presentation about your project, using your writing as foundational material to build a compelling talk.

You may ask: “Why? Isn’t doing something in-person the biggest time suck? I’d rather code!”

True. You are not wrong. I recommend this step specifically at this moment, not earlier or later, because you want quicker feedback on your output than what the Internet may give you. Comments and feedback on your posts will trickle in, but giving a talk at a meetup, taking questions, and chatting with attendees afterwards over pizza is valuable and immediate. The goal is not to pitch your project (reminder: you are an educator, not a marketer), but to listen for what kind of questions you get when you do put your project (and yourself) out there. It also has the added benefit of giving you practice delivering presentations, which will become important as your project grows and you will need to present in higher stake situations, e.g. large conferences, demos with prospective users, etc.

I know this step may not be practical if you don’t live in a tech hub, where meetups are aplenty. You may want to look for groups that are open to doing virtual meetups via video, or work this into your existing travel plan. (But don’t fly across the world to talk at one meetup.)

In person meetups can feel scary. Public speaking is not for everyone and a legitimate source of fear. My one mental state tip: just think of yourself as free entertainment, lower your own expectations, and offer yourself up to meetup organizers proactively and they will love you! Don’t overthink it. Having been both a presenter and a meetup organizer, I know how hungry developer-focused meetups are for good technical education.

Final Words

There’s a lot more nuance, strategy, and sheer work to effective product marketing, but I hope this post gives you enough guidance and specific action items to bootstrap it. Ultimately, you should still spend the bulk of your time building your technology. And if you have some revenue or funding already, it’s worth hiring someone who has deep expertise in product marketing, even as a part-time advisor.

Frankly, product marketing talent is hard to find. You need someone with both the technical chops and curiosity to learn about your project on a deep level, and the communication skills to compellingly tell the world about it. If you have specific questions on how to hire for product marketing, feel free to contact us. We are happy to help!

Open Source Creator Series, Part 1: Licensing Fundamentals

Kevin Xu — Thu, 09 Jan 2020 05:58:40 +0000

At any given moment, thousands of developers around the world are creating new open source software – to solve a problem that has no good existing solution or to scratch a technical itch. Regardless of what originally motivated the project, as it matures, you'd likely want more and more people or companies to use it. Getting adoption, however, requires much more than good engineering. (It's a tough but recognized truth that the best technology doesn't always "win".)

Today, we are launching the "Open Source Creator Series" to help you – the technology creators – understand and bootstrap some of the essential non-technical elements of building a successful project, which are likely not in your area of expertise or comfort zone.

The first topic we will explore is "licensing fundamentals" by Heather Meeker, who's the preeminent open source licensing expert, wrote one of the definitive books on the topic "Open Source for Business", and is a partner at OSS Capital.

(In future posts, we will discuss topics like: product marketing, capital efficiency, building community, technical writing and documentation, etc. Comment below if you have topics you'd like us to cover.)

Below is a video slide presentation by Heather on open source licensing fundamentals. Although the presentation is mostly speaking to the needs of corporate adopters, knowing how companies approach adoption and licensing is critical, because the policies they follow will drive adoption rates of your creation, and ultimately determine its future potential and impact.

Understanding how they understand licensing and compliance is just as important, if not more, as your own point of view on how your creation ought to be used.

Heather also explains how corporate adopters balance the risk and reward of adopting open source software, and identifies their pain points in following the requirements of open source licenses.

Ultimately, the licensing model is supposed to serve the development model of open source, not vice-versa. Software adoption is both a technical and a business decision. Licensing is a part of it, but so is total cost of ownership (TCO), sustainability and supportability, etc.

We hope this material from Heather helps you grasp open source licensing fundamentals and put the topic in proper context, as you continue building your creation.

Please note: This presentation does not constitute legal advice and does not create an attorney-client relationship. The principles presented here may not apply to the facts of your situation.

Resources:

Heather Meeker's Book, "Open Source for Business"
Link to slides in the video

Open Source Culture Company Handbooks

Kevin Xu — Thu, 12 Dec 2019 01:11:57 +0000

This is a reference list of company handbooks who are building an open source company culture. This list is inspired by a recent conversation between DROdio (CEO at Armory) and Kate MacAleavey (Head of Culture and Leadership Development at Armory) and Joseph Jacks (founder of OSS Capital) on the topic of "open source culture", in the context of building a Commercial Open Source Software (COSS) company.

We hope this list, which we will maintain going forward, can be a valuable reference material to help COSS founders and operators better build their company culture. While not all of these companies are COSS companies, the way they approach, foster, and articulate culture is forward-thinking and very much "open source".

We encourage you to provide comments, edits, and contribution to this list at the COSS Media GitHub repo.

Company	Link to Handbook
18F	https://github.com/18F/handbook
Armory	http://go.Armory.io/iterate
Basecamp	https://github.com/basecamp/handbook
Bonusly	https://github.com/bonusly/un-handbook
GitLab	https://about.gitlab.com/handbook/
Nylas	https://github.com/nylas/handbook
Sourcegraph	https://about.sourcegraph.com/handbook
Sparksuite	https://github.com/sparksuite/employee-handbook
Tidepool	https://github.com/tidepool-org/handbook

A Discussion of Open Source Culture

Kevin Xu — Fri, 15 Nov 2019 22:54:04 +0000

DROdio (CEO at Armory) and Kate MacAleavey (Head of Culture and Leadership Development at Armory) recently had a fascinating discussion on YouTube with Joseph Jacks (founder of OSS Capital) about "open source culture", in the context of building a Commercial Open Source Software (COSS) company. Armory is a COSS company of the open source project, Spinnaker, which originated inside Netflix.

DEV Community, what do you think of this discussion and/or "open source culture" in general?

Here are some of my personal top takeaways from the conversation:

There's a lack of common vocabulary and language when it comes to talking about company culture broadly and culture specifically when building a COSS company. When rubber meets the road, company culture really comes down to the type of behaviors the company will put up with or not put up with. If you want an open culture, default to public discussion and don't use Slack DM (as an example) unless you have to. Be intentional about the details, because those actions will reflect what is and isn't important to your specific company culture than what you say about your culture. (Aside: this takeaway is very much reflected in Ben Horowitz's new book "What You Do Is Who You Are".)
It is important to build a sense of pride, agency, self-empowerment, resiliency, and openness (especially in the form of vulnerability) into your culture, if you want a can-do, start-to-start spirit to permeate the organization. That being said, freedom and agency can be terrifying, particularly for people who come from other organizations, where most organizations' default mode is "command and control". Thus, they have never felt "freedom" before, which can feel uncomfortable. Developing an effective process and mindset to self-select the people who embrace your culture is important. Not everyone likes the responsibility of having "ownership" or the power to act and experiment.
For top engineers of an open source project, e.g. maintainers or core committers, their reputations and skills "transfer" with the project, not the COSS company that is commercializing it. (Instead of being a Xoogler, you might be a X-Spinnaker-er...). This dynamic fundamentally changes how a COSS company treats engineers and builds an "open source culture", because the company and the project are decoupled. Thus, the "how" is an open question and new frontier.
Learning from mistakes ("how can we avoid mistake in the future?") instead of blaming the mistake-maker is key to building a "growth mindset" culture and a safe place for experimentation. This mentality, from a technical level, is codified as "Chaos Engineering" in Spinnaker, because the technology is made to empower application developer to deliver software faster and safer. The Armory culture embodies this characteristic, which requires a high level of ownership and agency, as well as the psychological safety that must come with constant experimentation and the failures that inevitably accompany experimentation.

(If you would like a transcript of this video, please see this post on COSS Media's website. Didn't want to make this post excessively long by copying/pasting the transcript here.)

Commercial Open Source Software (COSS) Glossary

Kevin Xu — Thu, 14 Nov 2019 23:17:39 +0000

Today, we are releasing the first version of COSS Glossary, a set of definitions of commonly used terms in the open source technology world. The motivation behind this document is to help remove the confusion and conflation that often occur when different stakeholders discuss open source, with or without a commercial angle, and make open source more accessible to newcomers. While people we've been working in open source for a long time may find these terms "obvious", it's sadly not the case for new developers who are creating projects or contributing to open source for the first time. And they are popping up around the world every single day.

Without a common set of precisely-worded definitions of the fundamental concepts, it's difficult, even counter-productive sometimes, to have second-order discussions on topics like: how do I build a vibrant community? which license should I choose to maximize adoption? how do I position my commercial offering vis-a-vis the open source community version? The list goes on...

This list of definitions is compiled by the team at OSS Capital, and we will continue to add and update it as time goes on. We welcome the community to participate by commenting, adding new terms, and proposing edits, so this glossary can evolve into a foundational document that can help all open source stakeholders establish a common set of understanding, in order to have more fruitful discussions. Please do so in our GitHub repo.

Terms and Definitions

Open source (common short-hand: OS): A transparent technology creation, development, collaboration, and distribution model, where the source, deliberation, decision-making, and roadmap of the technology are all presented and conducted publicly. It is not a type of company, business, or business model.

Open source software (common short-hand: OSS or FOSS--Free and Open Source Software): Software made generally available under a copyright license that meets the Open Source Definition, as defined by the Open Source Initiative.

Source Available Software: Software made generally available in source code form under a copyright license that does not meet the Open Source Definition. This type of license is also called a limited source code license.

Example: MongoDB under the Server Side Public License (SSPL), MariaDB under the Business Source License (BSL).

Commercial open source software (common short-hand: COSS): A category of companies or business units that commercializes open source technology. The existence of COSS depends on the existence of the corresponding open source technology but not vice versa. Often times, these businesses are founded or led by the core maintainers and committers of the open source technology from which they are built. (See different definitions of "Maintainer" and "Committer" below)

Example: see the Commercial Open Source Software Index (COSSI), a list of COSS companies that have reached $100 million USD in annual revenue.

Public Domain Software: Software made generally available with no copyright license conditions at all.

Example: SQLite

Open Core: A business model, or subset of the COSS company category, where an open source project is the foundation (or “core”) from which a commercial product is built and copyrighted under a proprietary license (as opposed to an open source license). The proportion of open and proprietary in a product offering, depends on the particular use case, technology, and business value. (See below different definitions of "Project" and "Product". See this post for a more detailed discussion of “open core” implementation.)

Single-Vendor: A term that describes when an open source project is primarily developed and commercialized by a single business entity, commonly known as a vendor.

Multi-Vendor: A term that describes when an open source project is developed and commercialized by more than one business entity.

Project: A piece of technology that is created, developed, and maintained based on open source methodology and can be independently used for its functionality. It is not commercially licensed or sold directly, but are often supported or serviced via commercial agreements between user and service provider.

Product: A commercially licensed product built on top of an open source project that are packaged, distributed, and sold to customers of the COSS entity that built this product. It is a discreet but related piece of technology to its open source project base.

Benevolent Dictator For Life (common short-hand: BDFL): An open source community governance model where a single person, typically the creator of the project, makes most of the major decisions associated with the project.

Maintainer: A developer whose main responsibility is to drive and manage the roadmap and development of an open source project by engaging in activities such as code review, roadmap, governance, and community and ecosystem building. It’s typically considered a community position with the most responsibility and power. It is also often used interchangeably with "Committer" (see below), because both roles have commit access to the project and can review and merge changes from a "Contributor" (see below).

Committer: A developer whose main responsibility is to build core features and improvements of an open source project and conduct code review of other contributions. It’s typically considered a community position with the second most responsibility and power, but it's also often used interchangeably with "Maintainer" (see above), because both roles have commit access to the project and can review and merge changes from a "Contributor" (see below).

Contributor: A developer who makes either regular or ad-hoc contributions to the code base of an open source project, reviewed and merged by either the maintainer or committer. The scale and difficulty of contributions vary widely, from fixing major bugs or developing a feature, to fixing typos and formatting in the documentation.

Governance: A set of rules and procedures, similar to a corporation’s bylaws or a country’s constitution, that outlines how an open source project makes technical and community decisions, and how individual developers become maintainers, committers, contributors, or other community roles. These rules and procedures typically exist in a public document in either the project’s code repository or website.

Foundation: A not-for-profit entity that hosts open source projects inside a neutral organization, separated from any commercial entities that monetize the projects. The foundation is typically responsible for the governance, legal, trademark, and other administrative work associated with managing an open source project. It also engages in marketing, educational, and ecosystem-building activities for the projects it hosts.

A foundation often plays a key role in ensuring the sustainability and longevity of open source projects, independent of whether the projects are being monetized or commercialized by companies.

Code of Conduct: A set of community policies and norms articulated and applied as the basis to manage, moderate, and adjudicate the behaviors of and communications between members of an open source community. It is usually in the form of a public document in either the project’s code repository or website.

What's Your Biggest Hurdle(s) When Trying to Grow Your Open Source Project?

Kevin Xu — Tue, 29 Oct 2019 04:34:46 +0000

Developers build amazing open source technologies, but many have trouble growing the initial seed into large, widely adopted projects. What's your biggest hurdle? Please comment.

Lessons in Managing a Distributed Team

Kevin Xu — Mon, 28 Oct 2019 04:11:57 +0000

Building a 100% distributed, or remote first, workforce is becoming more popular for tech companies. Some notable ones are: GitLab, Basecamp, Hashicorp, Automattic, and of course our beloved DEV. (If I missed any, please leave a comment, and I’ll keep updating this list.)

Having recently just built and managed a globally distributed team at PingCAP, a classic commercial open source software (COSS) company built on an open source distributed database TiDB, both the joys and complications of working in a fully distributed fashion are still fresh in my head. For context, our global team had employees, both technical and non-technical, that spanned three countries (the U.S., Canada, New Zealand). Not only did we work amongst ourselves, we also collaborated and coordinated with a much larger team in China, which was also distributed across six cities. “Global” in my case simply meant anywhere but China.

Since the virtues of a fully distributed team have been articulated in many other places, I want to instead share some lessons I learned from operating one, so you can build your own with a clear-eyed approach. A fully distributed team is totally the way to go, especially if you are building a COSS company, because remote collaboration is ingrained in the open source DNA. But nothing is all sunshine and rainbows, tradeoffs exist in every situation, and the more aware you are of what they are, the more sunshine you will get to feel.

Focus On Back Office Details

By “back office” I mean to describe the operational processes and details that are necessary to support a fully distributed team: how do you pay employees living in different parts of the country or world, business and income tax implications for both the employee and company, benefits and rights afforded to the employee given her location or jurisdiction. The list gets long.

The term has a negative connotation (and I’m open to alternatives). It’s usually perceived as either “boring” or “unimportant”, both of which could not be further from the truth.

Our first “global” employee besides myself was based in Canada. I was based in the U.S., and we only had a U.S. entity. I worked with her to figure out the kind of entity we needed to register in Canada, so the proper taxes could be remitted. We used bank wiring to pay her initially, which was a pain in the ass, costly, and led to awkward emails where she sometimes had to remind management to pay her because you can’t automate it. We put in more time to research better options, and eventually used a different service that could make payments somewhat easier from a U.S. account to non-U.S. accounts. It was by no means perfect, just improved. And I’m grateful to this day that she put up with it all.

It took a lot of energy out of us. She was an engineer, who had a background in distributed systems. I had multiple responsibilities -- building our open source community, setting our go-to-market strategy, recruiting more people, writing blog posts and case studies, etc. Neither of us was well-suited to deal with “back office” work. It was painful, and at times felt like distractions, but ultimately very necessary.

Our team grew and things got better over time, partly because we found better tools, but mostly because I had to learn to communicate upfront the difficulties and rough edges in working with us in a distributed setting. A lot of the operational complexities were out of my control, but the least (or most) I could do was be open upfront about it all.

Ultimately, solid talent continued to apply to our openings because we had a strong open source brand, interesting technical challenges to solve, a bright business prospect, along with a distributed work setting. Hopefully that’s why people are applying to your company too, and not just because they want to live and work from wherever they are.

Getting these operational details right, hopefully from the start, and if not, over time and be transparent about it, will yield big cultural dividends in the long term. Lean on your lawyers for help -- one of the few instances where I would advocate for lawyer use in the early days of a company. Otherwise, even the smallest mistakes will leave a bad taste and erode trust over time in other areas of work, no matter how “world-changing” your mission is.

(One other noteworthy issue of a distributed team where engineers span different countries is IP ownership. It’s a whole ‘nother can of worms that we will cover in more detail in future posts.)

Flatten Decision Making

The naysayers of fully distributed work often to point to the lack of face-to-face contact, spontaneous interactions, and time overlap due to distance and time zones differences as downsides.

These are not wrong, but they are mere symptoms. The core problem is siloed decision-making, which isn’t a distributed workforce problem per se. It is a general workforce coordination problem. However, physical distance and remoteness could make a fully distributed team more vulnerable to this problem.

People become disengaged and disenchanted when decisions are made without their involvement or knowledge, regardless of whether it affects their day-to-day work or not. Good employees don’t want to be mere “satellites” just taking orders. (Employees who want that probably aren’t good employees.) When the process of decision-making is not clear and transparent, doubt and distrust start to form. This problem repeats often in both small startups and larger startups who still think like a small startup.

A fully distributed team, by default, removes a lot of the physical silos (conference rooms and corner offices are notorious devices for making secret decisions). But it doesn’t remove the temptation or ability to make snap decisions, often for the sake of “moving fast” or “efficiency”; phone calls and Slack DMs still exist.

The cure for siloing is transparent process-driven decision-making. Lay out how each type of decisions are made, who decides and who’s accountable (should be the same person), and iterate on the process over time. Most crucially, founders and executives have to be disciplined about sticking to the process and resist the temptation to just “hash it out”, simply because they have the authority to do so. It may feel inefficient at first, but the cost of employee disengagement and distrust is much greater.

Open source best practices -- public documentation, Request for Comment (RFC) templates, open code review -- are good rubrics to adapt from when building decision-making processes for your distributed team.

By effectively “flattening” decision-making into one layer, a fully distributed team can minimize the potential distrust that may come with “remoteness”.

Strategically Use Conferences and Airbnb

As a database company, we go to quite a few industry conferences. Every company probably has some set of conferences or summits to attend to drive awareness for its product.

Our playbook for these business trips is: everyone is invited regardless of your function, and we all live under a single roof, eschewing hotel rooms.

This setup builds more cross-functional empathy (booth duty is hard work!), more familiarity with how the company’s product or service is positioned publicly (don’t assume everyone knows), and a shared work experience that tends to produce higher quality bonding than the traditional offsite model, where you are bonding for the sake of bonding.

For the first conference we went to as a team, there were four of us in an Airbnb house. After the conference, we all went tent camping, which turned out amazingly well (but in hindsight was an aggressive choice for a first offsite). For the last trip I organized as the general manager, there were 16 of us! We obviously had to find a much bigger house. We shared rooms, bunk beds, and worked and lived under one roof for a solid four days. It was basically an adult band camp (or database camp).

Whether it was four or 16 people, these conferences-turned-band-camps were always chaotic, fun, productive (somewhat), and revealing of everyone in ways you would never see.

Here’s a video montage of that last trip with 16 people:

Thinking back, observing our team in this light was hugely beneficial to me as a manager. Who chips in to help? Who takes the trash out? Who proactively buys groceries? Who leaves their stuff lying around? Seeing these situations and gathering these behavioral data points helped me better coordinate, manage, and streamline different people’s personalities, after we all disperse and return to our distributed way.

Distributed Future

For technology and knowledge workers, a fully distributed setting will become more mainstream. As more and more companies adopt this approach, I hope these personal experiences could help you think through now to minimize the cons and maximize the pros of distributed work.

I’d love to hear your stories, experiences, and lessons from managing or working in a distributed team. Please comment and share your thoughts!

Mental Framework for Deriving Product from Open Source Project

Kevin Xu — Fri, 18 Oct 2019 19:33:37 +0000

My first memory of playing with a computer was via a MS-DOS terminal on the x86 PC in my grandfather's pharmaceutical research lab in the early 90s – playing games stored on 3 1/2 floppy disks and doing touch typing exercises. As technology improved, I would later spend an obscene amount of time taking the computer apart to add more RAM, a new graphic card, or a new fan, mostly so I could play cooler games. It was a fun, ongoing project, and I bonded with my father over it. It was also way cheaper than buying new computer.

What's the point of this story in the context of open source?

Well, even though I had no idea what "open source" was at the time, I was behaving like what a typical developer would do with open source projects today – spending free time to piece together and build things I want, sometimes for a specific goal, sometimes to learn new things, sometimes as a way to connect with others.

But over time, I stopped tinkering. For whatever reason, I decided that my time was becoming too "valuable" to retrofit my older computers. I started using a MacBook, and when my older MacBook wasn't functioning well, I just paid a pretty penny for a new one with better configurations, instead of unscrewing the bottom to see if I could jam in a new RAM card.

My behavior became more akin to an enterprise buyer – saving time and trouble by spending money.

OSS Project != Product You Sell

If your experience with technology resembles mine in some way, then we all know intuitively that the projects we DIY with are not the same as products we spend money buying.

This isn't a new observation in the open source community.

Stephen Walli, an IT industry veteran and part of the Open Container Initiative, has written numerous detailed blog posts on this topic. Sarah Novotny, who led the Kubernetes community and was heavily involved in the NGINX and MySQL communities, emphatically articulated at the inaugural Open Core Summit that the open source project a company shepherds and the product that company sells are two completely different things.

Yet, project and product continue to get conflated by maintainers-turn-founders of commercial open source software (COSS) companies, especially (and ironically) when the open source project gets traction.

This mistake gets repeated, I believe, because it's hard to mentally conceptualize how and why a commercial product should be different, when the open source project is already being used widely.

What Makes a COSS Product Different?

Two core elements differentiate a commercial product from its open source root: packaged experience and buyer-specific features.

Packaged Experience

Packaging your project, so it has that out-of-the-box user experience, isn't just about a polished UI or hosting on your server as a SaaS (though that could be part of it). It's an expressed opinion of how you, the creator or maintainer of the project turned founder of the company, believe the technology should be used to solve your customer's business problem. That "opinion" is essentially the product experience the customer is paying for.

When you are running an open source community project, it's usually good to be not opinionated and let your community organically flourish. When you are developing a product for customers, it's usually good to be opinionated.

It's the retrofitted x86 PC versus the MacBook dynamic.

Dave McJannet (CEO of Hashicorp) and Peter Reinhardt (CEO of Segment), both cited packaging as a crucial step to get right, in order to turn an open source project into a scalable commercial product.

Buyer-Specific Features

A well-packaged product must also have features that are necessary for your targeted buyer to justify a purchase. What these features are depend on the profile of your buyer, but the possibilities are finite and manageable.

An enterprise buyer, say a Global 2000, will have a relatively consistent set of features that they must have in order to purchase new products. (EnterpriseReady.io is a great resource for what some of those features tend to be.)

A small or medium sized business buyer, say your local mom-and-pop bakery, who has less financial resources, less people power, and is more price sensitive will need different things to be convinced to buy.

A consumer service monetized via ads will be different still, where your buyer is the advertisers while your users are everyday people.

One thing is for sure: your buyer is almost never your open source community.

Know what your buyer requires for a purchase, package that with your expert opinion on how to solve the buyer's problem, and that's what differentiates a product from a project.

Sid Sijbrandij's articulation of GitLab's Buyer-based Open Core model is a good example for enterprise.

Certainly, other elements can be added to further the differentiation. But a packaged experience with buy-specific features are essential. Without one or the other, your prospective customer might as well just tinker on their own, for free.

One Metric to Measure (OMTM): Time-to-Value

A perennially difficult thing in product development is measuring progress and establishing a data-driven framework to determine whether you are on the right path or not. I'm a fan of the One Metric to Measure (OMTM) mentality, elaborated in "Lean Analytics", where you focus on one single number above everything else for your current stage. This approach enforces focus and discipline, among a sea of data you can gather and distract yourself with (oftentimes vanity metrics like download numbers or GitHub stars). The single metric can effectively rally your entire company around one tangible goal or mission – especially critical for an early stage company. And the metric you focus on will be different at different stages.

So what's the right OMTM in the early day of your product development?

I propose: Time-to-value

"Time" here is straight forward – lower the better.

"Value" needs precise, rigorous definition that is technology and problem specific. Your distributed database is valuable because it can serve data with no down time when servers fail. Your continuous integration tool is valuable because it enables application developers to push improvements faster without breaking the application itself. You get the idea.

How quickly can a customer see or feel that one core piece of value is what you measure and optimize for. What is a sufficiently short enough time does depend on the use case, but given the increasing consumerization of enterprise technology, any product's time-to-value that's > 30 minutes is probably too long.

Finding and tightly defining that "value" is hard and iterative, but also table stakes if you are looking to build a product company around an open source project. Without a deep understanding of what that value is for your customer, there's probably not much of a company to build.

At the end of the day, as much fun as it was to "beef up" my x86 PC, I'm pretty satisfied with my MacBook and happy to pay the premium. So don't get too enamored with the joy of tinkering, if your goal is actually to sell MacBook.