How to accelerate Ruby development; Provide real world use case

The history of decentralization of Ruby, and what you can do for the future

The history of Ruby development is also a history of transferring and separating the power of Ruby's decision from Matz.

Many years ago all Ruby development was done by only Matz. But in the year 1999, Matz1 built a CVS server and allow some people to commit their changes into the repository. They fixes trivial bugs and manages some libraries without Matz's decision.

After about a decade, Rails has come and Ruby spreads all over the world, and people started to complain its release engineering.2 The problem is simply that a release includes both new features and bug fixes. To provide them but separated, Ruby introduced "stable branch" and patch releases (maintenance releases).3 And release engineering including releasing a new version (packaging) is also transferred from Matz. Introducing a bug tracker is also at the similar timing. The teeny versioning was transferred to branch maintainers little later (2.1.x).

In CRuby development, Matz still has a privilege over Core component API design and major/minor versioning. We (and maybe you) know Matz's design decision are generally so good. But can't we also replace his role by some other people or committee?

Some people are trying to steal his design principle. For example akr, a Ruby committer, wrote APIデザインケーススタディ, which describes some case studies of Ruby API designs.

Most people of so-called Ruby core team, I think, had considered whether we can replace Matz's role. But they, including me, seem to conclude cannot. It's hard to explain this feeling. But with the words from Smalltalk context,

Personal Mastery: If a system is to serve the creative spirit, it must be entirely comprehensible to a single individual.

Matz seems to use a black box which provides how complex the idea is, whether the name is suitable for the feature or not, the feature has enough merit to add, and so on. We cannot alternate such scoring black box.

Anyway if you check the log of RubyDeveloperMeeting or Matz's replies to Redmine tickets, you will find there's many replies like "naming" and "use cases". In these days people get well understood about naming issues. But people still don't care about use cases so much. Recently some of Ruby core team write Rails applications as their business (including me) and some are working as full time committer in Rails company like Cookpad and gathers use cases in there. Oneshot mode to coverage introduced in Ruby 2.6 is such feature. But we sometimes don't have enough experiences or imagination to discuss about a suggested feature.

The throughput of oracling the black box is limited. But we don't use its maximum performance yet. If you triage issues and providing/discussing a concrete real world use case for a feature, it will boost the Ruby development.

At this time when we discuss about a feature request, we discuss about how the feature is used in the real world. Then we check whether people who reads the code may misunderstand/confuse or not. You may suggest a magical fun feature but be rejected. It's because of such reason. Naming issues are also because of this reason.

And also, if a ticket has so long comments, it's helpful to summarize previous discussions. It's very helpful. Very helpful.


You can speed up Ruby development with showing a snippet from real world application.