Building FOSS Communities

This page outlines what I’ve learned about building Free and Open Source Software communities while working at Sun Microsystems and Oracle. The experiences I talk about here focus mostly on open source software communities, but the more I explore this issue the more I see that the principles apply to building any large organization where people voluntarily gather and create. Communities provide serious opportunities for everyone involved. That’s what I’m exploring here. That’s what fascinates me.

I’ll focus on three distinct but closely related groups: builders, participants, and contributors. Builders are people like community managers whose main role is to actually build the community so it scales well beyond its natural boundaries. Participants are people who show up at events or user group meetings and they are there primarily to learn. Contributors are people who also show up but they actively give back through code, presentations, organizing, leadership, and other work. All three groups are necessary for a software community to function. And although all three are involved in community building activities, it’s the builders who tie things together and those are the people who will most likely be interested in this content.

The builders, participants, and contributors all create reciprocal relationships. When you organize the community itself, you create opportunities for yourself and everyone around you because without you there would simply be no community. When you participate in a community, you grow your skills, expand your network, and build a base of knowledge and experience to support potential contributions in the future. And when you contribute back to a community, you provide the backbone necessary for the entire community to function because that’s the content around which the people gather in the first place: source code, binaries, libraries, presentations, user groups, conferences, and all the assets the community produces that everyone consumes. Remember, what you put in comes back multiplied because communities amplify individual effort so it’s always a good investment to contribute. Your employer benefits in this dynamic as well. Strong communities attract engineering talent, accelerate innovation, and build business ecosystems that make everyone more successful.

The list of topics below is comprehensive but certainly not yet complete. Community building, like any global project management enterprise, involves many moving parts cutting across many technical, social, and organizational levels. But there are enough concepts here to get most people started in the building process.

I believe the underlying process of community building is nature itself. People gather. They form groups. They want to help and be helped. Leaders emerge. People follow and contribute and everyone benefits from engagements at all levels. That’s what humans do when given the chance. This behavior is rooted in our evolutionary history. Humans compete, certainly, but we also cooperate. In fact, for millions of years, cooperation was necessary for survival. But human communities don’t necessarily scale well without organizers actively building infrastructure to support all the interactions necessary for the operations. There is research that suggests humans maintain stable relationships with around 100 to 200 people. Beyond that threshold, groups need some formal structure: rules, hierarchies, and management systems. Understanding these biological foundations can help people building communities because it’s smart to leverage an underlying sources of human intention. Ultimately communities are built by individuals taking action. But how do you get people to gather and take action and then build infrastructure to enable those collective actions to scale into something global? That’s an art.

The sections below cover the technical aspects of building FOSS communities. But since community building extends beyond technology, I’ve include sections on non-technical social movements and the biological and evolutionary foundations of human cooperation. Everything’s a work in progress and over time will evolve into a book. So, stay tuned!

“Every thought you produce, anything you say, any action you do, it bears your signature.”
— Thich Nhat Hanh

UnVoxxed Hawaii (LavaOne) in Honolulu in January 2019. — *UnVoxxed Hawaii (LavaOne), February 2020*

01. People

Communities are about people. Many components are involved in the community building process, but people are by far the most important. Don’t get so distracted with logistics and politics that you lose sight of the people. Focus on these three groups:

People you are trying to attract. These are participants, contributors, users, and fans. They are the reason you build. Understand what motivates them. What problems are they trying to solve? What do they need to learn? What barriers keep them from participating? Your job is to make it easy for them to join and contribute. Remove friction. Create clear paths for involvement. Make people feel welcome from their first interaction.

People you need to help you build. These are leaders, managers, and organizers. You cannot scale a community alone. You need people who will step up and take ownership of pieces of the work. Look for people who are already doing things, not just talking about doing things. Contributors emerge from the community itself. Your job is to recognize them, support them, and distribute leadership broadly. Give them the authority and resources they need. Then get out of their way.

People who get in your way. Trolls exist in every community. They drain energy and discourage participation. Deal with them quickly and directly. Write a code of conduct and enforce it consistently. Protect your contributors from harassment and abuse. Sometimes you need to remove people who damage the community. This is not censorship. This is maintenance. A healthy community requires boundaries.

Once you understand these groups, you can focus on what matters most in any community building project. The people doing the work are the community. Everything else serves them.

02. Planning

Building communities is an active and cyclical process of planning and implementing. Some people resist this because they believe communities should grow organically as people gather. Natural growth happens in the early stages when things are small. But to scale a community you need planning, resources, and builders. You have to build infrastructure, engage new people, and manage resources from diverse sources including corporate funding, foundation support, individual contributions, and volunteer effort.

The planning process does not have to be overwhelming or complex initially. Good community building rests on two principles: open communications and open development. Work in the open and talk in the open. If you want to grow, you need to talk to many people and talk to them constantly. Provide ways for people to contribute by creating and sharing their work with you and everyone else. The process and results of the community’s work help build the community because they generate more communications and more work. And around you go.

Planning and building are tethered. Write a plan. Start with one page. What do you want to build? Why? With whom? Where? When? How? Then start. Get feedback. Update your plan. Expand it. Publish it. Repeat often. Think in terms of generating quick momentum through small iterative steps rather than planning forever before you build anything. Focus your building efforts on moving toward your plan. But remain flexible so you can change direction when necessary. You will have to change direction. The final product rarely looks exactly like the initial plan. The purpose of a plan is to get you off the couch.

03. Transparency

Get outside. You cannot build a community from behind a corporate firewall or from inside your house. Conversations, ideas, arguments, plans, meetings, mailing lists, forums, websites, social networks, source code, documents, tools, people, infrastructure, artwork, whatever. Get it all outside.

That’s the only way anyone will know you exist. And it’s the only way anyone will have a fair shot at participating and contributing back and helping your community grow. Note here that I’m intentionally combining the community building process with the product or service the community delivers. If you are building an open source development community, then all the tools engineers need to build the software are also the tools you need to build the community. That’s how you engage new people and keep the people you already have. All tools are community building tools. The goal is to provide things around which people can gather, talk, and work.

Don’t wait until everything is done to put your work outside. Put the pieces outside and let things grow and come together from multiple directions over time. Yes, this will be messy. But communities are messy. Get used to it. This concept may seem counterintuitive and even confusing but it’s critical for building momentum. And this takes time. You build in pieces. Transparency is required to facilitate the process. You cannot live in two worlds if you want to build a community. You have to build outside.

There is an important exception to this transparency rule. If you are building a political movement for social liberation then you will need to be more discreet. You will have to find ways to make your work available to some but not all. In general though, if you are not overthrowing a dictatorship, you should be transparent.

04.Participation

Communities thrive when people are encouraged to participate, form trust relationships, and earn their way based on merit. Make sure the procedures for getting involved in your community are well documented and understood by everyone. You can look at this issue as the distinction between a community and a program. Most traditional corporate programs go one way, usually from a company to a market. But communities go two ways, actually many ways, and involve just as much coming as going. Participation is about doing things in the community, not talking about doing things in the community or offering a limited number of things that people can do. Remember that these distinctions are clear to anyone who participates in real development communities. Don’t bother faking it.

When communities are small and organic, those who participate generally do most of the work. As a result, those who do get the privilege to lead. Those are also the people whose voices are heard above all others no matter how noisy it gets. That’s the concept you need to embrace to scale things well. Encourage people to earn their credibility based on the work they contribute to the community, not the title they bring from their company or university or any other organization. If you want people to stick around and help the community grow, you will have to enable people to participate directly in as many operations as possible.

Let go. The more you keep control and the more you centralize, the more you will reduce participation and hinder growth. You can build very large programs by keeping control if you have lots of resources and customers or followers. But most community people will not engage unless they can directly participate and contribute to the creation and growth of the community itself. Work is visible. Contributions speak louder than words. People who do the work earn respect and influence naturally. That’s how healthy communities operate.

05. Onboarding

Getting people into your community is only half the challenge. Keeping them there requires intentional onboarding. First impressions matter. A confused or frustrated newcomer will leave and never return. Your job is to make the first experience smooth, welcoming, and productive.

Start with clear entry points. Create documentation that answers basic questions. Where do I start? How do I set up my environment? Where do I ask questions? Who can help me? Don’t assume people know how your community works. They don’t. Spell it out. Use simple language. Provide examples. Link to resources. Make it easy to find help quickly. Many communities fail at this basic step and wonder why newcomers disappear.

Create starter tasks for new contributors. These should be small, well-defined, and achievable in a few hours. Label them clearly in your issue tracker. Guide people through their first contribution from start to finish. Celebrate that first merged pull request or accepted patch. Recognition matters. It signals that the person belongs and their work has value. This is where community members are made.

Assign mentors or create buddy systems for newcomers. Experienced contributors should expect to spend time helping new people get oriented. This is not charity. This is investment. Today’s confused newcomer is tomorrow’s core contributor. The communities that grow are the ones that make onboarding a priority, not an afterthought. Make people feel like they matter from day one. Because they do.

06. Contributions

Define the contributions you want. Get specific. Publish them. Give general categories as well as detailed examples. And expect the community to offer even more examples and things you hadn’t thought of. That’s the goal actually.

For a software development project, contributions include source code, tests, technical presentations, user groups, language translations, university courses, training materials, websites, content, photography, video, branding, graphics, distributions, evangelism, documentation, bug reports, development tools, and governance. Many of those items are technical and require engineering expertise. But many are not technical at all and can be done by many people in the community. Think about a variety of contributions you want to encourage, publish a list, and then let that list grow in the open.

Contributing is the best way for people to cut through the noise in a community and get recognized. Existing contributors know the process and rewards. They are looking out for new contributors and can easily spot them. Make yourself and your intent known. This is a powerful process among large groups of people. Don’t wait to be invited. Step forward with work. Show what you can do. Contribution is how you earn visibility and respect in any community.

When contributions start coming in, point to the people who are contributing. Call attention to contributions. In most communities everyone knows who really contributes because work speaks louder than words. Contributors generally work with each other in the open. But as things grow in size and complexity it helps to thank people publicly and keep a record of who’s doing what. Do this in an understated way. Keep it classy. Be mindful of your community’s personality.

The goal is to make contributing easy and rewarding. Remove barriers. Simplify processes. Respond quickly to contributions. Provide feedback. Merge good work promptly. Nothing kills momentum like ignored pull requests or patches that sit for months. If someone took the time to contribute, respect that effort with your attention. Contributors who feel valued stick around. Contributors who feel ignored leave.

We all have influence in the spaces in which we participate. We have agency. We have power. I cannot think of a better quote to illustrate how important the individual is as they mix within larger groups:

“Every thought you produce, anything you say, any action you do, it bears your signature.” — Thich Nhat Hanh, Vietnamese Zen Buddhist Monk

This is an important concept to understand. When you realize that your contribution to the group bears your signature, that’s how you communicate to others in the community to cut through the noise and get something done. How does this work? Simply, contributors are always looking for other contributors, so signed signals are more easily seen among noisy global networks.

07. Documentation

Documentation is infrastructure. It’s not optional and it’s not something you do after everything else is finished. Documentation is how your community scales. Without it, you become the bottleneck. Every question comes to you. Every new person needs your personal attention. Every process lives only in your head. That doesn’t scale and it’s inefficient.

Write down how things work. Document your processes, your tools, your decisions, and your culture. Explain how to build the software, how to submit contributions, how to join discussions, how to report bugs, and how to get help. Make this documentation public and easy to find. Keep it current. Outdated documentation is worse than no documentation because it wastes people’s time and creates frustration. Good potential contributors expect to see comprehensive documentation. They judge your project by the quality of your documentation before they contribute anything.

Good documentation empowers people to help themselves and help each other. It distributes knowledge across the community. When someone asks a question that’s already documented, you can point them to the answer and they can find it themselves next time. When people understand the processes, they can participate more effectively. When processes are transparent, people trust them. Documentation creates that transparency.

Treat documentation as a community contribution. Encourage people to improve it. Make it easy to submit updates. When someone asks a good question, turn the answer into documentation so the next person benefits. Documentation grows with the community. It captures institutional knowledge and prevents that knowledge from disappearing when key people leave. Strong communities have strong documentation. Weak communities wonder why nobody knows what’s going on.

08. Presentations

If you are building a technical community you will be presenting to technical people. These are the people you want to get involved in your project. That’s why you are talking to them. Use your own voice, not your company’s marketing voice. Focus. Go deep. Get technical. You’re talking to engineers so don’t waste their time bouncing along the surface. People will appreciate your genuine approach.

Don’t just describe the technology generally. Add in pieces about how people can get involved and contribute directly to the technology and to the community and how that benefits everyone. Most technical presentations have one slide at the end with a list of mailing lists to join. If you are a builder, that one slide is not enough. Make the concept of contribution pervasive throughout your talk. Show people the path to participation while you’re explaining the technology.

Ask questions. Start conversations. Take names and follow up. I used to know a master bricklayer. I loved watching him place bricks. He was precise. He was an expert. His walls were beautiful. They were perfect. One brick at a time. That’s the attitude you need to build a community. You do it one person at a time and people need to feel that focus you are projecting.

Presentations are not just about spreading information. They are about building relationships. The conversation after your talk matters as much as the talk itself. People remember how you made them feel more than what you said. Be accessible. Be helpful. Be genuine. That’s how you turn audience members into community members.

09. Events

