Looking in django’s del.icio.us page this morning, and I found out that Lawrence Journal-World finally made a website for Ellington, the Django framework powered CMS they wrote for sites like lawrence.com, LJWorld.com and KUSports.com.
The site itself is a little short on details. There are no demos, tours or pdf overviews, but there isn’t any marketroid babble neither, which is a Good Thing.
Ellington is Django’s killer app right now. While not opensource it demonstrates what can be done with the framework: professional, scalable and production-ready web applications.
Comments (14)
I don’t think it’s really a CMS, although that’s part of it. It looks more like pre-build templated web sites based on ljworld and lawrence.com.
Tabo, thanks for noticing. You’re right that the info is pretty slim at the moment. We’re working on getting more up there - including some screencasts and case studies. For the moment, we’re working hard on installs and support for current clients. Just wanted to get something out there in the meantime.
Dan - that’s not quite an accurate assessment. There are default templates that come with Ellington, but they’re straight Django templates so fully customizable, replacable, etc. Nothing pre-built about it.
Ellington is in fact a CMS, and thanks to Django, a web development and server platform.
Just out of curiosity (and so I can adjust the descriptions if necessary) - what was it about the info on the site that gave you the impression otherwise?
I suppose because django more or less builds a CMS for you as you build the database models, so it seems to me that the real benefit of buying Ellington is that you get a pre-built django site with all the great features of ljworld or lawrence.com.
I would say that this a conflict of interest. Django competes with ellington. I hope you guys do it better than zope did. Having a competing commercial product means the “opensource” version suffers from lack of documentation and overall complication and obfuscation.
I’m not saying this happes consciously, its just that the fiscal priorities of the people are directed towards commercial side of the app. Especially when the same ‘core’ team is responsible for both products.
I believe Ellington should be open sourced. You cannot take the changes contributed by a whole community (when it comes into effect) and plow it back into a commercial product without at least making a crippled version available to the community.
controversial yes, but imo zope suffered heavily because ZC had active interest in the product being obfuscated and complicated. This ensured that “their” consultants would get the ‘juicy’ contracts. In the long run, the whole thing dries up, so its a strategic lose/lose sceanario (if taken to conclusion)
Having ONE product (ellington+Django) would be better. Otherwise Django will suffer from lack of docs and lose mindshare. Even now, the ‘Generic View’ capability is not fully explained even though most people could build basic web presence with just that functionality with a basic understanding of Python.
Hopefully that will happen soon. At the very least more docs for generic views and less of a feeling that one would need a ‘consultant’ do run the thing. There is too much plumbing to be hooked up by hand as it stands (with or without generic views).
Peter, Django doesn’t compete with Ellington any more than MySQL competes with Yahoo (that is, Yahoo uses MySQL extensively, and there’s no conflict of iterest there, is there?)
There are myriad examples in the open source ommunity of companies building products on top of open source frameworks, and history tells us that conflict usually is a moot point. Think about 37 Signals’ products built with Ruby on Rails, or RedHat’s commerical use of Linux, or…
It seems like your perception of conflict comes from not quite understanding what Django and Ellington are — Django is just a web framework; Ellington is a complete news CMS *built with* Django. Ellington competes with WebLogic and Vignette and such, not with frameworks and libraries like Django.
Second, your allegation that the “fiscal priorities of the people are directed towards commercial side of the app” is completely off-base. Adrian Holovaty now works for the Washington Post, not the Journal-World; his work on Django is purely his.
I do work on both, however, and I’m offended that you can attribute such base ethics to someone you don’t know.
Ellington is an app built with Django, including models, views, templates and all kinds of custom tags and functions. It represents years of development hours on its own, with or without Django. Django makes it easy to build content management apps, but not *that easy.
Ellington and Django aren’t the same thing. Ellington isn’t a “souped-up” version of Django, and Django isn’t a crippled version of Ellington. Without Ellington there would be no Django: Django was extracted wholesale from the core framework components of Ellington. We took everything that we considered generally useful and that wasn’t specific to particular applications and released it open-source. Everything. Including the interface.
World Online doesn’t “plow” anything from Django back into Ellington as a commercial product. Ellington requires Django as its core dependency. Anyone who buys Ellington from us gets Django installed as a convenience, but they could get it for themselves, straight from the trunk, with the same effect. And they can build whatever apps they want on Django, integrate them with Ellington, and not pay us another dime. At this point, we’re just another commercial developer building web apps on Django.
For the record, Django is *much more extensively documented than Ellington, *because it is open-source. I refer to the Django docs every day, and I refer our clients there too. If it’s not documented for Django, it’s not documented for Ellington.
Incidentally Peter, what did you find missing from the generic views documentation ( http://www.djangoproject.com/documentation/generic_views/ )? I’m not a Python programmer, but I just finished building a site in Django using nothing but generic views without much more help than the public documentation.
I believe I didn’t word the sentence properly. It was not my intention to accuse you of any such thing.
The reason think this model — extraction of frameworks out of commercial app and subsequent sale of the app for commercial value with the changes from the open source effort merged back into the product — poses issues of conflict of interest is precisely because there is overlap, and there are commercial concerns, and there are opensource (hippyish) concerns. Commercial concerns tend to win out over hippy concerns (free information, sharing of code etc.)
My intention was not to suggest that this happens at a conscious level, but it seems to appear (watching Zope, Arse Digita’s ACS and many other extractions) that when the FOSS concerns cross paths with commercial/consulting dollars. the commercial part wins out.
It is clear that Django & Ellington are not one and the same thing, but one must acknowledge that they are symbiotically intertwined.
Having said that, in a situation where an enhancement to Django would directly compete with Ellington, A conflict of interest could arise when generally the flow of goodies is from Ellington to Django (more extractions).
For example, I don’t understand why the Admin interface type option is not available on the user side? What is so conceptually different re: data? except that fact that on the public side, the user would need to have a generic role. This combined with a generic template and the generic views (properly documented) could allow users to create websites out of the box with just django.
Most people are not trying to build LJWorld out of the gate. But they do get converted to your framework if they can do the “Zope thing” without going through the “Zope pain”. By Zope thing I mean getting a simple website built as soon as they have installed the framework.
By the looks of it, this is _NO_ technical feat whatsoever. If the Django team wanted it, they could have put a generic admin-interface type face (configured through generic views of course) on the public side of django. But that is not the case so far. There is lots of wiring that needs to be done before a Hello World can show up on that port 8088.
Hi Wilson, I think the Generic Views docs are very good for someoen with basic programming experience. My point is: If you’ve gone 95% of the way, why not just go all the way and give users a simple site out of the box? Why make them download the djangoproject source and futz with it? Why not just include it in the core install, and let them yank it out if they want to. Django is modular to the point where this shouldn’t be hard for someone with a basic understanding.
Again, my intention is not to impugn the good intentions of the core team. This is more of a philosophical issue that I have with all “extracted” products especially when the commercial sibling generally owes its continued prosperity to the consulting dollar.
Perhaps I’m seeing things where there are none. And that is just as well.
Thanks for all your work, it is much appreciated.
P
This may not be a good example, and I’m not suggesting that the core team has done this for base/cynical/financial reason, but this, or something like this may come across as conflict of interest in which the commercial side of the symbiotic twin wins out.
P.S. Wilson, perhaps you can share your app on the apps repository. Not being a “Python Programmer” is not the same as not being ‘A Programmer’. I find the claims of 15year java veterans on the Rails list dis-ingenuous when they claim they built an app “without any Ruby or Rails experience”. I hope your claim is not in that vein. I am trying to speak for the end user because the framework is literally being within inches of being an OOTB product on its own.
It will only help the uptake and help Django in the long run. Just my Opinion.
Peter - Thanks for clarifying some of your points. Let me return the favor…
As I pointed out, Ellington doesn’t extract anything from Django. Every time Django introduces a new backwards-compatible change that we want to take advantage of, we have to refactor our code just like everyone else. Adrian doesn’t work for us, and he doesn’t write anything into Django as a favor to us. If anything, the trend is pretty strongly the other way. If anything crops up in Django that’s determined to be something “only World Online” should have to deal with, it’s removed.
Conversely, if we need something for Ellington that belongs at the framework level, we develop it for Django first - at the cost of having to update all our code to use it. As an example, Jacob and I both put a lot of time into the new edit-inline interface that will be part of the magic-removal branch because it was something we needed. We didn’t build it as an Ellington extension so we could sell it as an exclusive feature. It belonged in Django, we wrote it for Django, and it’s going into Django. And if we want to sell it, we’re going to have to sacrifice some weekends to refactor a few thousand lines of code first (well Jacob is, but I sympathize!).
Also, I’m not a programmer in any sense of the word. I’m a designer and I know my way around HTML and CSS and that’s about it. On a good day, I can do something painfully basic in javascript and not look like a moron. My point is, it wasn’t that hard for me to do something simple with the existing framework tools, using the available examples and documentation.
Your point that “If you’ve gone 95% of the way, why not just go all the way and give users a simple site out of the box?” is a valid one, but I think it’s a misconception.
The only reason the first 95% (give or take) is done is because it can be done in such a way that maintains flexibility and control for the user. And the last 5% is the hardest part. Not because it’s technically challenging, but because it’s virtually impossible to do it “right” for any number of users.
100% done my way works for me, but not for you or anybody else. If you do 100% out of the box, you inevitably and severely restrict flexibility. Obviously this is a trade-off and a grey area. Some people will think that 95% is too much magic, and they want more control. Some people will think it’s not enough and they want more done for them. There’s a sweet spot in there, but it’s different for different audiences. Rails has a different sweet spot, as do TurboGears, web.py, Zope and everyone else.
If you want to build sites entirely from a web interface and write no code, Django probably isn’t going to work for you. But there’s nothing to stop a programmer from writing apps with Django that accomplish exactly that. Ellington doesn’t work that way, and I don’t foresee something like that ever being part of Django as a back-end programming framework.
Also, sex toys, online slot machines, etc.
Wilson:
About the sex toys and online slot machines, I had to install akismet. The comment spam in the last couple of days was getting ridiculous.
tabo: I wasn’t complaining - just trying to fit in ;)
Wilson:
Your point re: the last 5% being the hardest part is well taken, and this is always a grey area. One can always try to influence the opinions of those in power :)
Even though I quite possibly have not done a very good job of presenting my point. I still believe that if Django came with an app which users didn’t have to mess around, it would give it leverage in terms of competition for mindshare. One thing I learned from the Catholic Church was that its always good to have converts. Doesn’t matter if they’re in china or in the ghettos of Brazil. They all contribute to the clout of the “product” if you will. And no, I’m not accusing any of the core dev’s or anyone of claiming to be Pope. :)
hello
I’m not a coder nor a programmer either… nor can I afford Ellington… that said… I just wish Django would offer a poorman’s Ellington… or at least an esier way for just a wknd and late nights warrior designer to put the power of Django to work!
Wilson, thank you for your fantastic and insightful point of view. I too could see the fall of django in a year or so as the inclination towards $$$ making by focusing on ellington and possibly other apps, instead of becoming the best at something that can change the way sites are designed. It just is not fair to take all the work of the community and package it together to sell by the insiders! Enjoy the $$$ team :)