The aim of this blog is to make visible the ongoing effort required to maintain the open source drag and drop project
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.
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.
I have adopted strategies that aim to maximise peoples ability to get started with
rbd, and troubleshoot issues without needing to reach out directly (self-service). They include:
- Created a free
egghead.ioquick start course to 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 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
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.
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.
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.
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
rbdis in one of their first projects. So often people are fighting with
Reactissues rather than
- 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
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
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.
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.
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
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
rbdcould 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
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.
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.
- Rethinking drag and drop
- Natural keyboard movement between lists
- Beautiful drag and drop: a year in review
- Beautiful interactions: Crafting elegant and robust drag and drop animations
Sharing some of my performance engineering learnings from
- Grabbing the flame 🔥
- Dragging React performance forward
- Performance optimisations for React applications
- Performance optimisations for React applications: Round 2
- 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
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.
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