You have to go to conferences. But don’t feel you have to always present something. Participating in the sessions, asking questions, and engaging in hallway conversations and social events are all just as important as presenting formal papers. Just being there is critical. All communities need a mix of face-to-face and online interactions to create a feeling of community. And if you are at an event don’t miss the opportunity to do a rapid-fire lightning talk. Most good conferences offer these opportunities and you should always be prepared to do this off the top of your head with no notes and no slides.

Add user group meetings to your list of events to attend. Or better yet start a user group. If you start a user group do it in a bar or coffee shop. Start small and social and let the technical presentations grow slowly as more people bring their own experiences to the group. Don’t feel you have to always have a big technical presentation with a hundred people in the room each meeting. That’s not realistic for the vast majority of groups. Maybe try technical sessions quarterly but meet monthly in a bar for food and beer and then discuss things on a mailing list between meetings.

Start small. Look for ways to build tradition through repeated experiences. Take lots of pictures or video of people at meetings. Photography is a remarkably powerful community development tool because it cuts cleanly across language and cultural barriers. Everyone everywhere loves pictures. Over time a culture will develop and that’s the glue you need to start holding your group together. After user groups grow, look to connect multiple groups so they can collaborate and start running small conferences.

Events create momentum. They give people deadlines to finish work. They provide venues for announcements. They concentrate energy and attention. Plan events regularly. Make them predictable so people can plan to attend. Mix large conferences with small intimate gatherings. Both serve different purposes and both matter for building strong communities.

10. Infrastructure

If you are going to build a community, spend time figuring out the physical and digital infrastructure you need to support all the people you want to attract and all the work they produce. Make sure your website design is modular so you can grow fast and in new ways as your plans change. Build your site so it can be localized into dozens of the most common languages and encourage the community to contribute those content translations.

What tools and processes are necessary to collect and host the project’s artifacts? Source code repositories, review and testing systems, defect tracking applications, content management services, and communications systems like blogs, wikis, social software, mailing lists, and forums. Most projects today use GitHub or GitLab, which consolidate many of these tools in one platform. Smaller and newer projects almost always start there. But some established projects maintain their own infrastructure. The Linux kernel uses kernel.org with custom mailing lists and git infrastructure. The Apache Software Foundation and Eclipse Foundation host their own systems for hundreds of projects. Some projects use hybrid approaches, like Rust with GitHub for code but custom infrastructure for governance. Choose what fits your project’s needs and philosophy.

Who has access to those systems? How do people earn greater access over time? Do you need physical items like vehicles and storage facilities for conference demos and stages and telecommunications equipment? What are your needs for video, audio, and other recording, storage, and streaming devices? What organizations will you and your community be interacting with? Any unions involved? Companies? Universities? Governments? Are your systems secure?

Build your infrastructure to not only transmit information to people but also to accommodate contributions coming back. Your infrastructure should enable participation, not create barriers. When infrastructure works well, people don’t notice it. When it breaks or gets in the way, it stops everything. Plan for growth. Expect things to change. Keep infrastructure flexible enough to evolve with your community’s needs.

11. Governance

Governance is about development frameworks and social structures to help people get work done. Governance can facilitate community growth quite nicely or it can kill a community with too much bureaucracy. If you are looking for true community governance then don’t launch with your processes already baked. Instead, let some things emerge over time as they are needed. The governance needs will evolve anyway so you may as well keep it small and flexible to start and then scale what works over time.

Governance is difficult. Specifying processes to get people to accomplish large and complex things is challenging, especially as things scale. There are people who have this expertise so don’t hesitate to seek them out. Learn from communities that have faced similar challenges. Talk to foundation staff who work with multiple projects. Read governance documents from successful communities. Ask for help.

How will your community run itself? What will the social organization look like? Will the community have elections? What voting system will you use? Who has access to what resources and how do they earn privileges over time? Are the social structures tied into and consistent with the engineering processes, and are those processes expressed in the software and infrastructure? How will everyone make decisions? What is your leadership model and how will you distribute that concept around the world? How will you call attention to contributors? How will you resolve conflicts? Write a code of conduct in detail.

These are questions that need addressing whenever any large group of people comes together to collaborate on anything. When you are small, you can manage governance easily in your head. But when you grow globally and in complexity you need to document the behavior you want to encourage and set some rules around how to manage things. It doesn’t have to be all pervasive, but people need to know where they stand, what’s expected of them, and what opportunities are available.

The people who write the governance systems should be the same people who run the community. There can be no separation here. The people who are doing the work need to write the rules of engagement. In the open source software world, most mature communities write their governance models right on their websites so these documents aren’t hard to find. Study them. Learn from communities that have solved problems you haven’t faced yet.

12. Leadership & Meritocracy

So many people claim they lead. Maybe they have a big hairy title or powerful position or know someone special, or maybe they have lots of cash and feel everyone should just follow along quietly. That’s not how leadership generally works in a healthy community. And even if there is a powerful single leader at the top there are always opportunities to lead in other areas. In a good community, leadership is distributed much more horizontally than vertically and it’s based on merit. There is simply no other way to scale a community to motivate people and manage the operations to support large numbers of volunteers.

Spotting great leadership in a community is easy. Just look around for who’s talking and for who’s doing. Engage the ones who are doing. From that pool of people you can carve out a group of leaders to help build the community. Chances are those people won’t bark orders at others. Instead they’ll encourage people to work right along with them and people will want to engage. Real leaders don’t duck when things get hot. They don’t get hard to find when things get confusing or uncertain. They stay visible. And they step up and act because things need doing. Leadership is demonstrated via action and anyone can lead because anyone can act.

Once you’ve established some criteria for your leadership model and start attracting and distributing leaders, a culture will grow as your community grows. This is good. But as a leader you have to be aware of what’s growing. What are your community’s values? What does your community stand for? What do you stand for? Don’t just think about this stuff casually. Make it core. Write it down. Build it. Things get painfully clear when you actually build something rather than just talk about something. Just having a written specification is nice, but it’s ultimately useless unless something gets built. It’s in the building that you find the bugs.

Your goal should be to build a distributed meritocracy. People earn influence and responsibility through their contributions and their track record of getting things done. Titles from outside the community mean little. What matters is what you do inside the community. This creates opportunity for everyone. Anyone can step up and lead by doing the work. That’s empowering for individuals and it’s how communities scale.

13. Culture

Culture emerges from the values and behaviors you reinforce. It’s not something you write in a mission statement and then forget. Culture is what people experience every day in your community. It’s how people treat each other. It’s what gets celebrated and what gets criticized. It’s who gets heard and who gets ignored. Culture shapes everything.

If you don’t intentionally build the culture you want, you may be surprised that another culture emerges and it won’t necessarily be what you want. Culture develops whether you guide it or not. Without intentional effort, culture often defaults to whoever shows up first and talks the loudest. That might work out fine, or it might create an environment that drives away the very people you need. Take control of this process early.

