What does react-beautiful-dnd cost to maintain?

  • 时间: 2019-05-21 01:09:34

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 rbdproject 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.

rbdis popular and much loved :heart:

I have been lucky enough to work close to full time on the rbdproject for almost two years at Atlassianand I am it's primary maintainer. rbdis 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 Reactprojects and it one of the most downloadeddrag and drop packages on the web. The package has been an ongoing source of praise for Atlassian.

The best defence is a good offence :football:

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 courseto talk people through getting started with the library step by step.
  • Created and maintain extensive documentation
  • Adding development only consolewarnings for detectable setup issues. That way people do not need to consult the docs for most setup issue issues
  • Creating a common setup issue guide
  • Creating issue templates to assist 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 :bug::x:

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 rbdhas 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.


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 :construction_worker:‍♂️

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 fluctuatesweek to week.

Bug reports :bug:

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 Reactand rbdis in one of their first projects. So often people are fighting with Reactissues rather than rbdissues
  • 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 issuethat 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 rbdagainst. 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 :rocket:

rbdgets 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.


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 rbdproject 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 Reactteam put it nicely when they said that rarely do they accept changes from external contributors. The Reactproject 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, 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:


Moderating :woman:‍⚖️

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 :gift:

There is some really interesting engineering in rbd. I write blogs and give talks to share my learnings and to market the rbdproject. By doing this the impact of rbdis 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


Internal Atlassian maintenance

All of the issue tracking and discussions for rbdis done on Github - so for the most, there are no double updates required for issues internally. However, there are internal rbdtasks 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 lotof 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 rbdinsightful. Also a huge thanks to Atlassian for continuing to allow me to invest into rbd:v: