It's been a while since I've communicated directly with the Zope community, and I am truly sorry for that. I have been so busy, that I have actually disengaged from the mailing lists, something I was hoping to avoid doing. I have maintained the same level of involvement with Digital Creations, and therefore Zope as well, but the amount of traffic on the lists was overwhelming me given my current activity level at Opticality. I have only seen a single post to the list regarding the recent announcement of Perl for Zope. Paul Everitt was kind enough to directly forward to me Eric Sink's post, because he knows how highly I regard Eric's opinions. The most important part of that post was Eric's clear statement that there was discord in the community over this announcement. Having been one of the instrumental people in bringing Zope to the community, and having likely been the driving force behind the decision to create Perl for Zope, I would like to directly share the thoughts behind that decision. Please recognize that I have not read any of the posts on the list, and therefore, could very well be repeating important concepts written by others. I apologize if that ends up being the case, but rest assured that this would only mean that I am further underscoring those thoughts, because I didn't have the benefit of reading them first. First, a brief history lesson. I was a major Perl coder for 5 years. I built multi-thousand line Perl programs that did pretty sophisticated things, so I knew Perl pretty well. Then I discovered Python. I haven't written a line of Perl since then. This is not a put-down of Perl, but rather an elevation of Python, IMHO. It is through my discovery of Python that I came across Digital Creations (DC), in 1995. I contacted DC in 1997, and asked them if they were interested in funding. We consummated a deal in October of 1998. The deal happened only because they were a Python shop. A month later, after lots of "active discussion", we decided to Open Source the then named Principia application server. I was a driver of that decision as well. So, for the record, I'm a deeply rooted Python person, and believe it to be the ideal foundation for Zope. So, why would I push for the decision to create Perl for Zope? When I was at Union Bank of Switzerland (UBS), I used a tool that hooked into the Objective-C runtime, and unified the object model so that it was equally accessible from Objective-C, TCL, Perl and Python. Classes, methods, instance data, etc., were interchangeable, and worked transparently across languages. This was simply magic, and we made excellent use of this in a variety of our applications. Given how wonderful Zope was, it seemed to me that it too could be the foundation for people who had skills in other languages. My original thought was to use the same tool I used at UBS and incorporate it into Zope. This would have allowed TCL to interact as a first class citizen along with Perl. After much thought on the subject, we decided instead to partner with ActiveState (AS). This adds only Perl support (for the moment), but accomplishes a number of other goals, which will hopefully give the community some insight as to DC's direction on this. AS has significant Perl Zen, but has also recently hired some of the top Python talent around. They are embracing Python in a significant way, through Zope, but also as a standalone programming and scripting environment. For more on that, read: http://www.activestate.com/Corporate/Media_Center/News/Press959117519.html (the above will likely have wrapped poorly, and should be re-pasted as one long URL.) There's a more important point here though, and that is that if DC had taken my original approach, we'd have been in the business of managing the cross-platform codebase directly. In fact, that alone was one of the gating factors in not doing it. By outsourcing the cross-platform parts to AS, we each continue to concentrate on our own core competencies. For DC, that's Python, through and through. We've got a world-class team of Python experts, and that hasn't (and won't) change just because our platform will now allow others to hook their code into it. The people internally view this as a positive thing, so they don't feel that they will be forced to code in Perl. To reiterate, Zope is Python, and always will be. Meaning, the core of Zope will continue to be developed in Python (and C), and no one today envisions that changing. However, there was no uproar when we introduced XML-RPC. No one said "Hey, I don't want to be able to communicate with other systems, Zope rules, and others must perish!" Likewise, introducing a tighter coupling, giving others a choice in using their favorite language shouldn't cause you any more grief. To me, it's about "inclusion", not about change. I'm told that one of the protestations is that people will be expected to know Perl if they want to get a job coding in Zope. I guess I have a hard time understanding the problem here. Today, those shops that do most of their work in Perl, don't use Zope. So, they won't hire you anyway. Those who have already embraced Zope, will want you for your knowledge of Zope, and probably Python specifically. If Perl for Zope ends up getting Zope installed in a wider variety of shops and sites, then the above might become true. Wouldn't it also be true that there never would have been an opportunity for you to get a job there had they not adopted Zope either? My point is that if Zope gets wider adoption because it permits a wider range of programming choices to script its core, then more jobs will be available. At some shops, those jobs will have to be in Perl. But at others, "Best Practices" will rule, and we at DC (and I too) believe that this will continue to be Python. In fact, I could argue strongly that indeed even in the pure Perl shops that adopt Zope, they'll want/need a Python guru or two to track the core of Zope, in case they ever need to tweak that as well. This will create a larger job-base for the Python people than we have now. Here's my bottom line, and a bit of a rub as well. The Perl for Zope initiative is meant to be one which purely and simply helps the community, by broadening support for Zope, and getting it more widely adopted. DC is not intending to become a Perl consulting shop, so it likely won't have a near-term direct influence on our revenues. In fact, it will add to our expenses, as we support this wider community. So, we've undertaken this with a view toward others, rather than what's best for us in a "mercenary" sense. I would hope that you would all join us in that view and mission. Finally, I apologize deeply for the fact that I won't have the time to debate this interactively with the community. I will ask Paul to keep me up to speed on the nature of the responses, and if requested, or required, I'll post again with a summary follow-up of my views. I wish to conclude by repeating the original introduction here. I am a deep supporter of Python, as are all of the employees at DC. I am deep supporter of the Open Source movement, as are all of the employees at DC. I am deeply committed to keeping the core of Zope in pure Python and C, so that we can continue to deliver on the promise of our Services-based business. I hope that my prior actions on behalf of the community will at least earn me a "wait and see" attitude on the part of the community as to whether the above turns out to be true! Thanks for reading, and good luck to us all in this, and the remaining Zope Adventures!