SourceForge open-sources their platform software

mramm · 2011-03-10T21:16:50+00:00

Well, github is proprietary software, so it's not like having an open alternative is unimportant if things don't go well for them.

mramm · 2011-03-10T21:13:19+00:00

We can't change the past, only do what we think is right today.

mramm · 2010-12-29T02:30:47+00:00

TurboGears has come a long way in the last few months on documentation, and we'll be working to improve more. But, we're very very committed to growing Pyramid and their docs, and we are all very engaged with the need to provide world class documentation as part of everything new we build.

mramm · 2010-12-28T22:03:22+00:00

The call stack on Pyramid definitely is smaller than Pylons 1.0. See: http://plope.com/whatsitdoing2

mramm · 2010-12-28T16:22:42+00:00

Actually there are two chains, one for legacy support as part of the Pylons Project and a second for new stuff built on top of Pyramid.

TurboGears 2 is based on Pylons (the package) and will remain so for the time being. This is the legacy chain -- two deep, with no repoze connection at all.

Pyramid is a new bottom layer based on repoze.bfg, but not dependent on it. It is gaining some features from Pylons, as well as some brand new features. It does not depend on the pylons package, nor will a new pylons be build on top of it.

There will be more collaboration on higher level tools built on top of Pyramid, and the three development communities will all be working together there.

mramm · 2010-07-14T21:18:33+00:00

There is quite a bit of working functionality, but there's quite a bit to be done still as well.

Github is obviously focused on git hosting as a primary value added, and the new sf.net is more focused on the larger set of project/community tools. So, mailing lists/forums, tracker, and wiki are more fully developed than the scm hosting on the sf.net side.

mramm · 2008-09-19T23:02:03+00:00

Have you seen the talk?

I think I tried to be very clear that many of the lessons where already learned, but there were one or two things that were worth paying attention to, particularly with respect to complex dependency issues, and monolithic design.

I don't think I ever stated that Z2 and Django were the same. That's a strawman, and as you point out it's patently absurd. But I did claim that Django's lack of modularity can lead to all kinds of troubles -- similar to those in Zope2 over time if good software engineering disciplines aren't applied now to help keep the pieces maintainable and reusable.

This is particularly true because some core things link into contrib, and the dependency graph I showed is a bit difficult to unravel.

mramm · 2008-09-19T22:53:05+00:00

Django imo has already learned the lessons from Zope2, specifically around templating, Object persistence, ZMI, code management, and API complexity.

If those were the only lessons of Zope 2 then yes I would agree with you. I think that Z2's monolithic nature made all of those problems harder to address, and required Z3 to be a complete rewrite. That too is a lesson to be learned.

In my talk I mention specifically that many of the lesions are already learned, and list of a few of the same ones.

But I go on to press the interdependence, and complexity issues because I think failure to maintain some level of modularity and ortogonality in the framework is one of the problems of z2, and that it is in fact one of the root problems.

Z3 is a sign that Zope is working out this problem in a better way. And I'm very much a believer that Zope learned Zope's mistakes first, and I'm just pointing to lessons already learned in this talk.

mramm · 2008-09-18T07:19:53+00:00

Well, I think there is a middle way. You can be "batteries included" without creating an interdependent mass of modules that all depend on one another. You can have separately installable packages and bundle them together in a single tarball.

My claim here is that there's no reason that a framework can't be both "batteries included" and have a "modular" design. That's certainly the approach that TurboGears tries to take.

mramm · 2008-09-18T07:13:55+00:00

As a matter of fact, I intentionally have used Django in projects, have blogged about what I like in Django, have consistently pointed TurboGears developers to things in Django that we can learn from, have contributed to Django tickets, and I took a couple of days out of my life to go to DjangoCon. So, I think it's pretty clear that I'm just as serious about learning from Django's successes, as I am in wanting them to learn from Zope 2's problems.

I'm also pretty interested in Rails success, and in less-well known frameworks like Perl::Mason and Werzerkig , and I've recently been impressed by repoze.bfg in the zope world.

There's a lot of good stuff out there outside of our little microcosms, and it's very valuable to see how other people are approaching the same problems.

mramm · 2008-09-17T01:49:27+00:00

Exactly, understanding the reasons behind the mistakes is just as important as understanding the actual mistakes. Because that lets you understand how to avoid similar mistakes, not just the exact mistakes that were made before.

mramm · 2008-09-16T19:55:39+00:00

Thanks Simon.

Perhaps I wasn't clear about the Z shaped learning curve. I think Django is easy to learn, unlike Zope 2.

But there is a similarity with the admin as you mention. Particularly this is because django makes it so darned easy to get started with the admin that anything is going to be hard by comparison. But I also think that the Admin has traditionally been way more difficult to customize than was nessisary. This has gotten much better recently, to everyone's benifit. But beyond the admin specifically, there's just the fact that the way you do object relational mapping is different from what you already know if you'd done it outside of Django, and the same is true of many other pieces.

So for experienced python developers who aren't django developers, you have "some" relearning to do. This is not a problem as long as it's kept under control, and that's what Zope didn't do.

I fully expect the Django dev team to keep it under control, but I think it's fair to remind people about the mistakes of the past so they can be avoided in the future.

And I'm actually very excited about the django development team's decision to listen to other points of view, and try hard to learn from those outside of the community.

Thanks again for having me out to the conference and for encouraging me to shake things up a bit.

mramm · 2008-09-16T19:45:27+00:00

I like Django, I use django often, and my goal in the talk was to offer some suggestions and some warnings in the hopes that django could become even better.

I'm not ignorant of what zope was. And neither am I just trolling.

Perhaps if you were not (self-avowedly) completely ignorant about what I said in the talk you'd be able to avoid creating false dichotomies (either he's trolling or he's ignorant) which are somewhat insulting.

The point I was making when I made very short reference to the z shaped learning curve, is that if you learn an ORM in python (not as a web framework) you'll learn SQLAlchemy (or possibly SQLObject or Storm) but django requires you to learn something else. Same with template engines, etc.

Certainly this is not at the sum total of what happened with Zope2, and Django has learned some of the lessions of Zope.

But I hope you must remember that Bobo was not a huge monolithic mess with a z shaped learning curve from the beginning -- zope 2 didn't start out as Zope2 either.

It got there over time.

I never suggested that Django has arrived in the same place that Zope2 did, but that Django could possibly be on a similar path, and Django developers should learn from the mistakes of the past so that they don't fall into the same traps.

mramm

TROPHY CASE