An Attitude of Gratitude for Open Source

This happened today, in a discussion on github, regarding the “damage” done by having two alternative mainstream ways of integrating React.js with Ruby on Rails.

See, my issue was more of a general nature. I am just getting pissed off more and more nowadays with developers, as in general everyone behaves like he needs to do some own thing instead of extending existing solutions to his needs.

All that variety in software is great, cause that what “evolves” and “revolutionize” things, but in practice I’d rather prefer more opinionated solutions that would benefit from a bigger community and stability. The fact that my anger about that emerged in this very Github issue is pure coincidence.

Personally, I have an attitude of gratitude with open source. IMHO, it’s one of the greatest things that’s ever happened to the software industry. Only with open source, can you say “I need something different than react-rails or react_on_rails, and I’m going to modify it and make it better for my own needs”.

Not that long ago, the alternative was that you’d use proprietary development tools with obscurely documented APIs. Sometimes, your machine would crash unexpectedly. Then you could submit a bug request to some big company and just maybe would you find out that your bug will be fixed within a year.

So that sucked!

Open source, on the other hand, is free of charge and you have the source code with an often active and passionate community, like we have for React on Rails. (side note, some open source licenses have licenses that are not entirely free).

Now, you can fix anything, and contribute to the open source community! Before even making fixes, you can even see if others have the same issue. And while you wait for your fixes to get incorporated, you can use a github reference to your fork on NPM or Ruby Gems and freely go about your development.

So I believe in an attitude of gratitude for open source!

The maintainers of these open source projects often spend their free time working on open source, rather than other hobbies. Some companies, like Facebook, BaseCamp, and ShakaCode, donate paid employee time to maintain these projects. I’m grateful!

The best thing about open source for anybody that works on it is hearing how much some random person loves your project, or, even better, some company has chosen your project for a live website. I’ve tracked both of these on our PROJECTS and KUDOS pages for React on Rails.

We enjoy this feeling of community so much that we have both a free slack room and a free forum where my team gives advice, besides the typical github issues.

To your point of “I’d rather prefer more opinionated solutions that would benefit from a bigger community and stability”, that is our goal with “React on Rails, as spelled out in this article: The React on Rails Doctrine.

Maybe we could have forked react-rails, rather than building a new gem, but our goals and approaches are different enough (or at least they were a year ago), that it seemed prudent to have a fresh approach.

Here’s a few of the key differences I see between React on Rails now and the v2 of react-rails

• react_on_rails is available now for Webpack with many live sites listed and probably many more unlisted, at our PROJECTS.md page.
• Default configuration: Since Webpack will be an add-on for react-rails, it might not have the unified community around it compared to the React on Rails community, backed by my team from ShakaCode. Our community is based around native JavaScript tooling, including webpack and npm.
• Backwards compatibility: Since react-rails will strive to make their solution an easy upgrade, Webpack will probably not be the default option, as the feature proposal for v2 of react-rails is: Improve the flexibility of React addons: Support custom ReactJS builds (backed with npm & webpack, built into the apps asset directory).

To be honest, I’m not the one to speak on v2 react-rails, as I’m only aware of the public feature list posted on github.