"basically an argument that monolithic frameworks can lead to community fragmentation by increasing the cost of switching and by creating an attitude of “uninformed superiority” on both sides of the divide."Well yes - I can't argue with that, but I don't think that being monolithic is necessarily Zopes problem.
Firstly, Zope was way ahead of the cgi curve, but in my opinion too far ahead, so like a lot of trailblazing products only got a niche audience for it's product, and also had to change directions a few times. Django by contrast had the advantage of being able to look at other frameworks and make some very careful design decisions which I think it ultimately is why it has become much more successful.
The biggest single design decision that zope is paying the price for is zodb.
A native object database is the most obvious solution for storing object data, but compared to sql, who in the wider world is actually willing to put their data in them. Given that no OODMS vendor has made any real dent in the sql world, it's very hard to pitch a large project which has zodb at the core. By using an ORM mapper Django made a pragmatic decision that keeps a lot of stakeholders happy, and there are a lot of people who know SQL, so if the ORM doesn't do it for you, then just bypass it and query the data directly. Zope by contrast can connect to sql databases, but it's clear zodb rules in the Zope world.
The other fundamental reason why Django is succeeding where Zope hasn't is a philosophical one. As Jacob is quoted as saying, Django is about "a way to get shit done", and from a design perspective the developers have been willing to take shortcuts to achieve that goal. Zope on the other hand has relied on others to develop the get shit done part (Grok) and focused on making Zope a framework that can compete with more complete enterprise frameworks. In other words Django has focused on a lower common demoninator.
Mark also talks about the trade-off between tightly integrated components and loosely coupled components, and it's here that Django needs to play close attention but not panic. I would argue that as long as Django does not get too far behind with any given core component, then it is much better to be able to control the direction of those components then be ahead of the game. Tight integration is one of Djangos key competitive advantages, which can only be a weakness if one of the components gets too far behind it's key competitors.
Loose coupling I would argue can be just as problematic for the advancement of Django. Ultimately if you can just just drop one part in over another it becomes like a wine-tasting convention, with every wine maker arguing that their wine is the definitive representation of the grape variety when all you want is a reasonable tasting drop at a reasonable price. Common blend wines might not have the features of a more expensive drop, but it has an easy appeal for a wide audience, and can benefit from the experiences of developing the more expensive specialized wine. Django's ORM and Templates need to pay attention and learn from SQL Alchemy and Jinja, but it doesn't mean they need to be replaced by them.
The key to Django's ongoing success I think will be something quite simple but hard to replicate, and that is a benevolent group of core developers who can stick to their philosophical roots and achieve that balance between technical excellence, pragmatism, and a healthy ability to accept criticism when it's due. That and retaining that newsroom sensibility of being able to communicate with an audience through the website, excellent documentation, and now with DjangoCon, are what should ensure a healthy future for the framework.
0 comments:
Post a Comment