You build culture through small consistent actions over time. How do you respond when someone makes a mistake? How do you handle disagreements? Do you welcome questions or dismiss them? Do you credit people’s work publicly? Do you make space for newcomers or do old-timers dominate every conversation? These daily interactions create the culture that people experience. Be intentional about the culture you want and model it yourself.

Different communities have different cultures. Some are more formal and process-driven. Others are casual and spontaneous. Some value technical excellence above all else. Others prioritize inclusivity and mentorship. There’s no single right answer, but you need to be clear about what your community values. Write it down. Talk about it. Reinforce it through your actions. When people violate the culture you want, address it directly. When people embody it, recognize them.

Culture attracts like-minded people and repels others. That’s okay. You cannot be everything to everyone. A strong distinctive culture helps people self-select. They know quickly whether they belong or not. This saves everyone time. Focus on building the culture you want, not the culture you think will please the most people. Authentic culture built on real values creates lasting communities. Generic culture built to avoid offending anyone creates nothing memorable.

14. Diversity

Diverse communities are stronger communities. Different perspectives lead to better solutions. Different backgrounds bring different experiences. Different approaches to problems create innovation. When everyone thinks alike, you get groupthink. When people bring varied viewpoints, you get robust discussion and better outcomes.

Everyone has something to contribute. If you are actively building your community, it’s your responsibility to seek these people out. Value all contributions, large or small. Not everyone will write code or design architecture. Some people will write documentation, translate content, answer questions, organize events, or welcome newcomers. All of this matters. All of it builds community. Recognize and appreciate the full range of contributions that people make.

Build environments where people from different backgrounds can participate and succeed. Remove unnecessary barriers to entry. Make your documentation clear. Provide multiple ways for people to contribute. Be mindful of time zones when scheduling meetings. Offer translation support when possible. Consider that not everyone has the same resources or access. Small adjustments can open doors for people who might otherwise be excluded.

Inclusivity means creating space for people to participate fully. It means listening to voices that might not be the loudest. It means recognizing that not everyone communicates the same way or has the same level of confidence. Some people need encouragement to speak up. Others need reminders to make space for others. Your job as a community builder is to facilitate both.

But inclusivity does not mean lowering standards or abandoning meritocracy. People still earn their place through contributions and demonstrated ability. What matters is that everyone has a fair opportunity to contribute and be recognized for their work. Judge people by what they do, not where they come from or what they look like. Merit and inclusion work together, not against each other. The goal is to expand the pool of contributors, not to compromise on quality. When you do this well, you get both diversity and excellence.

15. Universities

If you want to grow, and you should always want to grow, you need to go back to school and hang out with young people. They think differently than you do. They are not from your generation. They don’t know everything, but they will pry open your mind and offer a view into things that you just never considered.

Get your projects in front of students and professors everywhere, but pay special attention to regions with large student populations like India, China, and Indonesia. Don’t neglect established tech hubs in the United States, Europe, and elsewhere. Start technical user groups on campus. Establish relationships with professors and administrators. Universities are critical infrastructure for any community that wants to last.

It’s good to build user groups at universities and encourage students to start contributing while they are in school. Your project will benefit from their participation and the students will be able to graduate with a published portfolio of contributions to a global FOSS project. It’s a win-win situation. Students gain real-world experience and visibility. Your project gains contributors and fresh perspectives.

University visits are probably the single best way to ensure that your community has a shot at surviving into the future. You will always need new ideas, fresh energy, and an unlimited supply of young people so neglecting universities is not an option. It needs to be a top priority. By the way, building communities at universities is seriously fun.

Students bring enthusiasm and time. They have the freedom to experiment and take risks that professionals with jobs and families often cannot. They ask questions that challenge assumptions. They adopt new technologies quickly. They become the next generation of contributors and leaders. When you invest time in universities, you’re investing in the long-term health of your community. Those students you meet today will be the core contributors and maintainers five years from now.

16. Local and Global

Build your community with both global and local perspectives in mind. Where are the developers or users or contributors who could potentially join your community? Go there. A lot. If they are local, you will have an easier time with expenses and knowledge of the situation so you can act more quickly.

But when you go global you’ll run into all sorts of interesting language, cultural, and even governmental issues that will slow you down. To manage this, look for bilingual people who can help build the community in that region, and then work with those leaders to create a global network of communities.

You will never have one community around the world, so don’t expect everyone to just follow you or even understand you. Instead, you will have many communities and they will express their own independence differently. Expect this. It’s good. Your job is to encourage them to be as independent as necessary. Understand that their independence is a requirement for them to embrace your community. But also you need to help them connect to other regions, such as communities you build in your own local area, so they can contribute to the overall global community. This is not easy. But it’s necessary. And it can be an interesting source of really innovative ideas as you engage both established markets and rapidly growing regions.

Local communities need autonomy to thrive in their own contexts. They understand their local needs better than you do. They know how to communicate effectively in their language and culture. They know what motivates people in their region. Give them space to operate while providing connection to the larger global community. The balance between local autonomy and global coordination is delicate. Get it right and you create a powerful network. Get it wrong and you either stifle local innovation or fragment into disconnected silos.

17. Marketing

If you are building a community from inside a large organization, go meet your marketing teams. They can help publicize your project formally at conferences or within press and analyst operations or at corporate customer meetings. And they can offer a perspective you may have not considered on important issues such as trademarks, branding, media, advertising, and competition. Everyone thinks they can do marketing. But obviously most can’t. And don’t listen to those quick-to-judge marketers, especially when they don’t even come from a marketing background and don’t understand the issues.

Talking about innovative marketing and doing great marketing are two entirely different activities. So just go find some good marketing people who do marketing for a living and inspire them to get involved in your project. If you can find marketing professionals who are also familiar with community development, that’s excellent. If not, teach them. That’s part of your job as a community manager. You build community at all levels both internally within your company and externally out in the wild.

One of the best references for marketing within a FOSS environment is The Cluetrain Manifesto. It’s an older book but still valuable for engaging communities with conversation-based marketing, not megaphone marketing. All great marketers in the open source software world understand these principles.

Perhaps the most important aspect of getting marketing teams involved in your community is the need to quantify the value the community brings to your organization. The term “community development” can sound too much like charity to some executives who control corporate resources, stuff you need such as developers, infrastructure, documentation, source code, advertising, expenses, and buildings. So write a marketing plan based on your community development plan. You need both. Here’s a quick list of items to include: metrics, value, messages, business development, branding, revenue opportunities for new products, and contributions.

Get creative. But wrap the entire package in a context of money. You are building a community to generate value for your company’s shareholders. Period. If you are not using that language while talking to executives you are in trouble. That’s the only way you are going to secure resources. Finally, although community development plans should be public, corporate marketing plans should be private. If people complain, tough.

18. Advocacy

Advocacy is much bigger than marketing and it’s somewhat different as well. Advocacy is not about specific marketing disciplines such as advertising, branding, or public relations. Instead, advocacy is about direct, unfiltered engagement at all levels of the community. And it should promote active participation and contribution as the core message. It’s also messy and time consuming. It’s about many-to-many conversations and not one-to-many.

Advocacy can include marketing people, but it also includes engineers and project managers and support services and anyone else who wants to get involved. Everyone works. Everyone organizes. Everyone talks. Everyone builds. And everyone does this in public. That’s advocacy. Also, you are the best advocate for your own work, right? Well, that’s why you need to assume the responsibility for communicating your own work in your own way. Don’t just give this function to corporate marketing and walk away. Be involved. Do it yourself. And teach others to do it for themselves.

Building communities is ultimately a social exercise so people should have fun as they participate, and you should have fun as you build. You want to draw people into your community, right? You want to encourage people to stick around, right? Make it fun to hang out. Give people the opportunity and the permission to advocate and they will have a ball.

If you are in a corporate setting don’t worry about letting your people go out in public and talk it up with the community. Relax. They won’t leave. They’ll come back. I get this concern all the time. “I can’t let my people out because they’ll just leave and get a new job at a competitor.” Actually, the opposite is more likely. If you keep your best people locked in a cage they’ll eventually get frustrated and split. Besides, your best talent is already connected externally and if you don’t know this you’re not paying attention. Instead, if you give them a public platform from which to build your community and trust them to use your property responsibly, they will honor that trust and stay. Why? It’s in their interest to stay because they’re benefiting from the experience. If you don’t trust, though, you can’t build a community anyway so this point may be moot for some. It’s obvious to everyone else.

19. Content and Learning

Communities grow through shared knowledge. Creating and distributing content is how you scale learning beyond one-on-one conversations. Content takes many forms: blog posts, documentation, tutorials, videos, podcasts, conference talks, books, and social media. Each format serves different purposes and reaches different audiences. Use them all.

This topic of learning should be related to your university engagement programs. While you are at universities you are creating relationships with professors and administrators. That’s the perfect time to engage them in your project’s learning programs so they can have better teaching resources for their classes. For example, the Java project at Oracle has education programs to update the Java language itself to make it easier for students to learn, the project has online tools for students and new developers to use, and it has an entire website at learn.java that is exclusively dedicated to learning Java. During the OpenSolaris project, the team had different learning programs but they were comprehensive as well. The point is that if you are building a community, make learning a core value so you can educate your community as you engage and build the community.

Podcasts and video interviews are powerful tools for building community because they capture stories and voices in ways that text cannot. When people hear someone talk about their journey, their struggles, and their successes, they connect on a human level. This builds relationships and trust. It also preserves institutional knowledge that might otherwise disappear. Record your conversations with contributors. Document your community’s history. These become valuable resources for newcomers and reminders for longtime members about why the community matters.

Create content consistently. Regular output keeps your community engaged and attracts new people through search and social sharing. But don’t sacrifice quality for quantity. One excellent piece of content that people reference for years beats ten mediocre posts that nobody remembers. Focus on solving real problems and answering real questions. Listen to what people are asking. That tells you what content to create.

Encourage community members to create content too. Not everyone will want to or should. But those who do become ambassadors and leaders. Support them. Share their work. Give them platforms to speak and write. The more voices your community has, the stronger it becomes. And remember that content creation is itself a form of contribution. Treat it with the same respect you give to code contributions. Both are essential for healthy communities.

20. Business Models and Sustainability

Communities need resources to survive. Someone has to pay for infrastructure, events, travel, and people’s time. Understanding how your community will sustain itself financially is not optional. It’s essential. Many communities fail not because of technical problems but because they run out of money or burn out the volunteers keeping things running.

Different models work for different communities. Some communities exist within corporations where the company funds everything as part of their business strategy. The company benefits from the ecosystem and community contributions, so they invest in maintaining it. This works when corporate interests align with community interests. It fails when those interests diverge or when corporate priorities shift.

Foundation models provide another approach. Organizations like the Apache Software Foundation, Eclipse Foundation, and Linux Foundation host projects and provide governance, legal support, and infrastructure. They fund operations through membership fees from companies that benefit from the projects. This creates stability and independence from any single company. But it also adds overhead and requires projects to fit within foundation structures and policies.

Some communities rely on donations and sponsorships. This works for smaller projects or those with passionate user bases. But it’s unpredictable and hard to scale. Others offer commercial products or services built on the open source project. Red Hat built a billion-dollar business on this model with Linux. Many others have followed. The key is finding a model that provides sustainable funding without compromising the open nature of the project.

Think about sustainability from the start. What resources do you need? Where will they come from? What happens if that source disappears? Build redundancy into your funding model if possible. And be transparent with your community about finances. People understand that communities need money to operate. What they don’t tolerate is hidden agendas or sudden changes that put the community at risk.

21. Metrics

You need to measure what matters. Metrics help you understand if your community is growing, healthy, and productive. They help you make decisions about where to invest time and resources. They help you demonstrate value to executives and sponsors. But measuring the wrong things or obsessing over numbers can damage your community. Be thoughtful about what you track and why.

Marketing professionals can help quantify what metrics to collect. They understand how to measure reach, engagement, and conversion. They know how to present data to executives in ways that secure resources. Work with them to design metrics that serve both community goals and business goals. Just make sure the metrics reflect genuine community health, not just impressive numbers for presentations.

Some metrics are obvious. Number of contributors, commits, downloads, active users, and mailing list subscribers all tell you something about scale and growth. But these numbers don’t tell you about health or sustainability. A project with a thousand contributors but only ten active ones has a problem. A project with declining downloads might be mature and stable, not dying. Look deeper than surface numbers.

Quality metrics matter more than quantity. How many contributors are still active after six months? How quickly do you respond to new contributions? How long do pull requests sit before review? Are new contributors becoming maintainers? These questions reveal community health better than raw counts. A small active community often accomplishes more than a large passive one.

Track engagement patterns over time. Sudden drops or spikes usually signal something important. Maybe a major contributor left. Maybe a competitor launched. Maybe your conference generated new interest. Metrics help you spot these changes and respond appropriately. But don’t let metrics drive everything. Some of the most important community work is hard to measure. Mentoring newcomers, resolving conflicts, and building relationships don’t show up in dashboards but they’re critical for long-term success.

Be honest about what metrics can and cannot tell you. They provide data, not understanding. You still need to talk to people, observe interactions, and use judgment. Metrics inform decisions but they don’t make decisions. Use them as tools, not as answers. And remember that gaming metrics is easy and destructive. The moment you make a metric a target, people optimize for the metric instead of the underlying goal. Keep your focus on building a healthy community, not hitting numbers.

