ForewordΒΆ

Some times amazing things can actually happen.

In the world of web frameworks, the rate of radioactive decay is very high. Projects are starting, splintering, folding, and clashing constantly. For Python, there are over 50 listed web frameworks. In some ways this shows health and experimentation. Yet others have started to ask: “Is this really good for Python developers?”

This book is the result of an event which bucked this trend, an event which Armin Ronacher wrote was “one of the greatest moves in Python’s web framework history.” Two projects merged and are bringing in a third. Consolidation won a victory over splintering.

As someone from the Zope world, I had a strong interest in repoze.bfg. I viewed it as the escape hatch for Zope, teleporting us into the modern world of Python development, permitting but not requiring Zope-style idioms. Chris McDonough established a great brand for repoze.bfg: small, documented, tested, fast, stable, friendly. As the project manager for a very large repoze.bfg application, I can strongly attest that it was a home run on those points.

But in a crowded web frameworks landscape, repoze.bfg was a long-shot to get critical mass. It had a lot to offer, but was missing critical pieces such as momentum and name recognition.

Pylons has long been viewed as holding the number two spot in Python web frameworks. It is one of (if not the) first “modern” web framework. With lots of users, and a “full-stack” framework atop it (TurboGears), Pylons had momentum and name recognition aplenty. But it needed more resources to accomplish its goals of an architectural transition, and Ben Bangert needed to share the load as architect during the transition.

Ben and Chris started talking during 2011 about architectural patterns and discovered Pylons and repoze.bfg covered almost exactly the same surface area. After some experiments, it became clear that, technically at least, the next version of Pylons could be the same as the next version of repoze.bfg.

But what about the non-technical parts? It was one thing to consolidate code. Consolidating projects was new territory.

I was fortunate to meet with the principals in Las Vegas and watch as they hashed out the idea. The projects would merge and keep the Pylons identity. repoze.bfg would sacrifice its identity, but provide the technical foundation. All the resources from the two projects would be combined.

I’ll confess, I had high hopes for the outcome. Now that the merge has happened and 1.0 released, I can honestly say it has done better than I could have imagined. The story of “consolidation” is catching on, and interest in working together is growing. Pyramid 1.0 is very, very high quality and ready to go for PyCon 2011. People interested in “simple, fast, documented, tested” have a strong framework and healthy project.

It took humility, patience, and pragmatism to reach this point of obvious success. Certainly by the project leaders, who each had to give up some of their sovereignty and sacred cows. But as well, each community had to discuss the challenges, the various alternatives for going forward, and the pros and cons of consolidation in general but also this particular consolidation. That such a conversation and change could happen in a responsible, adult fashion speaks volumes about the strength and maturity of each community.

What might happen in 2011? TurboGears is considering a move into the umbrella Pylons Project. As Armin writes in his post, there is fertile ground for consolidation at other layers. In my own interests, I hope the worlds of Zope and Plone view Pyramid as the base for the next decade of their ideas. But also, the Pylons Project as a vibrant home for such ideas.

Congratulations, Pylons Project. Not only have you accelerated your spot on the Python web frameworks chart, but you have injected the word “consolidation” into the lexicon of hot ideas for 2011.