Ian Bicking: the old part of his blog

Re: spit & polish

While I agree somewhat that the sheer number of frameworks isn't necessarily a problem, I don't sense lock-in or incompatibility as being a huge stumbling block for many. I still think it's a business-like concern over support (i.e. documentation, books (eventually) and number of other users of the software) that is most people's concern.

"Am I going to build our department intranet in this framework and then it'll be dead by the time I'm done?" Sure people have the source, but in many cases not the time or skills to evolve and improve a framework like a community of users.

This is one thing that has drastically helped R*ils. As many similar projects do, they have a smaller core of developers who are dang good, and a much larger orbit of others -- designers, general webmonkeys, occasional programmers, beginners, etc. Many Python projects seem to get stuck at the small group of good devs - and never make it to the "attracting a crowd" part. Many possible reasons, some valid, some junk, but I still think this is the magic [but mundane] step to increasing visibility (http://blog.ianbicking.org/why-web-programming-matters-most.html).

Eventually, a Python framework will show up in a nice package, with a non-PythonGuru friendly face and crowd (lesser mortals aren't scared away by the high priests on the project), and start attracting much more attention. Maybe Mssr Holovaty's package, maybe not (haven't seen it!). But I think once that (inevitably) happens, it will set the terms. Sorta like how the IMG tag came about maybe.

That said, if it happens on a shared spec like WSGI and your other efforts, that's even better. But I suspect that will be resolved by a large-visibility project choosing to implement it rather than the project needing to for its own success. i.e., top-down as opposed to bottom-up. Just missing the obvious top right now...

Comment on Handling a Diversity of Frameworks
by ToddG

Comments:

While I agree somewhat that the sheer number of frameworks isn't necessarily a problem, I don't sense lock-in or incompatibility as being a huge stumbling block for many. I still think it's a business-like concern over support (i.e. documentation, books (eventually) and number of other users of the software) that is most people's concern.

If you can switch frameworks reasonably easily (and incrementally), then you can follow support and popularity. That's why I think lock in is a big problem. That said, in practice lock in isn't terrible right now, with one notable exception (that starts with a Z), but it's still more than it should be.

That said, if it happens on a shared spec like WSGI and your other efforts, that's even better. But I suspect that will be resolved by a large-visibility project choosing to implement it rather than the project needing to for its own success. i.e., top-down as opposed to bottom-up. Just missing the obvious top right now...

I think (?) that Zope 3 probably already runs on WSGI. When the Twisted people asked Jim Fulton what it would take to get them to use Twisted instead of their Medusa fork, he asked them to do it via WSGI. Twisted web2 (which had a 0.1 release recently) included native WSGI support, and Zope 3 should at least come along soon. I doubt Zope 2 would be that hard either, though what I'd really like is a Zope 2 WSGI Server Product, so that you could run WSGI applications under Zope. Really I should just stop talking about it and write it, because it shouldn't be that hard.

# Ian Bicking

I should expand on the importance of being able to switch:

An environment where people can move from one framework to another will allow a real Darwinian process, and the emergence of a smaller set of "winners". Right now frameworks linger on forever, because there's no honest way for them to die. Either the developers abandon their users -- many of whom are often clients who trusted the developer's original choice of framework -- or the project keeps going and further development continues on it. Neither is good; either you are bad to your customers, or you create a partisan environment where each group of developers works in isolation to create the same set of features in their different frameworks.

The coupling of typical frameworks makes this worse. It's hard to be a polished framework when you have to implement a large number of features. As a result, frameworks typically implement a few features well, and some features poorly. As a result the selection process is haphazard, because you have to decide which features are important to you (and you don't really know), and you have to accept compromises in other features. With a decoupled stack, you can choose the best piece for each level of that stack. Sometimes there will still be vague choices -- different valid quality implementations, which appeal to different segments. But I think at each level there will arise a small set of choices, each with real reasons for existing even in the presence of other implementations.

# Ian Bicking

You are of course right on the huge value of being able to switch - or "evolve away" from a specific framework. As seen in the Java world with some people moving away from Struts to more recent setups like Spring, JSF, [today's new favorite], etc., but not needing to move it all at once.

I guess I was loosely speaking more so of the possible reasons for thriving/dying of contenders. Most likely both parts are needed: not being locked-in at a lower level will allow more dynamism in the upper levels, which should lead to a few "obvious choices" as you point out [and I tried to point out as needed to really expand the visibility of pyweb stuff].

Perhaps akin to having your living room furniture bolted down and/or integrated into your flooring - requiring tearing up the floor to change things [current scenario], and having all your furniture on wheels on a nice smooth floor - easy rearrangement [planned]. Alright I'll stop killing analogies now...

# ToddG