22. Legal

Are you familiar with all the legal issues you will encounter while building your community? Get to know trademarks, copyright, contributor agreements, source code licenses, content licenses, patents, contracts, and any other legal issue related to your field. Getting these things right can help your community grow by enabling contributions. Getting them wrong can stop things fast. Engage some lawyers. Teach them about the needs of the community, and ask them to teach you the realities of the law. The education should always go both ways.

Licenses matter enormously in open source communities. The license you choose affects who can contribute, how they can contribute, and what they can do with the code. Different licenses serve different goals. Some are permissive and allow almost anything. Others are copyleft and require derivatives to remain open. Some are designed for corporations. Others protect individual contributors. Research your options carefully. Talk to other projects with similar goals. Understand the implications before you commit.

Contributor agreements protect both the project and the contributors. They clarify who owns what and what rights everyone has. Some projects use Contributor License Agreements that grant the project rights while contributors keep ownership. Others use Copyright Assignment where contributors transfer ownership. Still others rely on inbound equals outbound models where contributions come in under the project license with no additional agreements. Each approach has tradeoffs. Choose what fits your community’s needs and governance model.

Trademarks protect your project’s identity and reputation. They prevent others from claiming to represent your project or creating confusion in the market. Register your trademarks early and enforce them consistently. But don’t be heavy-handed about it. Communities need flexibility to use project names for user groups, conferences, and related activities. Create clear trademark policies that enable community use while protecting against abuse.

Legal issues can seem overwhelming but they’re manageable if you address them early. Don’t wait until you have a problem. Set up your legal framework properly from the start. It’s much harder to change licenses or contributor agreements after you have hundreds of contributors. Get legal help. Most foundations and large projects have lawyers who understand open source. Learn from them. And remember that legal structures should enable community building, not obstruct it.

23. Lessons from Non-Tech Communities

Software communities did not invent community organizing. People have been building movements, organizations, and communities for thousands of years. Looking beyond technology reveals patterns and principles that apply universally. Understanding how non-tech communities operate gives you perspective and tools that most people in open source never consider.

Labor unions offer powerful lessons about organizing people with shared interests against entrenched power. Unions understand that collective action requires trust, clear communication, and demonstrable wins. They know that people participate when they see tangible benefits. They build solidarity through shared struggle and mutual support. Union organizers are experts at identifying natural leaders within groups, training them, and distributing authority. They understand that organizers facilitate but don’t control. The parallels to open source community building are striking. Contributors have shared interests. They need to organize collectively to influence corporate and foundation decisions. They need visible wins to maintain momentum. They need distributed leadership to scale.

Marshall Ganz developed organizing principles that transformed community organizing in America. Working with Cesar Chavez and the United Farm Workers, Ganz created training programs that taught ordinary people how to organize their communities. His approach emphasizes storytelling as a tool for building commitment, relationship building as the foundation of organizing, and structured one-on-one conversations as the way to identify leaders. Ganz’s methods spread through political campaigns and social movements. His framework of public narrative (story of self, story of us, story of now) helps organizers articulate why people should care, why they should act together, and why they should act now. These same principles apply to building developer communities. Your story matters. The community’s shared story matters. The urgency of action matters.

The civil rights movement in the United States led by Martin Luther King Jr. demonstrates the power of nonviolent resistance and moral clarity. King understood that movements need both a clear vision of what they’re fighting for and practical tactics to get there. He combined inspiring speeches with meticulous planning and training. He built coalitions across different groups with different interests. He maintained discipline in the face of opposition. His movement succeeded not just through moral force but through careful organization and strategic action. Open source communities face different challenges but the principles apply. You need vision and values that people can rally around. You need practical ways for people to participate. You need coalition building across companies, countries, and cultures. You need resilience when things get difficult.

Mohandas Gandhi’s work in India shows how mass movements can succeed through sustained nonviolent action and building parallel institutions. Gandhi didn’t just protest British rule. He created alternative systems, communities, and practices that demonstrated Indian capability and self-sufficiency. He built what he wanted to see rather than simply criticizing what existed. He empowered individuals to take action themselves rather than waiting for leaders to solve everything. This approach of building what you want to see rather than just criticizing what exists applies directly to open source. Don’t just complain about proprietary software. Build free alternatives. Don’t just critique corporate control. Create community governance. Don’t wait for permission. Start building.

Gene Sharp studied nonviolent action and documented how ordinary people can challenge oppressive power structures. His book “From Dictatorship to Democracy” outlined 198 methods of nonviolent action and became a handbook for democratic movements worldwide. Sharp understood that power depends on obedience and that withdrawing cooperation undermines authority. His work influenced movements from the Arab Spring to the Occupy movement. For community builders, Sharp’s insights reveal how communities can resist harmful decisions by corporations or foundations. Communities have power through their participation, their code contributions, and their adoption of technology. When communities withdraw cooperation, power structures must respond. Understanding this dynamic helps communities negotiate from strength rather than supplication.

Grace Lee Boggs spent seven decades building community in Detroit and thinking about social transformation. She moved beyond traditional organizing to emphasize the need to transform ourselves as we transform society. Boggs argued that communities must create the future they want through everyday actions, not wait for revolution or policy changes. She focused on building local institutions, growing food, educating children, and creating culture. Her work in Detroit showed how communities could rebuild from collapse by focusing on relationships, self-reliance, and mutual aid. For FOSS communities, Boggs reminds us that the community we build is the world we create. If we want collaborative, generous, innovative communities, we must embody those values in how we interact daily.

Thich Nhat Hanh, the Vietnamese Zen Buddhist monk, built communities focused on mindfulness and engaged Buddhism. He created monastic communities and secular mindfulness communities around the world. His teaching emphasized that every action bears your signature, that how you do anything reflects who you are. For community builders, this perspective matters enormously. The culture you create emerges from your daily actions, not your mission statements. If you want a welcoming community, welcome people. If you want a generous community, be generous. If you want a respectful community, show respect. Your signature on everything you do shapes the community that grows.

Noam Chomsky’s work on power structures and manufactured consent reveals how institutions shape discourse and limit possibilities. While primarily known as a linguist and political critic, Chomsky’s analysis of how power operates helps community builders recognize when corporate or institutional interests distort community goals. His emphasis on intellectual self-defense and questioning authority encourages communities to think critically about whose interests are served by community decisions. FOSS communities need this critical perspective to resist capture by corporate interests while still collaborating productively with companies.

The Amish provide an unexpected but valuable example of intentional community building with clear values and boundaries. The Amish are a Christian community primarily located in Pennsylvania, Ohio, Indiana, and several other American states. They maintain strong communities by being explicit about what they value and making conscious choices about what technologies and practices to adopt. They don’t reject all change but they evaluate change against their core values. They prioritize community cohesion over individual convenience. They build resilience through self-sufficiency and mutual aid.

