The aim of this blog is to make visible the ongoing effort required to maintain the open source drag and drop project react-beautiful-dnd (rbd). The maintenance of the rbd project will look different to other open source projects, but I thought it would be insightful nonetheless. By exposing maintenance information I hope to dispell the myth that open source projects lead to less total effort then private source. There are huge advantages in open source, but the cost of ownership is not one of them.

`rbd` is popular and much loved ❤️

I have been lucky enough to work close to full time on the rbd project for almost two years at Atlassian and I am it's primary maintainer. rbd is used widely internally (Jira Software, Jira Portfolio, Jira Service desk, Trello and Confluence to name a few) and externally (Facebook, box, Zendesk and much more). It is now in the top 20 starred React projects and it one of the most downloaded drag and drop packages on the web. The package has been an ongoing source of praise for Atlassian.

The best defence is a good offence 🏈

Optimising for self-service

I have adopted strategies that aim to maximise peoples ability to get started with rbd, use rbd, and troubleshoot issues without needing to reach out directly (self-service). They include:

Created a free egghead.io quick start course to talk people through getting started with the library step by step.
Created and maintain extensive documentation
Adding development only console warnings for detectable setup issues. That way people do not need to consult the docs for most setup issues
Creating a common setup issue guide
Creating issue templates to help people to debug their own issues before reaching out
Using repeated issues as a signal for unclear documentation or a good development only warning

No open bugs 🐛❌

I have taken a fairly bold stance with rbd: I will not ship any new features while there are open bugs. This might seem unobtainable, but rbd has now been using this strategy successfully for almost two years. By keeping the quality bar high I have reduced the need for people to reach out. This lowers the amount of time I need to spend on maintenance.

Rant 🌶

It is hard to know if a bug is trivial or if it exposes a foundational issue. In order to confidently move forward with a software project we need to know that what we are building on is solid - otherwise, we can drown in fixes and rework. When people use a project they want it to work. It is okay for a project to have limitations - but to not deliver on what it claims to do is trust-destroying.

Workload 👷‍♂️

I have mentioned that I do a lot to promote self-service of rbd. However, people still do reach out for a variety of reasons. These collectively add up to a rough average of one day a week of work. The amount of effort fluctuates week to week.

Bug reports 🐛

I get about one bug report every 1-2 days. There are a few types:

Ghost issue: an issue is created without much detail or an example. I ask for more information and a demo (I provide a boilerplate demo). I then hear nothing back, ever. I need to then come in some time later and close the issue. I let them know they can reopen the issue if they provide more information.
Simple setup issue: some issues raised can be resolved by simply telling people to look at their console (as it can already be telling them what their issue is and how to fix it), or pointing them to our documentation. A large amount of these come from people who are getting started with React and rbd is in one of their first projects. So often people are fighting with React issues rather than rbd issues
Complex setup issues: sometimes bug like behaviours will be present in complex examples that people post. After a lot of investigation, I find that the answer was a simple setup issue that was hiding under layers of complexity.
Limitation hit: people hit against a documented limitation of the library. The limitation needs to be explained, and any relevant issues or documentation linked to. Sometimes this might lead to a new feature request issue being added, or additional detail added to an existing feature request.
Actual bug: actual bugs get raised and need to be fixed. I need to diagnose the bug, do a root cause analysis, design a solution, write a fix, write tests, merge the fix and do a release. Some bugs are simple problems with obvious fixes. Some expose much deeper issues. Sometimes I will release a short term fix if there is one available if I know that the correct fix will take a longer amount of effort. I will reproduce the provided example with a bug in a local environment to develop rbd against. Sometimes a bug can be fixed in an hour, sometimes two days. Sometimes it requires it change in architecture which might occur slowly over months.

Setup and limitation issues can also lead to documentation and development only warning improvements. Ideally, we make everything as clear as possible to people. I use repeating issues as a signal

Feature requests 🚀

rbd gets feature requests for a large number of interactions. These need to be run through our guiding principles and evaluated. Sometimes I think it fits into the direction of the library and keep the request open. This might be the start of a discussion as we figure out the implications and implementation details of the feature. Other times the request does not line up the direction of the project and I provide an explanation and close the issue. I might also add this information to the project philosophy page.

Discussions 🗣

We have a number of open discussion threads running at a time. This is for features and ideas that still require more thinking. These can be lengthy back and forth conversations and API, use cases, implementation, testing and implications. I often do a lot of background (shower) thinking about these.

Pull requests

We get about one pull request to the rbd project per week. There are a number of categories

Documentation fix: almost always can be easily merged
Proposed code changes: either a bug fix or new feature. Rarely created and even more rarely merged

Proposed code changes

The React team put it nicely when they said that rarely do they accept changes from external contributors. The React project has a rich history and established future direction. It is hard for an outsider to come in and make a meaningful contribution to the core library. I have found this also to be true for rbd. Changes on the fringes of the project are welcome and encouraged: documentation, build improvements, types, examples and (minor) bug fixes. But external contributors generally lack the context to make bigger changes. We do get some from time to time, but they often an attempt to meet their own goals without thinking more broadly about the library. I have found that these proposed changes are often in conflict with the accessibility or philosophy of the project. I generally encourage people to reach out before undertaking large engineering efforts to discuss what approach the change should take:

Hack: work with existing or new APIs to achieve their use case
Fork: maintain a forked version which bakes in their behaviour
Contribute: rbd could use the feature. In my experience, we have not had a single feature contributed entirely by an external. Sometimes I can shepherd through a bug fix. An additional challenge is their skill levels. On a few occasions, I have needed to rework big parts of external pull requests

Moderating 👩‍⚖️

There are 50+ active issues in rbd. They are comprised of feature requests, discussions, improvements and ideas. I monitor them to provide input and to ensure that the code of conduct is being observed. I try to respond to people within 48 hours. I also need to close old or redundant issues. I also get pinged questions through Twitter, Stack Overflow and other channels occasionally. I will either answer directly if it is simple or push them towards the project page to create an issue.

Sharing 🎁

There is some really interesting engineering in rbd. I write blogs and give talks to share my learnings and to market the rbd project. By doing this the impact of rbd is bigger than just the project itself. I will often spend 0.5-2 days writing a blog, 0.5-1 day preparing for speaking at a meetup and 3-5 days preparing for a conference talk. There is also a lot of thinking, exploring and discussions before creating sharable content.

Project related blogs

Performance related blogs

Sharing some of my performance engineering learnings from rbd

Talks

Deep sea fishing with React Hooks
Creating beautiful and accessible drag and drop for Atlassian
Rate limiting from scratch
What’s in the box?
React Portal: the good, the bad and the ugly
Dragging React performance forward
Performance optimisations for React: round 2
Performance optimisations for React applications
Performance hacking React
30+ at an internal Atlassian front end meetup

Internal Atlassian maintenance

All of the issue tracking and discussions for rbd is done on Github - so for the most, there are no double updates required for issues internally. However, there are internal rbd tasks as well. They include: creating and updating high level project tracking issues, meeting with internal stakeholders about future needs, internal blogs and planning discussions.

Closing thoughts

Maintaining rbd takes a lot of ongoing work. It is enjoyable to maintain a project with this scale - but it is heavy. Maintenance has been made easier by proactively pursuing self-service and continuing to engage with the project. In the times that I have needed to focus on other things, I know that the maintenance for the project has slipped as it is a fairly daunting domain to keep on top of.

I hope you have found this window into the maintenance cost of rbd insightful. Also a huge thanks to Atlassian for continuing to allow me to invest into rbd ✌️

What does react-beautiful-dnd cost to maintain?

rbd is popular and much loved ❤️