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.
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:
egghead.io quick start courseto talk people through getting started with the library step by step. consolewarnings for detectable setup issues. That way people do not need to consult the docs for most setup issue issues 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.
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.
I get about one bug report every 1-2 days. There are a few types:
Reactand rbdis in one of their first projects. So often people are fighting with Reactissues rather than rbdissues 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
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.
We get about one pull request to the rbdproject per week . There are a number of categories
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:
rbd
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 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.
Sharing some of my performance engineering learnings from rbd
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.
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: