Expectation regarding the Ruby open-source innovation process:
1- I stumble upon a problem at my job in our Ruby application
2- I build a solution for it in an open-source project (e.g. the ability to write the Frontend with a Ruby Frontend Framework instead of using an inferior JavaScript library like React)
3- I win an award for my open-source project by Matz, the creator of Ruby.
4- I get accepted to present my open-source project at Ruby conferences
5- Ruby Software Engineers adopt the new highly innovative open-source project, benefiting themselves and their customers greatly.
Reality regarding the Ruby open-source innovation process:
It doesn't matter how innovative an open-source project that you build is in your free time as a free beneficial contribution for the community. Even if your open-source project won an award from the creator of Ruby himself at an international tech competition that very few devs won, the project will get rejected from RubyConf due to discrimination and lack of appreciation for excellence from everyone equally. If you're in their discriminatory out-group instead of their in-group and/or you cover a topic that might upset RubyConf folks who aren't 100% for Ruby (e.g. unseating React/JavaScript with Ruby), you are excluded (even if your talk's project has zero competition), to the detriment of the Ruby community at large.
Learn more:
https://andymaleh.blogspot.com/2026/06/rubyconf-has-joined-railsconfrailsworld.html
Originally published as this blog post:
https://andymaleh.blogspot.com/2026/07/ruby-open-source-innovation-process.html
Top comments (4)
I found it really disappointing to hear that even an award-winning open-source project can be rejected from RubyConf due to discrimination and lack of appreciation for excellence. I think it's essential for the Ruby community to foster a more inclusive environment where innovative projects are valued regardless of the developer's background or the project's potential to disrupt the status quo. I'd love to know more about the author's experience with Glimmer DSL for web and how they plan to promote it to the Ruby community despite the challenges faced. Can the author suggest any alternative platforms or conferences where Ruby developers can share their innovative projects and get the recognition they deserve?
Thank you for the very kind and insightful comment. I would say that European Ruby conferences do not seem as corrupt as RubyConf with regards to not accepting talks that rock the status quo (e.g. unseating React.js or JavaScript in general). I was able to present Glimmer DSL for Web at both RubyConf Austria 2026 (in Vienna, Austria) and wroclove.rb 2026 (in Wroclaw, Poland) earlier this year. wroclove.rb's website literally says "We want to confront ideas" not run away from them like RubyConf 2026 did.
The exercises of the wroclove.rb 2026 3-hour workshop were posted on GitHub for everyone to be able to quickly setup an example Rails web app locally with Glimmer DSL for Web to get started with learning it step by step by following the exercises: github.com/AndyObtiva/glimmer_comm...
The recorded talk of RubyConf Austria 2026 might get published online. If it gets published online, I will announce it in a post on my blog (and maybe over here too): andymaleh.blogspot.com/
Otherwise, you can always reach me on Gitter Chat concerning Glimmer DSL for Web with any questions or requests for help: https://gitter.im/AndyObtiva/glimmer?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge
And, here is the Glimmer DSL for Web project's GitHub repo, which includes links to talks at the top (you can just check out the most recent one, like the Ruby on Rio talk):
github.com/AndyObtiva/glimmer-dsl-web
I hope this helps and answers all your questions.
It’s interesting to see how the path from open-source innovation to community adoption is not always as straightforward as building something technically valuable.
Projects that challenge established patterns often face a higher barrier because they are not only introducing a tool, but also asking developers to reconsider existing workflows and assumptions. That kind of disruption can create strong reactions, both positive and negative.
Regardless of conference acceptance, the fact that Glimmer DSL for Web has been recognized, presented at other Ruby events, and continues to attract discussion shows that alternative approaches have a place in the ecosystem. Healthy communities benefit when new ideas can be debated openly, even when they challenge popular technologies.
I think the most valuable outcome is keeping the conversation focused on the technology, trade-offs, and real-world benefits so developers can evaluate ideas based on their merits.
By the way, regarding my experience with Glimmer DSL for Web, I have been using it at my job (Eltropy, a Silicon Valley based Fintech company) inside our debt collection Ruby on Rails web application for a year and about 3 months now. In fact, I built it to solve our own problem of having very slow productivity/maintainability in JavaScript/React development in the Frontend compared to fast productivity/maintainability in Ruby/Rails development in the Backend. Now, we write our Frontend Components in Ruby too, and that is truly amazing as Ruby has unique features that make Frontend Development simpler than ever!
Two of our new hires love it! One of them joined us because he heard we had an alternative to React.js that allows building Frontend Components in Ruby. The other learned Glimmer DSL for Web and finished building his first Glimmer Component in 1 week only. He mentioned Glimmer DSL for Web as a very positive technology for our team at our regular team retrospective.
I would say Glimmer DSL for Web is feature complete as far as providing the ability to solve all Frontend problems in Ruby. That said, the setup process is still a bit manual and rough around the edges (it should get automated in the future), but once the library is fully setup in a Rails project, it is very simple to use to build Frontend Components that can be embedded inside Rails ERB Views. It still lacks some modern tooling like hot-reloading, but I was hoping the Ruby community would help fill that gap by contributing tooling and reusable components. Open-source software is meant to be a community collaboration after all, so I can use all the help I can get. Still, at my job, even without hot reloading, I find myself 2x-10x more productive with Glimmer DSL for Web than with React.js. React code in general becomes half the code in Glimmer DSL for Web. And, React components might shrink to 1/10 their size once rewritten in Glimmer. As any strong Software Engineer knows, having less code to maintain is better and simpler as it makes future maintainability cheaper, while finishing initial work in less time too.
I would say, any Rails shop that is using React.js or any SPA library like Angular, Vue, Svelte, or Ember is a perfect no-brainer environment for adopting Glimmer DSL for Web immediately instead as it would simplify the Frontend code significantly via Ruby and would double productivity or increase it even more (I rewrote a React.js component that took a developer 1.5 months in 1.5 days only using Glimmer DSL for Web). That is the no-brainer usecase that Glimmer DSL for Web helps the most with; that is doing true Frontend Development in Ruby, like building a UML Designer, a Business Configuration Tool (that involves many clicks by the user in the Frontend), etc... We are very happy to be able to use our most productive language, Ruby, not just in the Backend, but in the Frontend too thanks to Glimmer DSL for Web.