[ANN] Rack, Change of Maintainer & Status

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

Thanks for all the hard work!

···

On Mon, Aug 18, 2014 at 4:28 PM, <jftucker@gmail.com> wrote:

-----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 thi
s 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] rack retrospective · GitHub

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

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

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 :slight_smile: