Europython monday afternoon¶

Monday afternoon talks from the europython conference.

See also the complete write-up overview .

Alexander Limi - "Plone growing up":

Pretty new: the plone foundation, started to protect plone. The plone foundation now owns the code, instead of Limi himself. They've got an IP committee, a trademark committee (plone now has a worldwide trademark, which was a lot of work) and a marketing committee.

Plone has grown quite a lot since last year. A big help was the support of Computer Associates, but they decided in the end not to do any CMS anymore. Their product, based on plone, was BrightStor; they've now donated it to plone.

Coouple of big deployments: Oxfam UK and USA (with 14 million pageloads during the tsunami), Motorola, parliament of Brazil.

Plone 2.1 is upcoming! The first release that Does Not Suck (tm). It's much faster, probably at least 2x as fast. It especially holds out much better in big, heavy deployments. A core thing was to make both the user and the developer experience much more consistant and pleasant.

A neat feature is that you can choose how to display for instance folders. "Why didn't we do this before". A folder with lots of images can now get a photoalbum view. Which obviates a lot of specialist products like photoalbums.

Every slide had a stange quote below it. Here are a couple of them:

• "Plone - because a plonejob is better than a J2EE sweatshop"
• "Plone - it breaks, so you don't have to"
• "Plone - entropy embodied"
• "Plone - we have better hair than the Perl guys"

Heikki Toivonen - Chandler

Chandler is developed by the Open Source Applications Foundation, which is an experiment in itself as it was explicitly started as a foundation to develop "an" application. Hire developers and see what comes out of it.

Chandler manages all the data you're accustomed to using every day, like email, contacts, tasks, notes, etc. A Personal Information manager (PIM). It is open source, cross-platform and mostly python. They are really trying hard not to re-invent the wheel: they use a lot of 3th party libraries.

The license is GPL. So if you want to build a closed-source application based on chandler, you have to buy a license (as commercial licenses are available).

There is an extension model: parcels, which is their name for plug-ins. It should be very familiar for Eclipse users. Most of the core chandler applications are themselves written as parcels. There is a central repository that is used to store the actual data, but also settings for the various parcels and so.

For the user interface, they use 'wxWidgets'; the basic core that takes care of exporting and writing data is based on Twisted. That actually gave some problems, as Twisted has a "don't call us, we call you" worldview, but of course you really want the UI to be the boss.

Some challenges (which they think they can solve, though):

• They're the first mass-market cross-platform app written using wxPython. Things sort of work, but there are differences between the various platforms.
• Bloat. 20MB on windows at the moment. That's big for such an app.
• Internationalization/Localization. Python's unicode sorting is apparently not up to scratch.
• Accessibility.

A 0.6 release is planned for 12 october 2005, this should have a polished and usable calendar (which they plan to use themselves at OSAF).

There is a paper about the topic of this talk here

Paul Everitt - What is open source business?

Most of the "you're a bunch of communists" propaganda is phrased that way by those that have the current (soon to be death) "commercial" business model. Paul thinks, instead, that open source business is a much more pure version of a free market economy.

For open source business you need a few things.

1. Customers

   A couple of advantages to the customer: no vendor lock-in; quality; long-term maintainability.

2. Consultancy

   A couple of advantages to work in open source business: you get to work on world-class software; you get to choose your own tools; it is fun.

   Question to the people attending the talk: how big is your company? Most were in companies max 20 companies. Question: would you want to be a 150 person company? Almost all said NOOOO. But for some jobs

3. Developer

   Developers are awfully essential, they are the golden goose (if things are good). (I missed something here, it looks like numer 2...)

4. Governments

   The Lisbon agenda. Being the number 1 knowledge economy in the world. Halfway they looked at the status and saw that in the software industry it is actually going backwards. Some 39% of the EU expenses paid for IT goes to three USA software companies... Ouch. The only chance for the EU is open source.

   According to a Univerity of Maastricht study, of 13 projects that were researched, 3 had no intellectual property regime and of the 10 that had it, 8 had their copyright holding instance in the US. And most of the open source software starts in Europe. So it starts here and ends up in the USA.

In this open source business model there is a value chain. Just like in every supply chain, you must look at every link in the chain: is every link healthy or does all the money end up in just one link? Much EU research money, also for open source like projects, end up at the huge big companies.

