GPG Fingerprint: D2B1 7F9D A23C 0A10 991A F2E3 D9EE 01E4 7852 AEE4
OTR Key: 83DFF1C9 95252513 D430604F 5E244CCC C8795B4B

Save Co.Up

Story Time: When I was new in Berlin in 2007, I had worked from home as a freelance consultant for many years and I was ready to think about getting an office. One of the reasons why I was moving to Berlin was to have more opportunities to meet likeminded people.

In the city I moved to Berlin from, that is otherwise lovely, everybody was very much doing their own thing. Open source and community was not a topic at the time, and I didn’t feel rooted enough to start something. From Berlin I knew there was a PHP user group that people I knew regularly attended. That sounded exciting to me, I wanted to be part of something like that. One day, I found myself in a U-Bahn towards RailsConf EU randomly meeting @langalex on our way to RailsConf EU and we started talking. His company with @freaklikeme had just moved moved into a new office space, but they had a few desks to spare. At the time coworking wasn’t really a thing, but we had heard of it, so the idea to move in with them made immediate sense. Some time in 2008 I became the first renter of what was later to become @co_up. Soon joined by…

Soon joined by now Berlin veteran luminaries like @kriesse, @klimpong and @roidrage we had a lot of fun working our respective jobs, share lunches in good company and exchange knowledge about the technologies we were interested at the time. @langalex positively spent weeks teaching me git on the side.

At the time, I had occasion to go to California where I met @dreid, who I knew from my open source work on Erlang and CouchDB. He introduced me to the concept of a Super Happy Dev House (SHDH). Basically a weekend of hacking on fun stuff at the office.

One of the most mindblowing (to me at the time) things about SHDH was that it came with instructions on how to run your own: I thought how hard can it be? We have a nice office space, we had many friends who might be up for it.

So we ran one. Introduction and recap links: It was a great success.

I met many fun people there over the weekend, many of which are still active in Berlin actively doing community work. In the recap, you can read about how the @SoundCloud founders popped by and hacked up a web-iTunes using jQuery UI on top of their API.

Just to highlight a single connection here, every single developer event I have done in Berlin that required sponsorship has since been supported financially by SoundCloud. And all attendees have countless of similar stories each.

Long story long: we caught a first glimpse of what benefits to the community it had to run open and accessible events, and we all would double down hard after this.

Our little office community quickly outgrew the original office space and we started looking for a larger place and settled eventually on what became the original @co_up: a larger coworking space, and success didn’t stop there.

