00:00:03.430
Hello everyone, welcome to RailsConf.
00:00:08.670
Let's get started on time.
00:00:11.629
My name is Lillie Chilen. My last name is a bit tricky, so here’s a phonetic guide for you: Lillie Chilen. You can find me online as Lillie Albert on various platforms. I am a software engineer at Omada Health, where we focus on helping people avoid chronic diseases through behavior change. I am grateful to Omada for covering my flight and hotel and for giving me the time to come to Atlanta to discuss open source.
00:00:31.320
When I'm not involved with projects at Omada, I usually think about RailsBridge. RailsBridge is an organization that offers free weekend workshops aimed at making the Ruby community more diverse. We maintain a set of open-source curricula and an event management application known as Bridge Troll. I am currently the chair of the board.
00:00:51.140
Aside from Omada and RailsBridge, I also spend time thinking about Double Union, which is a feminist hacker makerspace in San Francisco where I serve as the CTO. I handle our membership application and management app. At some point today, I'll provide a link to these slides, although it's not available right now.
00:01:13.930
Today, we're going to discuss three main topics: what constitutes a hero in open source, how to recover from the mantle of heroism, and tips for becoming an effective contributor.
00:01:39.570
In my view, heroes in the Ruby community can be likened to superheroes. They possess remarkable abilities, contributing consistently to benefit our lives. But often, heroes are just regular people who start helping out, figuring out how to get things done, and eventually become essential figures in our community. When we think of a Ruby hero, we might picture someone on a pedestal — a visibly prominent community member. However, many heroes work quietly behind the scenes, maintaining gems that significantly enhance the Rails app experience.
00:02:04.210
I confess that I’m a bit of a hero myself. I am the sole maintainer of Double Union's open-source membership app and undertake numerous heroic tasks for RailsBridge. While this can feel gratifying at times, it creates challenges. On one hand, it's wonderful to have heroes who do incredible work and make developing Ruby and Rails apps enjoyable. On the other hand, being a hero comes with some unpleasant aspects.
00:02:50.630
For instance, when something is broken in the Double Union app, or when a new feature is needed, I am able to swoop in and fix it because I understand the context completely. This gives me a warm, fuzzy feeling. Being a solo contributor allows for rapid progress since I know where everything is in the app, enabling me to make both major and minor decisions without needing to consult others. However, this also means I’m solely responsible for introducing bugs, which inevitably happens.
00:03:15.330
Some contributors earn a certain level of notoriety in the community — who doesn’t want to be famous in the Ruby world? But becoming a hero is not easy. There are significant downsides to taking on that role. One major issue with having heroes is that every hero represents a single point of failure. Silos are detrimental, but being the solo maintainer of a project makes them unavoidable. If a project has only one person managing it and they disappear or become unavailable, users can be left in a difficult position.
00:04:46.790
Moreover, heroism can trap the maintainers in a cycle of overwhelming responsibilities. I have felt this way in my roles, especially when pushing projects forward all alone. If I leave, I fear the project will crumble, and if it does, I worry whether anyone cares. This spirals into existential dread and sadness for everyone involved.
00:05:39.970
Personally, I tend to be a responsibility sponge. When I join a community, I take on fixing problems I observe, eventually becoming accountable for those areas. If this continues over multiple projects, it can lead to burnout. In fact, I’ve quit RailsBridge twice in the last four years due to feeling overwhelmed and uncertain about how to balance my commitments.
00:06:17.740
With Ruby gems, sometimes maintainers start slowing down their contributions as they become overwhelmed. Pull requests and issues pile up, and sometimes they ask for help but receive no assistance, leading to half-hearted maintenance of the project. It can even result in maintainers silently disappearing, leaving users to fend for themselves. You may find issues labeled with confusion about whether a project has been abandoned.
00:06:59.050
Not every prolific contributor is considered a hero. Simply writing a lot of code doesn’t designate someone as a hero in my mind. Heroes are those who hold projects together independently, who become essential for the project's survival. Sometimes this arises from a distrust of others among maintainers, which is disheartening. More often, however, heroes inadvertently fall into this role by chance, akin to being bitten by a radioactive spider which results in gaining GitHub stars and an engaged user base.
00:08:35.549
So, how can we assist and what strategies are available for recovery? Firstly, it would be beneficial if we could compensate individuals for open-source development. A significant reason individuals become heroes is a lack of resources. If developers can make a living through open-source work, they wouldn't have to sacrifice their evenings and weekends, contributing to projects that ultimately support many businesses making substantial profits.
00:09:07.650
I am particularly excited about an organization called Ruby Together, which is a new nonprofit trade organization. They are committed to supporting Ruby tools and infrastructure through funding contributed by individuals and businesses. It would be great if everyone could check them out and encourage their companies to sponsor them.
00:09:47.430
If paying for open-source work isn’t an option for you, what else can you do? There are three major areas I encourage you to consider: documentation, project management, and recruiting collaborators. While none of these activities involve writing awesome code, they are essential and should still be prioritized.
00:10:12.290
Much of what elevates someone to the status of a hero is being the only person with the solutions to problems. If everyone in Gotham had access to a Kevlar suit and a Batmobile, Batman wouldn’t be needed, but chaos would ensue. However, documentation can be a powerful tool in providing others with the means to contribute. A great starting point is your README file. It should include not only how to use the application or library but also how to contribute, how to set up the application, and how to run tests.
00:10:46.000
You should outline where to track features and bugs and indicate preferred communication channels, be it IRC, Slack, a mailing list, or a Google Group. By giving potential contributors the basics on how to start contributing, you can break down barriers. Often, maintainers already overlook elements that newcomers might need to understand. Therefore, it can be incredibly valuable to find an outsider who does not know your project. Their fresh perspective can reveal gaps in your documentation.
00:11:27.000
I went through this process with Double Union. Ben Balter from GitHub has a fantastic post on open-source collaboration that highlights the importance of minimizing friction for contributors. Everything we do should aim at reducing friction, thus encouraging people to engage and reducing the likelihood of becoming isolated.
00:12:02.310
You should communicate your preferences up front. For instance, if you prefer squashed commits or have specific formats for documentation, let others know. This approach prevents you from nitpicking their pull requests, allowing you to focus on the actual review process and not discouraging potential contributors.
00:12:49.690
Next, make a list of everything you do as a maintainer. There are probably numerous tasks that you handle that others might not be aware of, and they can’t assist unless they know what you do. I went through this exercise with RailsBridge, compiling a lengthy list of responsibilities I had taken on over the years. A lot of those duties would suit new contributors perfectly, but I’d been keeping them to myself because it was easier.
00:13:33.860
Once you compile this list, share it with others and solicit their help in managing those responsibilities. This move diminishes your silo status while allowing others to gain insight into and investment in your project. I acknowledge that I have not implemented this with my RailsBridge commitments yet. It's challenging, but I'm publicly committing to doing it during my flight back to San Francisco, so hold me accountable.
00:14:24.420
Project management is another challenging area. While people have designated jobs for managing projects, open source maintainers frequently still need to manage their projects effectively. When you start working solo, it’s manageable to track changes in your head. However, this isn't accessible to others who join later.
00:15:04.840
You will eventually need to write things down, but the project management tools available can be inadequate. They often assume consistency among contributors, which can be rare in open-source projects. While I don't have a silver bullet for addressing this inconsistency, it is important to balance your personal preferences with the accessibility for others.
00:15:56.020
We use Pivotal Tracker for tracking features in Bridge Troll, inherited from the app's creators. This tool works well for our frequent contributors, but I suspect it might hinder engagement among newcomers due to the need for permission to join. So far, nothing else we've tried has proved significantly better, so inertia wins.
00:16:57.330
On the other hand, Double Union operates completely on GitHub, making it easy to find tasks but difficult to prioritize them. I've found that sending emails to our mailing list helps. I can highlight specific issues that would benefit from additional input, and so far, this has yielded positive results.
00:17:54.560
Another vital aspect of project management involves timely responses to pull requests. Mozilla conducted a study on contributor engagement and discovered that contributors are far more likely to return if they receive a code review within 48 hours. However, if they wait longer than a week, their chances of returning drop significantly.
00:18:37.870
This can be challenging if you are a solo maintainer because you might want to take time off. It’s essential to find additional team members who can help review pull requests, preventing you from being the sole reviewer. This leads us to the question of recruitment: how do we find contributors and co-maintainers to share responsibilities with?
00:19:45.970
When making feature decisions, it’s useful to consult your users. Engaging them not only helps you shape your app but also identifies passionate individuals who might assist in your project’s development. When I engage with users of the Double Union app, I often find some are Rails developers. However, I predominantly reach out to non-developers and tech enthusiasts for targeted recruitment.
00:20:40.550
If your project is a library, your users will likely be developers — Ruby developers, to be specific. This scenario makes it easier to recruit contributors. Still, work on applications differs significantly from library development. Some developers may require additional support when shifting from application to library work.
00:21:39.830
Many may find the transition challenging, and this is perfectly okay. Additionally, it’s good to keep in mind that newcomers don’t necessarily need permission to contribute — if an open issue excites them, they should feel free to work on it.
00:22:25.760
I encourage everyone to provide feedback before submitting their PRs by utilizing mentors or co-workers. Saving maintainers from the initial steps of feedback can be a valuable contribution. Here are some general guidelines to foster happiness in both life and open source.
00:23:05.560
We should regularly introspect to understand our motivations for contributing or maintaining a project. If you currently maintain a library, ask yourself: are you still deriving joy from it? If you aim to contribute, ensure it's driven by enthusiasm or a desire to give back, rather than a vague sense of obligation.
00:23:50.700
The notion that one must be involved in open-source projects to secure employment is damaging. Not everyone possesses the luxury of time to contribute, and such pressures disproportionately affect those who can dedicate time only during evenings and weekends. Additionally, individuals sometimes arrive wanting to work on open source primarily for job prospects rather than a genuine interest.
00:24:41.780
If employers could stop imposing this expectation, it would be a tremendous help. Remember, involvement in open source is not a burden nor a lifelong commitment. It's perfectly acceptable to join for short periods or depending on interest.
00:25:16.540
However, accountability remains crucial for the sustainability of projects. We must discuss what happens when goals aren’t met without trivializing individual contributors' experiences.
00:25:59.350
This expectation is vital when working with volunteers, as I often encounter guilt when a deadline is missed. To mitigate this, creating retrospectives where honest, candid discussions about project issues can flourish will contribute to reducing heroism in favor of teamwork. Team collaboration allows for shared responsibility that can lead to resilient projects.
00:26:53.790
To summarize: silos are harmful. We should avoid creating single points of failure and develop succession strategies. Teams are indeed beneficial; they distribute responsibilities and allow maintainers to focus on what truly excites them. This promotes a healthier project environment, minimizing burnout.
00:28:42.180
Overall, thank you for your time and attention.
