Mark Ramm-Christensen of the TurboGears project starts what looks like it will be a great commit count pissing match . I know that wasn't his intent. He just wanted to show the TurboGears project is active. But nevertheless, this kind of thing tends to get rather silly rather quickly, so we certainly can't leave Zope out! Amounts of commits on a project are only a very vague measurement of project activity. Some projects may have more frequent, smaller commits than others, depending on project culture. Or maybe people with more commits simply make more mistakes! It's also only a single measurement of project activity. Lines of code changed might make more sense, but it's harder to do. Determining what belongs to the project and what does not is very tricky though. There are also other measurements of community activity. Amount of documentation produced, say. Or package release frequency on PyPI. Anyway, back to Zope. How does it fare in this? We're not dead yet either, after all. In the month of june alone, the svn.zope.org repository saw 663 commits. In the last 30 days or so, Mark's measurement, we got 796 commits (give or take 10; I'm not being strict with day boundaries here). Almost 800! If we start pulling in commits from other projects related to Zope but not kept in svn.zope.org, we'd get a bigger number. We could go counting commits in the Plone collective, for instance. If we included commits of projects that we sometimes use with Zope, such as SQLAlchemy and Paste, we'd get even more commits. That'd be silly though, as we've already won! Hah! :)
![[Comments]](/blog-content//themes/Default/comments.png "14 comments")
(14) Wed Jun 25 2008 02:53 Zope's entry into the commit count pissing match:
- Comments:
Posted by Balazs Ree at Wed Jun 25 2008 08:49
Commit counts are correlated with the project activity, but there are slightly different ways to measure it. For example on http://ohloh.net there is a project activity graph that features the number of commits and other similar statistics. Zope and Plone are already represented here.However the results are not completely real. For example, due to the nature of svn, each merge, however big it is, is counted as a single commit done by a single person and the activity done on branches is not taken into consideration for the statistics.So in my opinion, considering statistics like this can be useful to decide if a given project is active or not, but
it is not an adequate way to compare two given projects with each other.Posted by Patrick Stinson at Wed Jun 25 2008 09:26
Well, none of that really matters if a bunch of developers are spinning their wheels anyway. How about an average of the response to critical bugs, (meaning bug-in-the-bag), and number of milestones completed, based on a degree of complexity and difficulty?
Posted by Martijn Faassen at Wed Jun 25 2008 13:54
Patrick: those are good questions, and I have no idea how to begin measuring them. Determining what a critical bug is and what a milestone is in an open source project made up of volunteers is tricky enough, especially when the actual project is compose of many semi-independent smaller components.
Posted by Mark Ramm at Wed Jun 25 2008 16:12
My intention was definitely not to start a pissing match. ;) And I think any such pissing match is silly. Even in my own little page, I noticed that SQLAlchemy had far fewer commits than ToscaWidgets. But there's been far, far more *substantive change* in SA than TW.It was intended just to show that there are a lot of developers doing a lot of stuff, so the whole "turbogears is stalled" meme needs to die. Anything more is craziness.
Posted by Martijn Faassen at Wed Jun 25 2008 16:17
Mark, you couldn't help, of course, comparing with Django (and also to a lesser extent, Rails). I understand why you had to do that; it's hard to show activity if there's no point of reference.I am just trying to hijack your discussion to also say "Zope is alive and well". :)
Posted by Mark Ramm at Wed Jun 25 2008 16:49
I agreed that we needed a reference and I picked django because it has a reputation of having a healthy and growing community. And I didn't pick zope, because comparison with you would make us look bad. :)But seriously, TurboGears 2 is starting to use some zope technologies (via the repoze project) so can we now count your 600 svn commits, on our side too? ;)
Posted by Martijn Faassen at Wed Jun 25 2008 17:24
It's 800 commits, not 600, and I hadn't even counted Repoze commits. :)Cool that you're using Zope technologies. I really hope the TurboGears 2 project will seriously consider the use of zope.interface and zope.component. WSGI is nice because it establishes one basic, universal API that everything can follow, but one API that things can plug into is not enough in my opinion. What the zope component architecture does is allow the creation of many pluggable APIs in a general way. It's also why Grok is likely more pluggable than any of the competition.In return, Grok is going to use more WSGI. :)
Posted by Mark Ramm at Wed Jun 25 2008 21:45
Well, we're using zope.interface in a couple of places, but we're pretty careful not to use it where simpler methods suffice. And we're not zope.component, at least not yet. This may be my fault, as I haven't really felt like I was able to get behind the what of zope.component into the why. I agree though that you can't have one API for everything, and trying to shoehorn everything into WSGI is a bad idea. I think there are a lot of people skeptical of zope stuff, and I'd love to see some of those perceptions changed, if only because I don't want people flipping out when they see zope.interface as a dependency in turbogears. ;)
Posted by Martijn Faassen at Wed Jun 25 2008 23:32
Why are you pretty careful to use simpler methods? How is zope.interface non-simple?Concerning zope.component, it's indeed tricky to understand the "why" of it. But is a proven way to actually create pluggable APIs in a very general way, so it bears investigation.Note that even though it doesn't go into the "why" much at all, the grokcore.component does make the "how" easier still:http://pypi.python.org/pypi/grokcore.componentI know there are a lot of people are skeptical of Zope stuff. I can guess at reasons why, but it's still ironic as even Python itself was influenced by Zope people quite a bit (new style classes, for instance).
Posted by Rene Dudfield at Thu Jun 26 2008 02:09
hi,Why is zope.interface non-simple(complex)? zope.interface requires extra interface(s) for your code. You need to know one more technology (zope.interface) -- instead of just the normal python stuff.There's usually one more file, and one more interface class -- where there could just be one class, or maybe some subclasses, or class/method options, or config.Often you don't need pluggable APIs, and python allows you to fairly easily extend things without interfaces.The 'why' for interfaces is documentation, as well as pluggable object -- so people can make multiple implementations of an interface. Think 'file-like' python objects -- with a definition. Not just a definition, but a contract. If your thing works with an interface, you can be pretty sure it works.But like many optional python constructs, often you don't need interfaces -- you can stick with the simple stuff. Just look at how long python got away with just 'file-like' objects.class MySimpleFile:
def read(self, *args, **kwargs):
return 'my quick hacky file-like! Lucky I didn't need to implement the full interface!'
cu,Posted by Noah Gift at Thu Jun 26 2008 05:37
I would love to see a friendship rating for web frameworks, where it showed how much code was shared from another project either by grabbing or giving. This would be awesome, how could we chart this?
Posted by Noah Gift at Thu Jun 26 2008 05:37
I would love to see a friendship rating for web frameworks, where it showed how much code was shared from another project either by grabbing or giving. This would be awesome, how could we chart this?
Posted by Kevin Teague at Thu Jun 26 2008 08:03
"Grok has added TurboGears as a friend. Grok now has 382 friends.""TurboGears has joined the group 'Pissing Match'. The group 'Pissing Match' now has 12,718 members.""CakePHP has left the group 'Your Components are touching my Components'. The group 'Your Components are touching my Components' now has 34 members.":)
Posted by Kevin Teague at Thu Jun 26 2008 08:40
@ReneArguably, using zope.interface means you may waste some time building spurious interfaces that don't improve the functionality of the code. And you are adding another thing that you need to learn.So why go to the extra trouble?Documentation. When I open an unfamilar package and want to use it, I will open the README.txt first, and then head for the interfaces.py file second. You can get a sense of all the functionality of package more quickly with them, and they are great as a reference for looking up an API.Perspective. For smaller projects, sure, you don't need to think about interfaces. They're just polish you add later, to make packages more friendly to others. I still like them for solo hobby projects though. When I start to think about the design of a package, interfaces are a concise way of sketching out your more important ideas. Like writing tests, they give you another perspective into the code base that can make you see things that weren't apparent when you were knee-deep in implementation."Often you don't need pluggable APIs, and python allows you to fairly easily extend things without interfaces."This is certainly true. There are two packages though, zope.interface and zope.component. The later, zope.component, is the more complex one. zope.interface only provides the Interface base class and functionality for Interface adaptation. The zope.component package is the one that uses interface information to add all the pluggability and swapability to an application. And yes, perhaps Zope apps are at more risk to wind up with unneeded plugability - when you first learn the system there is a temptation to think, "cool, now I can make everything pluggable!" Apps that I write don't often need too much pluggability, but I really appreciate that feature in a framework."But like many optional python constructs, often you don't need interfaces -- you can stick with the simple stuff. Just look at how long python got away with just 'file-like' objects."Interfaces are very optional. You can build complete Grok web apps without writing any interfaces or even knowing about them. They become more valuable the larger the project. For a collective effort like a web framework, they enable developers to formally and semi-formally document their public interfaces (and they are not like Java's interfaces, they in no way reduce the dynamic nature of Python).