On top of the coworking, we also kept organising events, like @berlinjs and @upfront_ug, which have since long been surpassed in number and frequency by multiple events every week (h/t’s @rmehner @sheley @carolstran. And most recently the inaugural @queerjs (h/t @nikkitaFTW.

A few years in, we again could make good use of a larger office space and a new floor had opened up in the same building and put up a little fundraiser to be able to cover renovations. In particular, we ordered custom-built folding tables that allowed us to transform the floor from coworking by day into a meetup space by night in the matter of five minutes. The @co_up third floor you all know and love today was born and we started to run events down there, and kept the coworking separate on the fifth floor.

One special one-off event, heavily inspired by the @RailsGirls project, we ran a JavaScript for Absolute Beginners workshop (JSFAB. h/t to @theophani and @marijnjh for the inaugural teaching materials

JSFAB brought willing learners and willing teachers together in a safe space to enjoy technological education. For free. Even while planning the event, it became clear that this model of well-educated people with well-paid jobs using their privilege giving back to the community wasn’t limited to JavaScript, and Open Tech School was born at the same time, as an umbrella organisation for community-teaching, but for any topic.— Open Tech School is worth its own thread, but they have run many hundrends of meetups for any and all topic imaginable. They’ve enhanced the initial teaching weekends with continuous learning groups that kept people growing, a proper, completely volunteer run school, for anyone, for free.

I frequently get asked about how to transplant, for example, @berlinjs into another city, and while donated office space is often available, there is usually a commercial quid-pro-quo, when a company opens their doors, which often is to the detriment to the event itself.

My first reaction usually is: well, for starters, you need a @co_up. A not-for-profit community space, centrally located, lots of tasty street food nearby (so you can avoid terrible pizza sponsorships), that is free to use for free community events. That’s then usually where the conversation stops, and I have to reflect that what @langalex and @freaklikeme have set up with @co_up and what the rest of the community has done to run with that is properly unique.

I am no longer able to remember and recount all the magical things that happened when one community or another came together. 10s of 1000s of people have been through @co_up events. 1000s have used events at @co_up as a first step into the community, like I did with PHP all those years back. Again 1000s have found new friends, new employers, new co-founders, even new partners and the collective benefit of bringing all these people together in the past 12 years is immeasurable.

Unfortunately, as you already know, capitalism. All this success has downsides. One of which is property speculation in the city going rampant. We finally have a rent break in place, but that’s after rent hikes of over 2x in 10 years just a few blocks away from @co_up.

Over the years, we have seen the building @co_up is located in transform from predominantly producing industry to IT. A lot less of which likely would have happened, if @co_up didn’t prove the viability of the location. None of that, however, counts today.

The @co_up third floor rent is getting jacked up significantly in January and @co_up is running a fundraiser to get the community to support paying the new rent. For me, this is an extreme no-brainer. Even after moving out of @co_up, @neighbourh00die kept supporting it.

From what I can tell, the fundraiser is mainly supported by individuals who experienced the benefit of a not-for-profit event space first hand and this warms my heart. However, the funding goal is mere peanuts for Berlin’s well-funded tech companies and startups.

The equation that supporting @co_up quickly amortises your recruiting costs, some of which are many times the monthly rent required to keep @co_up open, seems not to sink in.

Aside from a few trusted partners, Berlin’s startups are, unsurprisingly, happy to exploit the free support system, but I think it is a disgrace. If your company has any budgets left for 2019, or if you are ready to commit, even just a little monthly donation (say 100€), you can help make one of the pillars of Berlin’s community sustainable for the long term. Give generously, and #SaveCoUp. Take a minute to scroll through the hashtag and see how many people, how many user groups and meetups you could be supporting.

Bonus Story

One more bonus story. In 2015 during the West African Ebola crisis, a non-profit running vaccination programs in the region started setting up a development team in Berlin to be able to move faster. because @co_up was a natural fit for such a team, they settled quickly.

At the time, the Ebola-affected countries were dealing with many compounding crisis, including a lack of infrastructure. The non-profit set out to build tools to help first responders that turned pen-and-paper-based processes into mobile web apps.

That allowed first-responders to help more people faster, and make their work more organised and collaborative. When trying to contain an epidemic, time and speed are a factor.

Because of the lack of infrastructure, the team had already settled on @CouchDB and @pouchdb for their technological foundation, because no other technology was readily available and open source that would allow them to quickly build mobile web apps that worked offline.

One day over lunch, they asked around if the others at @co_up knew anyone who knew @CouchDB. As @CouchDB project management chair and longest standing contributor, I’ve had talked to each and every person at @co_up about it, if they didn’t stop me quickly enough and so we quickly got put together.

In the course of about 12 months, my team at @Neighbourh00die and I fully joined @eHealth_africa to build out the Berlin development team. We grew from ~6 to 29 in the course of six weeks and helped build tools that eventually ensured that the Ebola endemic could be stopped.

We also worked on the apps that ran the first clinical trial that later lead to the first Ebola vaccine in history.

A lot of things came together to make this happened, but if it weren’t for @co_up, it would likely have gone a lot slower.

Community Legacy

Berlin’s most influential & groundbreaking coworking space Co.Up is closing shop. Their famous event space remains open.

As Co.Up’s first ever renter, nine years ago, about a year before it even became Co.Up, I feel obliged to say a few words. This is, however, not a eulogy.

On the surface, a coworking space is office space with tables for rent, and there’s at least one in every major city today. When what eventually become Co.Up started in fall of 2008, coworking was decidedly not a thing, not usual, not common.

Of course, people have shared office space since there was office space, but a dedicated office sharing culture, a notion of a temporary home for digital nomads with globally shared values, that was new. And Co.Up was at the forefront of this now ubiquitous movement.

sad to hear about the closing of @co_up as a coworking space. your atmosphere was formative for me. thank you, @freaklikeme and @langalex. — @electricgecko

In the past ten years, and without hyperbole, Co.Up has been the foundation and nurturing space for sustainable communities that started with technology, but now spans culture, education and the arts.

How is Co.Up different from other coworking spaces in this regard? The openness and willingness to try things that are different, that are unconventional, but ultimately the right thing to do.

Co.up was born out of the desire of Upstream founders Alex & Thilo to have a nice office they can share with others. Alex’s & Thilo’s community involvement made it an attractive space for other technologists to hang out. Later, and with Aleks’s initiative and support, other communities found a home at Co.Up.

These communities and the coworkers participating in them enabled thousands of people per year to connect, start out their careers in Berlin, find jobs, find partners in crime^Wbusiness, found companies, start user groups. Even OpenTechSchool, a global initiative in volunteer education, has its roots at Co.Up. On top of all this, countless friendships have found a beginning at Co.Up that have since long outlived the confines of the offices at Adalbertstraße. And this is only a tiny sliver of groups that started out at Co.Up.

Thanks co.up for being my work home for many years, for all the people I got to meet, and everything you did for the community :’( — @kriesse

Co.Up’s probably most radical initiative was the opening of a 100+person event space that was free for events that were open to the public. I keep meeting folks that say they want to start something and they need place to meet and every time it comes down to Co.Up’s generosity to support the Berlin communities pro-bono that enables so much. In other cities and contexts, the deal usually involves a commercial involvement, hindering many initiatives.

Luckily, Co.Up’s event space remains open.

Met lots of great people by way of @langalex and @freaklikeme, and the team at @co_up. All the best on their next journey. — @klimpong

Personally, I’ve given up my desk at Co.Up in 2015 after founding Neighbourhoodie and needing a space of our own, but we continue to support Co.Up’s event space financially, like many other Berlin companies. I’ve simply outgrown the model of a coworking space and now Upstream is going through the same transition. As they mention in their closing blog post, success is a matter of focus, and their focus is now their software business Cobot, a very successful coworking space management software, so they are still very much support the coworking community.

My thanks to Alex, Thilo & Aleks for all their hard work. Your dedication will live on in the DNA of so many Berlin communities, people, and hearts.

Understanding the Facebook vs Apache Software Foundation License Kerfuffle

Translation: French by @gnieh_

Disclaimers: I am not a lawyer. I’m not speaking for Facebook, the ASF, or CouchDB. This is a personal view on the matter.

tl;dr: Projects at the Apache Software Foundation can no longer use dependencies that are distributed under Facebook’s “BSD+Patents” license, including React.

Intent of this post

I’m trying to explain the situation in simple language and without bias. There is a lot of misinformation around this issue that I hope I can clear up here. If there is anything that I got wrong here, please do let me know.

What happened?

Why did it happen?

To understand the conflict, we need to examine what the ASF and Facebook respectively are trying to achieve with their policies and licenses.

Aside: I want to make doubly clear that I’m not trying to take sides in any of this, I’m merely explaining the underlying intentions of very dense legal texts. In my opinion, both Facebook and the ASF can do whatever they want in terms of licensing. And if their goals differ, that might lead to conflict, like in this case. That’s unfortunate, but that’s the messy world we live in.

The ASF Side

It is the ASF’s Policy, that anyone using Apache projects as a dependency for an Open Source or commercial project can do so without (m)any restrictions.

The Apache License 2.0 lists a few restrictions, briefly:

In return, the Apache License 2.0 then grants you a copyright license that lets you do whatever. This is what’s most relevant to other Open Source projects.

It also grants you a patent license, which is most relevant to commercial users of Apache projects.

As an example, this means I can take Apache CouchDB and release it as a new commercial and closed-source database JanDB. Given that I abide by the requirements mentioned in the Apache License 2.0 (as summarised above), with or without modifications, for free or for money or any other purpose I choose.

This “downstream freedom” is a major intention of why the ASF exists in the first place and is as such encoded in their policies and licenses.

Now, the Apache License 2.0 includes one more restriction and its part of the aforementioned patent license. If you are using an Apache project you can’t use any of your patents to claim that the ASF or anyone else who is using that same project is infringing on your patent without losing the patent license to the Apache Project.

In the JanDB example, if I hold a particular patent on database technology, I can’t sue any other CouchDB users over that patent, without also losing my patent license for CouchDB from the ASF. I can still sue them over other matters, including patents infringed on by other software the other companies are using.

In order to make it simpler for Apache projects to decide what kind of licenses its dependencies can have, the ASF has created a handy overview of allowed, and disallowed licenses, and everything in between. The disallowed licenses are classified as “Category X” licenses. This list includes a number of very popular Open Source licenses including the GPL family and many others.

The Facebook Side

Facebook’s focus with its BSD+Patents license is protection against so-called “frivolous” or “meritless” lawsuits. In short: if you are a big company with lots of money and exposure, enterprising assholes will try to come after you for whatever reason to legally extract some of that money or exposure. Patents are a prime vehicle for such asshattery.

The BSD+Patents license is designed to minimise these lawsuits for Facebook, and with the August 18th decision they have confirmed that this remains a high priority.

The Facebook patent clause has a similar restriction to what the Apache License 2.0 states, except, it is broader in definition. Whereas the Apache License 2.0 version specifically restricts its clause to “the Work” (say Apache CouchDB), the Facebook patent license is revoked when any “Patent Assertion” is brought up against Facebook.

So if you have a patent that you think some part of Facebook infringes upon, but is unrelated to your use of React, you lose your patent license to React when you decide to sue Facebook over that patent. In the Apache License 2.0 case, you only lose the patent license if you assert the same infringement for the project you are yourself licensing (say Apache CouchDB in the “JanDB” example).

In October 2014, Facebook switched React from the Apache License 2.0 to BSD+Patents explicitly, because it contains a broader protection and in October 2016 have confirmed their intentions in call between the ASF and Facebook.

What does that mean?

Projects at the Apache Software Foundation can not use any dependencies that are labelled as Category X by the ASF’s Legal team. This includes React + ecosystem projects that are also released by Facebook under the BSD+Patents license. Projects that already use such dependencies can not make any new releases past August 31st, 2017 including these dependencies, and have to migrate away from these dependencies now.

Affected projects are (at least): Cordova, Superset, TrafficControl, Ambari, Allura, Whimsy, Spot, Myriad, CouchDB, Lens, SensSoft, Sling (Updated August 22nd).


What are the options for ASF projects now?

  1. remove the dependency altogether, or find an alternative that has a compatible license, and deal with whatever extra work that needs to be done to make the migration.

  2. move to a plugin architecture where the BSD+Patents licensed plugin is maintained and distributed outside of the ASF, but can be added by end-users.

Aside: it is true that there are projects that have (or claim) API compatibility with React, that come with compatible licenses. “Just use X” is a common recommendation that ignores a bunch of realities:

Why didn’t the ASF do this sooner?

The ASF Legal team doesn’t proactively review any and all software licenses. This issue was brought up on April 20th, 2017, and resolved within the ASF by June 17th.

What does that mean for the license compatibility with other Apache License 2.0 licensed projects using React?


The incompatibility is between the BSD+Patents license and ASF policy.

What does this mean for my (open source or closed source) project that uses both ASF and React software.


What does this means for me/my Open Source project/my company that is using React?


Unless you are part of the ASF or another organisation that has a similar policy regarding the BSD+Patents license. There seem to be a few.

Why was RocksDB relicensed and React weren’t?

I can only speculate, but React is a much much larger target, was differently licensed from the get go, and Facebook is interested in having RocksDB support in Cassandra and seems to be contributing that work. But I wouldn’t know for sure.

Aren’t Software Patents just the worst?


But I’d rather have the ASF and Facebook be upfront about their intentions than leaving things in the dark like most other Open Source projects and companies.

Comprendre le bazar de licence entre Facebook et l’Apache Software Foundation

Note du traducteur : Ceci est la traduction du billet daté du 19 août 2017. Pour toute correction ou commentaire, contactez moi

Avertissement : Je ne suis pas avocat. Je ne parle pas au nom de Facebook, l’ASF ou CouchDB. Ce billet reflète uniquement mon point de vue personnel sur le sujet.

tl;dr : Les projets de l’Apache Software Foundation ne peuvent plus utiliser de dépendances distribuées sous la licence Facebook « BSD+Patents », y compris React.

But de ce billet

J’essaierai d’expliquer la situation en des termes simples et sans biais. Beaucoup de fausses informations ont circulé sur le sujet et j’espère pouvoir clarifier la situation ici. S’il y a quoi que ce soit que je ne rapporte pas correctement ici, faites le moi savoir.

Que s’est-il passé ?

Pourquoi cela est-il arrivé ?

Afin de comprendre le conflit, nous devons examiner ce que l’ASF et Facebook essaient respectivement d’atteindre avec leurs règles et licences.

Note: j’aimerais mettre doublement au clair le fait que je n’essaie pas de prendre position dans tout ça, j’explique simplement les intentions sous-jacentes aux textes légaux qui sont très denses. Selon moi, Facebook et l’ASF peuvent chacun faire ce qu’ils veulent en terme de licence. Et si leurs buts diffèrent, cela peut conduire à des conflits comme c’est le cas ici. C’est dommage, mais c’est le monde désordonné dans lequel nous vivons.

Du côté de l’ASF

La Politique ASF veut que chacun puisse dépendre des projets Apache pour un projet Open Source ou commercial, et ce sans (trop de) restriction.

La Licence Apache 2.0 liste quelques restrictions, en résumé :

En retour, la Licence Apache 2.0 vous accorde une licence de copyright qui vous permet de faire ce que vous voulez. C’est ce qui est le plus important pour les autres projets Open Source.

Elle vous accorde aussi une licence de brevet, ce qui est plutôt important pour les utilisations commerciales de projets Apache.

Par exemple, cela signifie que je peux prendre le projet Apache CouchDB et le redistribuer en tant que nouvelle base de données commerciale et propriétaire JanDB. Tout cela sous réserve que je respecte les exigences de la Licence Apache 2.0 (tels que résumées ci-dessus), avec ou sans modification, gratuitement ou de manière payante, ou pour tout autre but de mon choix.

Cette « liberté en aval » est la raison première de l’existence de l’ASF et est inscrite ainsi dans ses règles et licences.

De plus, la licence Apache 2.0 inclut une autre restriction qui fait partie de la licence de brevet susmentionnée. Si vous utilisez un projet Apache, vous ne pouvez utiliser aucun de vos brevets pour affirmer que l’ASF ou quiconque utilise le même projet viole votre brevet, sans perdre la licence de brevet sur le projet Apache.

Dans l’exemple de JanDB, si je détiens un brevet sur les technologies de base de données, je ne peux attaquer aucun autre utilisateur de CouchDB sur ce brevet sans perdre dans le même temps ma licence de brevet pour CouchDB accordée par l’ASF. Je peux cependant toujours poursuivre ces utilisateurs pour d’autres raisons, incluant des violations de brevet par d’autres logiciels utilisés par ces utilisateurs.

Afin de rendre plus facile la tâche de décider quel type de licences les dépendances des projets Apache peuvent avoir, l’ASF a créé un aperçu très pratique des licences autorisées et non autorisées, et tout ce qui est entre les deux. Les licences non autorisées sont classifiées dans les licences de « Catégorie X ». Cette liste inclut un bon nombre de licences Open Source très populaires dont la famille GPL et bien d’autres.

Du côté de Facebook

L’intérêt de Facebook avec sa licence BDS+Patents est la protection contre les poursuites dites « frivoles » ou « vexatoires ». En résumé, si vous êtes une grosse société avec beaucoup d’argent et une grande exposition, des enfoirés entreprenants essaierons de vous poursuivre pour quelque raison que ce soit afin de vous extorquer légalement cet argent et cette exposition. Les brevets sont un outil de choix pour ce genre de connerie.

La licence BDS+Patents est conçue afin de minimiser ces poursuites judiciaires contre Facebook, et avec leur décision du 19 août, ils confirment que cela reste un grande priorité.

La clause sur les brevets de Facebook a une restriction similaire à ce que la licence Apache 2.0 exprime, sauf que sa définition est plus large. Là où la version de la licence Apache 2.0 restreint spécifiquement sa clause au « Travail » (disons Apache CouchDB), la licence de brevet Facebook est révoquée dès lors qu’une quelconque « revendication de brevet » est portée contre Facebook.

Ainsi, si vous détenez un brevet que vous pensez être violé pas une partie de ce que fait Facebook, mais qui est sans lien avec React, vous perdez votre licence de brevet pour React dès lors que vous poursuivez Facebook sur ce brevet. Dans le cas de la licence Apache 2.0, vous perdez uniquement la licence de brevet si vous revendiquez cette violation par le projet que vous licenciez vous même (soit Apache CouchDB dans l’exemple de JanDB).

En octobre 2014, Facebook a changé la licence de React de la licence Apache 2.0 vers BSD+Patents, explicitement car elle contient une protection plus large, et en octobre 2016 Facebook a confirmé ses intentions dans un appel avec l’ASF.

Qu’est ce que ça signifie ?

Les projets de l’Apache Software Foundation ne peuvent pas avoir de dépendances classées dans la Catégorie X par l’équipe légale de l’ASF. Cela inclut React ainsi que les projets de l’écosystème qui sont publiés par Facebook sous licence BSD+Patents. Les projets qui utilisent déjà ce genre de dépendances ne peuvent plus publier de nouvelles versions après le 31 août 2017 qui incluent ces dépendances et doivent se séparer de ces dépendances maintenant.

Les projet affectés son (a minima) : Cordova, Superset, TrafficControl, Ambari, Whimsy, Spot, Myriad, CouchDB, Lens, SensSoft, Sling.


Quelles sont désormais les options des projets ASF ?

  1. Supprimer purement et simplement les dépendances ou trouver une alternative publiée sous une licence compatible et assumer tous le travail additionnel qu’une telle migration impose.

  2. Migrer vers une architecture de plugin où les composants sous licence BSD+Patents sont maintenus et distribués en dehors de l’ASF, mais peuvent être ajoutés par les utilisateurs finaux.

Note : il existe des projets qui ont (ou affirment avoir) une API compatible avec React et qui sont publiés sous une licence compatible. « Tu n’as qu’à utiliser X » est un conseil classique qui ignore tout un tas de réalités :

Pourquoi l’ASF n’a pas fait ce travail plus tôt ?

L’équipe légale de l’ASF ne relit pas de manière préventive toutes les licences logicielles. Ce problème a été soulevé le 20 avril 2017 et résolu par l’ASF le 17 juin.

Qu’est-ce que cela signifie pour la compatibilité de licence avec d’autres projets sous licence Apache 2.0 utilisant React ?


L’incompatibilité se trouve entre la licence BDS+Patents et la politique de l’ASF.

Qu’est-ce que cela signifie pour moi/mon projet Open Source/ma société qui utilise React ?


À moins que vous fassiez partie de l’ASF ou de toute autre organisation qui a une politique similaire envers le licence BDS+Patents. Il semble y en avoir quelques-unes.

Pourquoi RocksDB a été relicencié et pas React et les autres ?

Je peux seulement émettre des hypothèses, mais React est une beaucoup plus grosse cible, a été licencié différemment depuis le début, et Facebook semble intéressé par avoir RocksDB pris en charge par Cassandra et semble contribuer à ce travail. Mais je ne peux en être sûr.

Les brevets logiciels ne sont-ils pas juste terribles ?


Mais je préfère voir l’ASF et Facebook clairs sur leurs intentions que de laisser les choses dans le flou comme le font la plupart des autres projets Open Source et sociétés.

Sustainable Open Source: The Maintainers Perspective or: How I Learned to Stop Caring and Love Open Source

If you want your open source maintaining to be sustainable, you need to stop caring.

Wait what?

Nolan wrote a very in-depth description of what maintaining open source projects can feel like.

Mikeal suggests leaving projects is the solution, which I think is only the most extreme option.

I’m offering middle ground: stop caring.

I can relate to everything that Nolan is saying and I must know that Mikeal’s solution is always an option in order to be able to not care effectively.

Inbox Zero Redux

Before I stop caring though, I’d like to address a flaw in how I see people apply “Inbox Zero”. Nolan uses the powerful metaphor of people in front of your door with their problems.

Just because there are people with problems in front of your door, that doesn’t mean they are your problems. You can choose to make them yours, but you want to be very careful about what to care about. Ideally you don’t care about any of these problems and none of these people (more on the people later).

Inbox Zero doesn’t mean you have to have looked at everything, or even handled everything (like replied to every email or commented on every issue), but to have sorted everything into piles that you can work on in batches (it’s more efficient from a context-switch perspective) when you have the time.

When you have the time. This implies that you have to make time to actually resolve issues coming into your inbox. This also means: if you can’t make time, these issues are not going to get handled. And the only way to be okay with this is to stop caring about the issues.

And being very good about being able to bubble to the top what you do want to take time for.

GitHub Notifications, like Email, is often treated as a world-writable todo list. This works for small number of people writing issues, but with a semi successful open source project or multiple small ones, you easily surpass this being a useful model.

As a result I treat all my open source notifications and email as: I might not get to this.


This is from my perspective of maintaining two large-ish Open Source projects: Apache CouchDB and Hoodie and many many small projects I started, or contributed to. CouchDB even went through the birth of the NoSQL database category, so on top of all the Open Source stuff, I had a nascent venture capital infused industry to deal with.

All the advice I have here is for later-stage Open Source projects. For early stage projects, care is the only thing you can give them. But once you’ve shipped version 1.0.0 or even 2.0.0, once you wrote all the documentation, once people start using the project in production with success, once you’ve talked the 100th person through getting started on IRC or Slack, your priorities have to change.

Here’s the list of things I do care about in later-stage Open Source projects:

Not Caring

Here is a list of things that come up repeatedly, with any variety of urgency, anger, and frustration:

“Hey, I found [other database] works better for me.”: Great! I don’t care.

“Hey I’m building this app / solving this university assignment, can you help me with…”: No, don’t care.

“Hey, I see you haven’t released a new version in X days/weeks/months/years”: I don’t care.

“Hey, I found problem X in your tool”: I don’t care.

“Hey, I can’t get started with your thing”: I don’t care (I’ve already written the docs).

“Hey, I reported this issue, but nobody is picking it up”: I don’t care, send a PR and it might get better.

“Hey, I opened a PR and it doesn’t get merged”: I don’t care.

“Hey, I opened a PR and it doesn’t get merged, and now I’m frustrated and I blame you for stringing me along to spend so much time on this.”: I especially don’t care about guilt-tripping.

“Hey, I read on Hacker News…”: I don’t care.

“Hey, your project is shit.”: Don’t care, insta-block.

None of this is to say that I don’t try and address these people’s issues and concerns, as much as I can, too. But on my terms and in my time, and the only thing that lets me sleep at night is not caring about any of these things. I’ll get to them eventually, some may fall between the cracks.

It’s not nice from a project or people perspective, but short of leaving the project and leaving it all behind, I found this to be the only way to make my personal Open Source maintainership sustainable.