[ANN] Rack, Change of Maintainer & Status

5441 views
Skip to first unread message

jftu...@gmail.com

unread,
Aug 18, 2014, 4:28:46 PM8/18/14
to ruby...@ruby-lang.org, rack-...@googlegroups.com, rack...@googlegroups.com, rubyonra...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dearest Rack Community, Ruby Community, and passionate onlookers,

There is a time when transitions must be realized by a point of impact, when a torch must go out, and it’s replacement brightens the darkness. We’ve arrived at such a point in the history of Rack. To cut the following story short, I (raggi) will be stepping down from any “maintainer” role in Rack. Aaron (tenderlove) will continue to maintain point releases henceforth. Additionally, as it stands today, the “Rack Core Team” are formally announcing that we do not expect that this team will release Rack 2.0. The rest of this missive will explain some history, and provide overdue gratitudes.

As many have seen, in the last year Rack has seen little to no maintenance. This is both a good and a bad thing. It is good in that the product is quite stable now, for what it is. It is bad in that the product is, like all software, not yet bug free. More than bug related challenges, Rack is now starting to fall behind the times at the architecture level. The reasons for non-maintenance are largely personal reasons, related to the lives of the core team. In most cases, a large part of the reason is that the team has moved on, using alternative technologies, if doing any software engineering at all. Some members have kids, some have jobs too busy to make time for Rack.

After some discussion by partially-laden swallow and internet telepathy, the original core team are in agreement that “holding the torch” - Rack as the sole middle-tier specification for the Ruby community - is at this point no longer appropriate. The world is changing, with Websockets, Server-Sent Events, SPDY, HTTP2, quic, and many Ruby implementations having usable multi-threading among many many other things. The next generation of middleware specification for Ruby should address these changes, and we wish to encourage the community to take ownership and do this.

It is quite likely that some battles will ensue, but it is our “dying” hope that by announcing the completion of Rack, the community will rally to the cries of its many members. Users will place their fire and brimstone under cauldrons and once again cook up a popular new abstraction that will spread even across foreign lands as Rack once did.

When Rack was first introduced to the community, there were many specifications for server and application interfaces. Chris did an amazing job at providing an abstraction so simple that it would be hard to argue it could be any simpler. In addition to providing a much needed specification for the connection between servers and applications, Rack also included many helpers to reduce common duplication - with great success. Eventually even Rails joined the party, and once at critical mass, Chris created the Rack Core Team. This was a fruitful period in the history of Rack. A great deal of middleware was produced, and it was good.

Fast forward to a couple of years ago, and Rack was in a similar place to where it is now. Many of the core team were busy with other responsibilities, and Rack was behind in maintenance. I (raggi) saw this and saw members of the community suffering as a result. I decided to put in the effort to clear our backlog and roll some releases. Little did I know at the time, but performing such an effort can inadvertently transmute oneself into a maintainer. In the time that followed, I did my best to ensure that critical security releases were timely, and that at other times, as few regressions were released as possible. For some in the community, this attention to detail was too much, they would prefer more speed. Rack has a very large API surface, that stretches deep into the servers, and deep into the applications. The API is very simple, which also means that it’s subtleties are actually critical semantics for many users. In light of this, there is some advice available in this gist[1], that was once unfortunately made public before it’s time. I hope that it provides some food for thought in future endeavours, but it is in no way a map to fame and riches (or a recipe for brewing what the next tier should be!).

A final note for those that may now be hearing the rattle of their chainmail. Rack will still be maintained for some time. The community needs it, and there are many that depend on it. There are many people who can still look after it, and additionally I will still assist those that kindly request it. No one is leaving you unsupported, this announcement is for your benefit, and it is best to see it as a chapter for the community, not an epitaph. Aaron will provide more details in due time.

Thank you everyone for your contributions, code, comments, support, discussions and even arguments. Without your input, Rack would not have been so successful. Never underestimate your value, we love you all, and we wish you the best of times!

Happy hacking,

- raggi, in association with rack-core.

[1] https://gist.github.com/raggi/11c3491561802e573a47


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJT8mH6AAoJELphsezQxofDFTwH/1Gu1yF5paia7IvI6ciCNutD
cd422lkbEubT0RwZEEZjKG/4ah3THcvjJwgRk6v74ggA0GKrXmMsgSeQSC59L1GH
BCw+FdMj8DwEoCfVGo9ID42SmHGuj+6W7MNpTPVW5u/Ck4k1uJ14gcSdoaS4ut0V
Wqr623uhYcIPEgQir6jvVjRCHclnjphR7cVmeueV7Lpnh15Tw1ttoRPZgsHsYqat
vTwYz2x4XC8jNfGLbejEoxSNnCc8UZC6SfVnMazOuqN6RnR0p7qBXSCtTD72H8l7
Fk+cAivJxjss+rnorYjxsS7a4XUsspYaaLd+IdYcNDRGLhPbltdOpLcG6U005TU=
=Qwuf
-----END PGP SIGNATURE-----

Eric Wong

unread,
Aug 18, 2014, 5:45:23 PM8/18/14
to rack-...@googlegroups.com, ruby...@ruby-lang.org, rack...@googlegroups.com, rubyonra...@googlegroups.com
James, Chris: thank you for all the leadership and work over the years!
Rack has inspired a lot of my work over the years (including servers
outside of Ruby).

To Aaron and new maintainers:
For the old-fashioned Rack apps, my services remain _always_ available
via old-fashioned email. Consider me obsolete when it comes to features
requiring new-fangled GUI browsers, though. curl is my co-pilot :)
Reply all
Reply to author
Forward
0 new messages