The Amish are famous for barn raisings where entire communities come together to build structures in a single day through coordinated collective effort. Everyone knows their role. Everyone contributes according to their ability. The work gets done through cooperation, not competition. After Hurricane Helene devastated western North Carolina in 2024, thousands of Amish volunteers traveled from Pennsylvania to help rebuild homes, businesses, and bridges in towns like Chimney Rock and Bat Cave. Over 2,000 volunteers worked for months clearing debris, repairing roofs, building tiny homes for displaced families, and restoring infrastructure, all without compensation. Their commitment came from faith and community obligation, not external reward.

Open source communities can learn from this deliberate approach to culture, collective action, and mutual aid. What are your community’s core values? What practices serve those values? What technologies or processes might harm community cohesion even if they’re individually useful? Being intentional about these choices creates stronger communities. The Amish also demonstrate that communities thrive when mutual aid is expected and delivered. When disaster strikes, people show up. When work needs doing, people contribute. This ethic of reciprocal obligation strengthens bonds and builds resilience.

These examples share common themes. Successful communities require clear values, distributed leadership, practical ways for people to contribute, visible wins that maintain momentum, resilience in the face of setbacks, and intentional culture building. They empower individuals while building collective strength. They balance idealism with pragmatism. They understand that organizing people is fundamentally about relationships, trust, and shared purpose. The tools may differ between a labor union, a civil rights movement, an Amish community, and a FOSS project, but the human dynamics are remarkably similar.

Community building across all these contexts follows recognizable patterns. Leaders emerge through action, not appointment. Trust develops through consistent behavior over time. Norms evolve to serve group needs. Reputation systems emerge to track who contributes and who doesn’t. Reciprocity expectations shape behavior. Conflict resolution mechanisms develop to handle disputes. These patterns repeat because they reflect how humans organize regardless of the specific domain.

Technology communities would benefit from studying these movements more deeply. Read about community organizing. Study social movements. Understand how unions work. Learn from intentional communities. The skills translate directly. If you can organize a labor action, you can organize a conference. If you can build a mutual aid network, you can build a mentorship program. If you can create shared values in a religious community, you can create shared values in a developer community. The medium changes but the methods remain constant.

24. Lessons from Biology and Evolution

Community building did not emerge with the internet or even with human civilization. The impulse to form groups and cooperate is written into our biology. Understanding these evolutionary foundations explains why communities form naturally, why they struggle to scale, and why certain organizing principles work across all human endeavors.

For millions of years, humans who failed to form groups and cooperate died. Isolation meant death in ancestral environments. Our brains evolved specifically to handle social relationships because group living was the only reliable path to survival. Social bonds helped early humans meet daily challenges that no individual could face alone. Sharing food, caring for infants, defending against predators, and building social networks were not cultural choices. They were biological necessities. Those who collaborated effectively survived and reproduced. Those who did not perished.

Cooperation runs deeper than culture. It operates at every level of biological organization. Genes cooperate in genomes. Cells cooperate to form organisms. Every multicellular being, including humans, exists because of cooperation at the cellular level. Throughout human evolution, natural selection favored psychological traits that support cooperation. We developed the capacity to form trust relationships, recognize reciprocity, internalize social norms, and experience emotions like shame and guilt that enforce group standards. We carry this evolutionary inheritance whether we build software communities or farm cooperatives.

But biology also imposes limits. Research suggests humans can maintain stable personal relationships with roughly 100 to 200 people, a finding known as Dunbar’s Number. This limit appears connected to the size of our neocortex and reflects constraints that governed human social groups for hundreds of thousands of years. Hunter-gatherer bands typically numbered 30 to 50 people. Neolithic villages averaged around 150 residents. Roman military units organized into companies of 100 to 200 soldiers. Even modern organizations like Gore-Tex famously cap their facilities at 150 people because beyond that threshold, people lose the sense of community and can no longer remember faces and names.

This is where biology meets management. Groups larger than 150 to 200 people require imposed structure to maintain cohesion. They need formal rules, hierarchies, enforcement mechanisms, and institutional frameworks. Without these management systems, large groups fragment naturally into smaller units where people can maintain the direct personal relationships that our brains evolved to handle. This is not a failure of community. This is biology asserting itself.

The evolutionary perspective reveals why certain community building strategies succeed. Transparency works because humans evolved to assess trustworthiness through repeated observation of behavior. Meritocracy works because ancestral groups survived by recognizing and rewarding those who contributed most effectively. Reciprocity works because our psychology expects mutual benefit in cooperative relationships. Distributed leadership works because human groups naturally develop nested hierarchies with different levels of intimacy and commitment. These patterns emerge repeatedly because they reflect how our minds work and how our species survived.

Understanding evolutionary constraints also explains common failures. Communities that grow too quickly without developing structure fragment into factions. This happens because people cannot track relationships beyond a certain threshold. Communities that rely solely on altruism struggle because pure altruism contradicts individual survival interests. Communities that ignore reputation systems fail because reputation is how humans assess trustworthiness in the absence of repeated personal interaction. Communities that suppress conflict entirely create dysfunction because conflict resolution evolved as a crucial social skill.

The implications for FOSS communities are direct. You are working with millions of years of evolved psychology. The impulse to form groups is built into us at the deepest level. So is the cognitive limit on how many people we can truly know. Your job as a community builder is to harness the natural drive to cooperate while creating structures that allow communities to scale beyond what biology alone permits. Work with human nature, not against it. Provide ways for people to build trust through transparency. Create systems that recognize and reward contribution. Enable reputation to spread through networks. Structure large communities into nested smaller groups where direct relationships can form. Design governance that feels fair because it mirrors patterns humans evolved to accept.

The biological foundations remind us that community building is serious business. These patterns run deep. They shaped human survival for millions of years before we built cities or wrote software. Ignoring them leads to predictable failures. Respecting them creates communities that feel natural even when they operate at scales our ancestors never imagined.

25. Final Thoughts

Building communities is hard work. It requires patience, persistence, and a genuine commitment to people. You will face setbacks. People will disappoint you. Projects will fail. Conflicts will emerge. Resources will run out. That’s normal. Keep building anyway.

The mechanics and management processes of building software communities are similar to the general concepts of community organizing and activism. You can learn from people like Gene Sharp, Noam Chomsky, Marshall Ganz, Mohandas Gandhi, Martin Luther King Jr., Thich Nhat Hanh, and Grace Lee Boggs. These people all built communities. There are many others obviously, but once you dig into these figures you’ll find many more. Tastes may vary, a lot, but you’ll see the similarities and differences immediately when you intentionally look at a variety of people who build communities or who engage in activism.

