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: http://termie.pbwiki.com/HowToDevHouse. I thought how hard can it be? We have a nice office space, we had many friends who might be up for it.
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.
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.
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.
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.
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.
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 :’( https://twitter.com/co_up/status/908617161308082176
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.
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.
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.
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.
vous ne pouvez pas utiliser les noms ou marques déposées d’un projet Apache ;
vous devez inclure une copie de la licence et une note indiquant que le projet en question est utilisé par votre projet ;
si vous changez quoi que ce soit dans le projet Apache, vous devez aussi le mentionner.
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.
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).
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 ?
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.
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 :
React est plus que son cœur et a un large écosystème pour de nombreuses tâches relatives à la construction d’applications web. Beaucoup de ces projets annexes sont aussi sous licence BSD+Patents et ne peuvent ainsi pas être utilisés non plus et peu ont un remplaçant compatible. Ainsi « migrer vers X » n’est pas aussi trivial qu’il n’y parait suivant le nombre d’autres projets qui sont utilisés par dessus React. À titre d’information, pour l’interface administrateur Fauxton de CouchDB, le travail de portage est estimé entre un et deux mois de travail à plein temps d’un développeur pour ne plus utiliser React. Dans notre cas, il s’agit d’un investissement en temps non négligeable qui prend un temps précieux au développeur sur d’autres sujets plus importants.
React contient un bon nombre d’innovations techniques, et certaines personnes on suggéré de migrer vers un autre framework qui contient une partie de ces innovation (par exemple JSX) mais pas toutes, incluant la compatibilité de l’API. Migrer vers un tel framework requiert sensiblement plus de travail que l’option précédente. Dans le cas de CouchDB/Fauxton, ce coût est très probablement prohibitif, mais nous explorons encore des options.
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 sembleyen 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.
Translation: French by [@gnieh](https://twitter.com/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.
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.
you can’t use the Apache project’s name or trademark(s).
you must include a copy of the license and a notice that the project in question is being used by your project.
if you changed anything in the Apache project, you need to mention that too.
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.
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).
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?
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.
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:
React is more than just it’s core, but there is a wide ecosystem for many related tasks around building web apps. Many of those related projects are also licensed under BSD+Patents, so they can’t be used either, and few or no replacements exist for those. So “moving to X” is not as trivial as it might sound, depending on the level of other projects that are used on top of React. As a point of data, for CouchDB’s Fauxton admin interface, the porting work is estimated at 3+ months of dedicated developer time for switching away from React. In our case, it’s a significant time investment that takes valuable developer time away from other pressing matters.
React includes a number of technical innovations, some folks have suggested to move to another framework that includes a subset of these innovations (say JSX), but not any of the other ones, including API compatibility. Moving to such a framework is significantly more work than the previous option. In CouchDB/Fauxton’s case, that is very likely prohibitive, but we’re still exploring options.
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 seemtobe a few.
Why was RocksDB relicensed and React et.al. 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.
If you want your open source maintaining to be sustainable, you need to stop caring.
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:
Code of Conduct violations: these are basic ground rules that govern everything we do in a project. If somebody doesn’t play along, that needs to be dealt with asap.
Security issues: once you are used in production, handling security issues swiftly and professionally is a imperative. Since they can pop up at any time, you want to be having some spare time that you can allocate to this at all times. That doesn’t have to be you individually, but as a project, you always need to be able to handle these.
Trademark violations: Apache CouchDB is a registered trademark, and within the Apache Software Foundation it is the job of the Project Management Committee to go after trademark violations. US trademark law requires action against transgressors for a trademark to be upheld. So this is something I have to do. These things aren’t as urgent as security issues, and are usually solved with a form letter.
No new contributors coming in and signs of fellow maintainer burnout: I’ve written at length about this before in Sustainable Open Source.
Do I sleep/eat/have fun/sport/partner/friends/nature enough? If I don’t function, I can’t give anything to projects or people in Open Source. Michael Bromley sums it up nicely in Why I Haven’t Fixed Your Issue Yet.
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.