One way in which this open source business value chain can be broken is by the big consultant companies that just by culture don't really interact with the open source community. They mostly only take, they don't give. Their developers need 8 levels of management approval to even be able to connect to a source code server. Apparently, for many big consultancies, marketing and sales is about 70% of their expenses.

There's a "whole product paradox". You can't get too big, otherwise the community will distrust you. But if you're not big enough, you can't make the whole complete product that many businesses need.

In Paul's opinion, an open source business should be a network. Just like open source business itself, in fact. That way they can have a lot of the benefits of being collectively bigger without the drawbacks. Good example: the Zope Europe Association . Zest software, were I work, is a member of the Zope Europe Association, so I'm happy :-)

Arnar Lundesgaard and Andreas Johnsen - Zope Topic Maps - building metadata-based portals with open standards

Topic maps are an official ISO standard and have fixed data formats. They are more or less a bit similar to RDF, but topic maps are more elaborate and a bit more high-level.

"A topic is something you might want to say something about". So me, or the carpark outside. Occurrences are containers or pointers to data about a subject (like a picture of a person) (note Reinout: sounds like attributes/properties). Topics are used to say what kind of occurrence something is ("a picture").

Associations describe relationships between subjects. We go through all this effort in order to get a generic mechanism by which we can later add all sorts of new topics, associations, etc.

(Demo of their system. As all the concepts (topics, associations, etc.) are defined inside the system, they can be happily added. After adding an "Employee" topic type, you can start adding "Employee" objects. The term that, in zope terms, best explains this is "extensible schema" imho.)

Some advantages. For information architects it is a powerful tool for prototyping and midelling: no forced hierarchies!. For developers it is a generic self-documenting data model. For editors it is an easily extensiible content management systems. For end users there is associative navigation and improved search.

Arnar jokingly mentioned that, from developers, they turned into "ontology engineers" which made them sound much smarter than they really are.

I asked them what he liked more, topic maps or RDF. His answer (admitting he was biased): topic maps are easier to understand for ordinary users. It is easier to explain. It is how the brain works. RDF has a simple model that is quite understandable to information architects, but not for ordinary users.

Btw, they are working at Bouvet .

Tarek Ziadé - CPSMailAcces : a webmail application in CPS3 using Zope 3 and Five

CPSMailAcces should be usable in today's zope2-based CPS, be easily portable to upcoming CPSs and it should be as easy to use as a rich mail client. It also had to be reliable for big intranets.

They implemented using Five, so that it would be portable to zope3. Ajax (analogous javascript + xml) was used to make it a bit like a rich mail client.

They implemented a sort-of 80/20 rule: 80% of the work is done on the zope side, max 20% of the time there's synchronising with the mailserver. So zope tries to do most of the work itself, saving mailserver connections. For every message, they store MailMessage objects with the id, the header, etc., just not the attachments and so. So: caching.

For the indexation of the message properties (and optionally the body) they used Zemantic, an rdflib based catalog. With such an RDF backend it is easy to store all the relations between messages, for instance for showing a threaded view of a set of related messages.

A lot of work needs to go into scalability. Zope corporation has a product called Zasync that can help a lot, but you need to be really really sure that your code is thread-safe. Otherwise you're done for.

Thanks to Five, the way to Zope3 is short. Here's the link to the project . At the end Paul Everitt advertised the blogs by Nuxeo people .

Pravir Chawdhry - Zope/Zeo in Real Life Deployment

Pravir works for the European Commission joint research centre. His work is on the "European extra-judicial network for out-of-court settlement of cross-border consumer complaints". They are trying to set up an infrastructure for allowing you to register complaints with consumer complaint organisations in other countries.

Zope2.7 with the bundled ZEO (Zope enterprise option) is easy to deploy, more easily configurable than 2.6 and it worked out of the box at low-medium loads.

They subcontracted two parts to two zope companies and got surprised reactions from some of their EU collegues when it was finished: they were used to programmerYEARS instead of programmerWEEKS.

They have an integration environment which is a collection of PCs which is configured just like the real system, this is used for testing out new versions of the software. Likewise they have a test environment with the exact versions of everything, just like on the servers. This test environment is also used for training and demonstration.

eGovernment applications are restricted by a lack of in-house expertise and strict public sector rules on engaging external suppliers. Also, there is a need to focus on value to the customer rather than ideology.

An important conclusion was that it is a good thing to continually track your requirements and keep an eye open for zope community products that might fit well with those requirements.

The website address is http://eejnet.jrc.it/