Community building principles apply not only to building communities but also to building all organizations for any purpose whatsoever. Don’t leave out leaders and managers from diverse fields like the military, politics, unions, universities, nonprofits, and corporations. And don’t just focus only on the good people. The bad ones organize too. Read Machiavelli. And many others. Understanding how power works and how organizations function gives you tools to build better communities.

The lessons from non-technical movements remind us that organizing people follows common patterns whether you’re building a labor union, a civil rights campaign, or a software community. Study how others have organized masses of people toward shared goals. From Marshall Ganz’s organizing principles to Gene Sharp’s methods of nonviolent resistance, from Grace Lee Boggs’s focus on local transformation to Thich Nhat Hanh’s emphasis on how every action bears your signature, these leaders understood that community building is fundamentally about relationships, trust, and shared purpose. The Amish demonstrate intentional culture building and collective action through barn raisings. Gandhi showed how to build parallel institutions that demonstrate capability. Martin Luther King Jr. combined moral clarity with meticulous planning and coalition building. These movements succeeded because they understood human nature and worked with it.

The evolutionary foundations of cooperation remind us that community building is not a modern invention. For millions of years, humans have faced the same fundamental challenge: how to coordinate action among individuals for mutual benefit. The tools have changed from spoken language around fires to digital platforms spanning continents. But the underlying dynamics remain. People still need to know who they can trust. They still form reciprocal relationships. They still create and enforce norms. They still organize into nested groups. These patterns emerge because they reflect how our minds work and how our species survived.

Remember that everything you build is temporary. Communities change. Technologies evolve. People move on. The OpenSolaris project taught me that lesson painfully. Six years of work ended abruptly when Oracle acquired Sun Microsystems. Thousands of contributors. Millions of lines of code. A global community. Gone. But the lessons remained. The relationships remained. The skills remained. Nothing is wasted if you learn from it.

Build with the understanding that what you create today plants seeds for tomorrow. The students you mentor become the leaders who mentor others. The documentation you write helps people you’ll never meet. The culture you establish shapes communities long after you’re gone. This is how communities survive and grow across generations. Your individual contribution matters even when you can’t see the full impact.

Finally, building communities is an opportunity for you personally. It develops skills that benefit your entire career. It expands your network globally. It builds your reputation in ways that open doors. It gives you purpose and meaning beyond just writing code or shipping products. The reciprocal relationships you build in communities create value that compounds over time. You help others and they help you. Everyone grows together. That’s the opportunity. That’s why it’s worth the effort.

Presentations on Building FOSS Communities

Conference sessions on building and contributing to FOSS communities, Java, and OpenSolaris.

John Gage, Eric Schmidt, James Gosling, Andy Bechtolsheim, and Bill Joy during the 2019 Sun Reunion.

References on Building FOSS Communities

Here are resources on community building, activism, career development, leadership, learning, and personal effectiveness.

Books on Community Building and Open Source

Art of Community by Jono Bacon
People Powered: How Communities Can Supercharge Your Business, Brand, and Teams by Jono Bacon
Cathedral and the Bazaar by Eric Raymond
The Cluetrain Manifesto by Rick Levine, Christopher Locke, Doc Searls, and David Weinberger
Open Sources: Voices from the Open Source Revolution by Chris DiBona, Sam Ockman, and Mark Stone
Open Sources 2.0: The Continuing Evolution by Chris DiBona, Mark Stone, Danese Cooper
Rebel Code: Linux And The Open Source Revolution by Glyn Moody
Forge Your Future with Open Source by VM (Vicky) Brasseur
Understanding Open Source and Free Software Licensing by Andrew M. St. Laurent
The Wealth of Networks: How Social Production Transforms Markets and Freedom by Yochai Benkler
Working in Public: The Making and Maintenance of Open Source Software by Nadia Eghbal
Producing Open Source Software by Karl Fogel

Books on Social Movements and Organizing

Rules for Radicals by Saul Alinsky
The Power of the Powerless by Václav Havel
Letter from Birmingham Jail by Martin Luther King Jr.
Gandhi: An Autobiography by Mohandas Gandhi
Community: The Structure of Belonging by Peter Block
Amish Society by John A. Hostetler

Organizations and Foundations

Programs and Communities

Contributing and Participation Guides

Open Source Guides
How to Contribute to Open-Source Projects: A Handbook for Beginners
Contribute to OpenJDK
Contribute to Dev.java
Contributing to the Java Community & the Java Japan User Group by Jim Grisanzio (video)
Contributing To The Linux And FOSS Community
Participating in Open Source Communities
How to Be a Responsible Open Source Citizen by Ivar Grimstad (video)
Try The Java Playground

Corporate Open Source Resources

Open Source and Community Building by Arun Gupta and Jono Bacon
Fostering an Open Source Culture by Arun Gupta (video)
How to build open source culture in your company by Arun Gupta
Oracle FOSS Projects
TODO Group

Photography and Visual Archives

FREESOULS Captured & Released by Joi Ito
Faces of Open Source by Peter Adams Photography
Danese Cooper: Faces of Open Source
James Gosling: Faces of Open Source

Wisdom and Philosophy

Robert Greene on the Wisdom of the Stoics by Daily Stoic (video)

Tools and Learning Resources

Anki App (spaced repetition for learning)

Evolutionary and Biological Foundations of Human Cooperation

Culture and the evolution of human cooperation – PMC research article
The evolution of human cooperation – ScienceDirect
Two Key Steps in the Evolution of Human Cooperation: The Interdependence Hypothesis – Current Anthropology
Evolutionary Explanations for Cooperation – ScienceDirect
The Evolutionary Benefits of Cooperation – The Leakey Foundation
The evolution of human cooperation – Journal of Bioeconomics
High Cost of Survival Promotes the Evolution of Cooperation – MDPI
Cooperation and Competition Were Primary Driving Forces for Biological Evolution – Karger Publishers
Social Life – Smithsonian Institution Human Origins Program
Cooperation as a causal factor in human evolution – Journal of Biological Education
What went wrong when society grew beyond Dunbar’s number – Daniel Schmachtenberger and Lex Fridman (video)

Dunbar’s Number and Group Size Limits

Dunbar’s number – Wikipedia
‘Dunbar’s number’ deconstructed – PMC (Biology Letters, 2021)
‘Dunbar’s number’ deconstructed – Biology Letters (original journal article)
New study deconstructs Dunbar’s number – ScienceDaily
Dunbar’s Number, Psychological Safety and Team Size – Psych Safety
What Is Dunbar’s Number? – Brian D. Colwell
The end of Dunbar’s number: Have our social networks changed for good? – The Oxford Scientist
Size matters: The link between social groups and human evolution – Research Outreach (interview with Robin Dunbar)
The Power of Dunbar’s Number: Thriving in Groups of 150 – The Geeky Leader
Dunbar’s Number: A Simple Summary – PeopleShift

Jim Grisanzio with the Taiwan Java User Group in Taipei in September 2024.