2020Ruby on Rails Community Survey Results

On June 23rd, 2013, Rails Version 4.0 was released, which was a milestone in Rails's stability. As startups chose a framework to rapidly prototype their MVPs, Rails became an easy choice. No surprise that 5 - 8 years later, those MVPs have graduated into booming businesses that have proven that Rails can scale.

The dual-booting upgrade strategy entered community conversations in 2018, around the time the last survey was released. A dual-boot strategy adds a second Gemfile to a Rails application during an upgrade, one pointing to the current gem versions, one pointing to the upgrade gem versions. This allows all upgrade and non-upgrade related changes to coexist in the main branch during an upgrade, instead of the traditional approach of relegating upgrades to a feature branch.

I'm curious to see how this value changes between this survey and the next. It also led me to wonder how many of the respondents have worked on an upgrade since 2018? If they worked on an upgrade, was it for a minor or major version? Are most of the folks who used the dual-boot working on large apps or small apps?

Sidekiq's growth in the Ruby market has been a literal dream come true for me. The success of the Sidekiq business has given me an edge that most open source projects don't have: sustainability. Eight years later I'm still working on Sidekiq, answering support emails, and improving it daily. I hope that developers see quality when they read the wiki or the code.

Authoring a gem is important for people in the community for a few different reasons, in my opinion:

1. It increases the total accessible solutions in the field. Each gem is a reusable component that someone can build upon. Thus, the more gems are in existence, the more combinations of potential solutions that can be built using them.

2. Authoring a gem is a great way for people to learn to contribute to the community. It improves people’s code-style, testing, and communication skills.

3. Ruby, as opposed to some other programming language communities, is open to many different ways of doing the same thing. As the number of authored gems increases, the number of different approaches to the same solution also increase (think of the number of different gems you can use for making web requests), which enriches the community and the products they build.

Looking at this graph, gem authorship as a percentage seems to be on the decline for the last 4 years. This could be attributed to newcomers joining the community who are less likely to start contributing by authoring gems, or the number of tenured people who have authored gems leaving the community to go on to do other things. In the long run, this is an expected trend with people changing fields and interests. It is still amazing that over half of the people in the community have shared their work for others to use.

It's awesome to see so many people in the community contribute to open source a few times a year or more. I think that says a lot for how welcoming the community is to newcomers who would like to contribute to Ruby or Rails projects. Of course, I'd love to see more open source contributors. If you're not sure where to start, ask a maintainer or start by improving docs & error messages or add a small improvement to something you find frustrating or error prone. You'd be surprised how easy and rewarding it is!

These results suggest that Rails developers seem to be tending towards lightweight solutions when it comes to adding JavaScript into their apps. It's not all that surprising to see that most Rails engineers would choose jQuery over a larger framework when possible; jQuery is smaller in size, and to some extent, faster to implement as compared to learning a new framework. When a more barebones library doesn't do the trick, React appears to be the clear framework frontrunner, with Vue and Stimulus closely behind.

Notably, while all three of these frameworks come with their own learning curve, it would seem that Rails developers have accepted the new mental model of these frameworks with the main benefit being their smaller bundle sizes.

"I am both surprised and alarmed at these results, especially considering over 700 malicious gems were discovered on RubyGems in April. Rails has a reputation of being pretty secure out-of-the-box, and my theory is that this causes security to become a secondary concern for many teams. I am also curious if providing more examples of automated security tools, like GitHub security alerts and Snyk, would have affected the results. Security should always be a priority and automated security tools will ensure that you can find and fix issues before attackers find you. My challenge to the community is to make sure that next year the results indicate that security is a first-class citizen in our applications."

As a consultant working on many past and present Rails projects, the deployment options I've encountered each had their own advantages and pain points. It's heartening to see that easy to deploy Rails apps are the steadily increasing norm, especially since the majority of Rails developers have little DevOps experience.

Whether it's a gem, your hosting platform, integrated into a CLI or any combination of the above, there are options that can make the process easier for you and interruption-free to your end users.

While I don't deny there is likely an inherent bias within the community of those who participated in the survey, seeing that 93% recommend that new developers learn and build Rails apps vs other frameworks is really encouraging. I can't help but attribute this to a healthy (and stable) third-party library community, a lot of valuable educational material, and ability for junior developers to be able to quickly learn how to contribute.