There is No Mute Button
Growing an open source community through communication.
The sound of one hand clapping
Back in the day, when phones looked like those pictured above, there was no mute button. If you wanted to try and keep the person on the other side of the call from hearing you, you would cup your hand over the bottom part of the handset. Times change. Mute is now a prominent, and often unintentionally engaged feature in many conversations.
I gave a talk at the Open Source Strategy Forum run by FinOS Foundation in 2017 with the title “They can’t hear you on mute.” This quote is now in the Desktop Don Reference under the Communication category. The point of the talk was that sharing code on GitHub or other social coding platforms is usually a very small part of being successful in open source. You have to regularly communicate on multiple channels if you want your work to be discovered and build a community around it.
There is no mute button with successful open source projects
For developers who want to build a sustainable community around their project, there is a lot more work to be done after the code is open sourced. It’s usually not effective to only have one-on-one communication with folks about your project. That is unless the folks you are communicating with believe in your project, and are connected enough to share information about your project in forums that can help it become discovered. While it’s not impossible for this to happen, for most of us working in open source, we have to explore and leverage multiple channels to help more developers discover and engage with our projects.
The key thing to measure when working in open source over a long period of time is how much you continue to learn. If you are not learning anything, even if your project is successful, you are stagnating. After twenty-one years of working on an open source Java collections framework, I am still continuing to learn. The learning mostly comes from communicating with others, across multiple channels.
In the rest of this blog, I will share some of the things I have learned over the past decade working in open source. If you want to help others discover your work exists and convince them it is worth taking their time to investigate further, you need to start from the ground floor and build credibility in your work and yourself.
Building credibility
I spent eight years communicating to many developers and teams inside of Goldman Sachs before open sourcing GS Collections. I had successfully established that there was a potential market for a feature-rich Java collections framework. Once the project was open source, I initially only had one communication vehicle to help developers discover the project … the GitHub README.
Start with your project README.
Write the most helpful README you can about your project. This is the first window to your project that many will see. You want them to look at other things in the repo, and fork and star your project. There are projects out there that can help you write an effective README. I’m not going to claim any authoritative expertise in the README writing space. We continue to evolve our README with feedback from the community.
Build a website for your project.
Both your README and website will establish that you care about your project and show that the work is professional. Take contributions to your README and website over time. Some of the best contributions the Eclipse Collections project has received over the years are language translations of the website. There are now twelve language versions of the Eclipse Collections website. It helps to keep your website simple, so a translation takes less time to write and review. Be sure to thank those that make contributions publicly. This increases the incentives for others to want to get involved.
Talk about your project at user groups
I started communicating publicly about GS Collections and then Eclipse Collections by talking at Java User Group meetups. This helped me build credibility in smaller local Java communities. By the time GS Collections was migrated to the Eclipse Foundation and became Eclipse Collections, there were already around 1,500 stars on GitHub and 20K downloads from Maven Central.
Then both stats were reset to zero, and Eclipse Collections had to start from scratch. It took a lot of passion, patience, and persistence to recover from this branding reset.
Building a recognizable brand
There’s a lesson in here about the downsides of building credibility and then rebranding. GS Collections was just beginning to build brand recognition in the Java community. When Eclipse Collections came into existence it became part of another stronger brand with the name Eclipse. It wasn’t obvious at first, but this stronger brand would act as an unintentional mute button for Eclipse Collections over the last ten years. Eclipse is recognized as being a world-class open source IDE. Eclipse Collections would not only have to build its own recognizable brand as a world-class open source Java collections library, but would continually help reinforce the brand of the Eclipse Foundation as distinct from the Eclipse IDE. I have told literally hundreds of developers over the past ten years that Eclipse Collections is distinct from the Eclipse IDE, and is one of hundreds of projects managed at the Eclipse Foundation. I have told developers that I write all of my code contributions to Eclipse Collections using IntelliJ IDEA, and have used IntelliJ since 2002, just to illustrate the independence of the project from the Eclipse IDE. I realize every time I say this that I have been fighting an uphill branding battle. The brand of the Eclipse IDE is incredibly strong. This is deservedly so. The Eclipse IDE is an amazing open source IDE and has a strong and loyal developer community. I continue undaunted in this seemingly Sisyphean task of building brand recognition of Eclipse Collections in the shadow of the Eclipse IDE. I hope the clarification here helps some folks who were not aware of the difference between Eclipse IDE, Eclipse Collections, and Eclipse Foundation. Progress continues.
I am proud for Eclipse Collections to be a part of and contribute to the Eclipse Foundation brand. Eclipse Collections will never be as well recognized as the Eclipse IDE, and that is fine with me. I didn’t create Eclipse Collections to win a popularity contest. I created Eclipse Collections so a sustainable development community could form and grow around the project that I created and believe in. This measure of success has been met by Eclipse Collections being a project at the Eclipse Foundation.
Eclipse Collections has developed a recognizable brand over the past ten years. How do I know that Eclipse Collections has become an independently recognizable brand? I gauge this measure of success on a few metrics.
Gauging your project success
I’ve been watching several metrics around Eclipse Collections for the past decade that it has been at the Eclipse Foundation. I pay attention more to trends with these metrics than absolute numbers. I don’t think it’s helpful to compare your project to other projects, unless they are in direct competition for the same market .
GitHub Stars
The first metric is a vanity metric. This is the number of GitHub stars for the project. Eclipse Collections just passed 2,500 stars on its GitHub repository. All this really tells me is that 2,500 people have a GitHub account and stopped by the Eclipse Collections project to drop a star on the repo. GS Collections by comparison has 1,800 stars. So after starting over again at zero, I am happy at least Eclipse Collections finally passed the level that GS Collections had achieved. This took several years to achieve, so for me this feels like some form of success. Averaging out the total number over the total number of years, and the project has been receiving ~250 stars per year.
Maven Central Downloads
The second metric is more difficult to attribute than GitHub stars, but I find it more interesting. The second metric is monthly downloads from Maven Central. GitHub stars can be traced to individual GitHub accounts. I can’t trace the monthly downloads to anyone specific, and the downloads can be the result of transitive dependencies, which means the library was downloaded as part of the dependencies for another project. This doesn’t matter in my opinion. If a project uses Eclipse Collections, and folks use that project, then they are most likely using Eclipse Collections without knowing it. I believe production usage is more important than individual developer usage, but both are nice. In the chart below, we can see there were 1.2 million downloads of the eclipse-collections library from Maven Central in April 2025.
Open Source Dependencies
The third metric is the number of open source projects that depend on Eclipse Collections. This metric probably has the greatest effect on the second metric. If a popular project depends on Eclipse Collections, then it stands to reason that Eclipse Collections will see more transitive downloads due to that project’s dependency.
GitHub Traffic
The fourth metric I look at is GitHub traffic. With the standard GitHub traffic view, it’s possible to see only the past two weeks of traffic. You can see Git clones and Visitors, as well as referring sites.
Growing your community
This is where the mute button has to be turned off. There are a lot of different channels you can explore in helping to grow awareness of your project.
Writing articles
The first article I ever wrote was for InfoQ. I wrote a two part series about GS Collections. I can’t tell how much traffic has visited these articles in the past decade, but when I first wrote them, I could see how much traffic they referred to the GS Collections repository on GitHub.
Articles take a commitment of time and patience. Depending on the platform you are writing for, you will need to be prepared to write a minimum number of words in the article, and go through a formal editing process. The platform has its own brand and audience expectations to uphold.
I would recommend writing a few formal articles, at a few places. I have written articles for InfoQ, DZone, and the JVM Advent Calendar, which runs annually during the month of December.
Presenting at conferences
One of the best ways to get the word out there about your project is to give talks at technical conferences. It usually helps to build credibility around your project before presenting at conferences. This is why I suggested starting at user group meetups first. Once you have come up with a talk idea and content, it will help you potentially get your first conference talk proposal accepted. It is sometimes required to share a video of you speaking as well. If you were recorded talking at a user group meetup, this can help check off that requirement.
One of my favorite blogs about speaking at technical conferences was written by Holly Cummins. The blog is linked here:
Writing Blogs
Blogging is not for everyone. However, it is an effective medium to help get your story out there and grow a community around your open source project. After about 1,000 one on one conversations where you have to repeat the same story about your project, it will become clear that it is impossible to scale your story without some help. If you are reading this right now, you already understand the potential reach of blogging.
My recommendation is to start writing for yourself. Write down your important thoughts that you want shared about your project. Nobody else may read them at first, but you can share them to shorten the repetitive cycle of communication. As you develop your voice and see the reading metrics around your various blogs, you will learn what your audience is interested in reading. I don’t know the secret sauce for writing a hugely successful blog, other than just writing and doing it consistently. You know the things you like to read, and that keep you engaged. Write things that you would be interested in reading.
Blogging here has been one of the best decisions I have made in my professional life. I am sad that I started blogging so late in my career. If I had known the impact it would have, I would have started in my twenties. I started blogging well into my forties. There are twenty years of stories I am still having to catch folks up on, and I’ve forgotten so much already. I wish I had blogged about Clipper and Smalltalk when I was programming professionally in them. I also wish I knew about open source and got involved when I was working with them. My suggestion… save wishes for birthdays, and start writing blogs instead.
Don’t ask me for a blogging platform recommendation.I blog here, but will not recommend it as better or worse than any other platform, as I have never used any other blogging platform. Do your own research, and there are loads of opinions folks have shared. I have settled with this platform as being adequate for my needs. I have overcome some problems in the platform over the years, like how to represent tables other than using images. I use Asciidoc in GitHub gists for tables. It’s possible eventually there is a solution added to the platform. At some point Medium added support for syntax highlighting code examples. At that point, I stopped using GitHub gists for code examples and inlined them directly.
If you do decide to blog, and want to know how your blog is doing, check your blogging platform for the kind of stats it shares about your blog. I will share a picture of the Story Stats for my latest blog here on Medium, which I published five days ago. It shows the number of views and reads over time.
RSS Feeds, Email Subscribers and Blog Aggregators
Having your blog available to RSS readers and email subscribers is very useful. Make sure the blogging platform you choose supports both of these options. Different folks like finding out about things in different ways. Of the 2,300+ folks who follow me here, 55 have signed up for email subscriptions. A small percentage overall, but it is not zero. Pay attention to your audience. If they are telling you something, like clicking on a subscribe button, then listen.
My blogs are also aggregated by Planet Eclipse. There are surely a lot of other better options in this space. I signed my blog up there quite a while ago since I am an active blogger about an open source library maintained at the Eclipse Foundation.
Social Media
We used to have this amazing platform called Twitter. It was a great place for having conversations and helping build communities around open source projects . You could really get a sense of being connected with the technical community. Today we have a collection of social media options that are less engaging. To be honest, I now find LinkedIn is the most effective platform for communicating about my own projects. This is probably because I have used LinkedIn to build a professional network, and many folks who I have worked with over the years are connected with me and are active there.
I find the topic of social media a bit sad these days. The level of engagement feels like it is way down from the levels it used to be at. I use BlueSky, Mastodon, LinkedIn as the primary social media channels for sharing links to blogs, talks, project updates, etc. As I said, LinkedIn is now the most effective of these platforms that I personally use for sharing information and raising awareness. YMMV.
The platforms that often generate a burst of interest in a blog post are Reddit and Hackernews. I don’t have an account on or post to either of these platforms, but occasionally someone else will share a blog of mine there. If I see a sudden spike in traffic with thousands of views, I can tell someone has shared a blog on one of, or sometimes both of these platforms. If you use these platforms and you’re comfortable with posting on them, then maybe you have some additional options to get your ideas and project out there.
Writing Books
If your project reaches a level of success, it might be a good time to think about making an investment in writing a book. This is what I did after 20 years of working on the Eclipse Collections project. I wish I could have written the book a decade ago when lambdas first became available in Java, but I wasn’t in a position to do that at the time, as my personal life was in crisis mode. I wrote almost 200 blogs before deciding to finally take the time off to write a book. I recommend writing a book because you love your project or a specific topic, not because you hope to have a New York Times Best Seller. You most likely will not. It’s unlikely to even see a return that remotely matches your investment. I wrote a book about Eclipse Collections because I had invested 20 years of my life working on a project that I believe in and am proud of. I can point developers to 240 blogs or a Reference Guide, but I thought the project deserved a detailed story from its creator about why it has existed and evolved for 20 years.
Below is a link to my book. It is more than a story about Eclipse Collections. It is a story about one developer’s journey and his mission to share the joy of programming with other developers.
Podcasts
Up until a year ago, I steered clear of podcasts. In retrospect, this may have been a mistake. There are some great podcasts out there. I have participated in three podcasts so far. With the exception of Duke’s Corner, I knew both of the hosts of the podcasts I participated in. Some people fear writing. I have a fear of speaking publicly. I have battled this fear by doing a lot of public speaking. I always have the fear, but realize that the fear is a challenge to my own success. If I don’t use my voice, and keep the mute button on, no one else will speak for me.
I was fortunate to be asked to join three podcasts in the past year. This likely happened because I have networked and built relationships over the past fifteen years. I have kept my network active and alive by sharing information directly with people on a regular basis.
Here are links to the three podcasts I have done in the past year. I wrote blogs about the first two experiences.
While writing this blog, I realized I failed to write a blog about my third podcast. I also didn’t write an experience report about my JavaOne trip in March. This is what happens. We get busy and we forget. I was busy working on the publishing of my book and doing things in preparation for JavaOne. On the last day of JavaOne, I participated in the Community Keynote, participated in an interview livestream with Billy Korando immediately afterward, gave a talk on Data Frames with my friend , and then participated in my third podcast with Josh Long. It was a lot for one day. The third podcast is available on YouTube.
Networking
Do not go it alone. Open source is community, not just code.
Networking is so important. So many of the things I wound up getting involved with around Eclipse Collections happened because I was learning from others. There are so many talented folks out there doing amazing things and they are happy to share what they know. Thankfully, they understand the importance of taking themselves off of mute.
Networking doesn’t have to be just in public spaces. I networked with thousands of developers inside of Goldman Sachs by doing internal talks, writing internal blogs, answering questions on internal Q&A sites, and teaching many Eclipse Collections Katas over the year in both four and eight hour classes. I was challenged and learned from so many folks I worked with as well.
Your network can help you amplify your message, but only if you build meaningful long term relationships. It takes being authentic, taking time and care to build your network. Your network is not a marketing tool. Your network can help you validate if you’re having a meaningful impact in the work you are doing. If you’re fortunate, members of your network may become involved as contributors in your projects and write blogs, give talks, post/comment/like on social media.
I’ll be giving a talk at dev2next at the end of September with my friend Vlad with the title “Refactoring to Eclipse Collections: Making Your Java Streams Leaner, Meaner, and Cleaner”. I gave a talk about Data Frames at JavaOne 2025 and dev2next 2024 with him. Vlad is giving a talk about Data Frames next month at InfoQ Dev Summit Boston. I will be attending the conference and watching from the audience. I’ve known and worked with Vlad for 30 years. He’s fricken’ awesome! You should attend his talk if you’re in Boston at InfoQ Dev Summit next month! I hope to see you there in the audience. If you bring a copy of my book and find me after Vlad’s talk, I will be happy to autograph it for you in the hallway track of the conference, where some of the best networking happens.
That’s just one example of what networking and long term relationship building can do for you. There is so much more value in networking than any other thing you will ever do in your career. Take care and invest in your network.
Some final thoughts…
I hope you found something in here helpful. When we first open sourced GS Collections in 2012, the marketing and community building strategy was TBD. We had a GitHub README, and a desire to learn and grow. The project got a recognition boost the first year GS Collections was open sourced, when I presented at the GIDS conference in India and at the JVM Language Summit in California. I was a member of the JSR 335 Expert Group (Lambdas/Streams) at the time and was fairly certain lambdas would eventually make it into Java. In 2014, I would give my first talk at JavaOne on GS Collections, as well as participate in the Strategy Keynote about the potential use of Java lambdas in our code bases. I think this was the largest audience to ever hear about GS Collections, with several thousand folks in the room.
I did not have a guide to help me on the marketing and community building front with Eclipse Collections. I asked a lot of questions and tried out different things to see what worked. I shared some of the things that have helped out Eclipse Collections over the past decade. There’s no guarantee you’ll see the same results. When you try things, remember the following quote, which I learned from a senior leader at a bank I worked at.
Measure, execute, repeat.
Try different communication channels. See what works for your projects. After you do something, measure the results. If they are good, rinse and repeat.
Blogging has been the best long term investment in my opinion. Networking has helped the most in validating my efforts, helping get my stories out there, and growing the community.
I wish you success in all of your open source endeavors. Best of luck out there!
Thank you for reading!
I am the creator of and committer for the Eclipse Collections OSS project, which is managed at the Eclipse Foundation. Eclipse Collections is open for contributions. I am also the author of the book, Eclipse Collections Categorically: Level up your programming game.