Weblog: Archive

Apart from my own session, I went to see Danese Cooper's session on Corporate Blogging, which focused on how Sun uses blogs and other collaborative tools to aid in a cluetrainish transformation to a more customer focused and open organization. The related policies and success stories were a good starting point for convincing other companies to do the same.

The session of legal issues of Open Source was also interesting, highlighting the recent German court ruling that upheld GPL and the risks arising from the fact that liability from neglecting potentially harmful issues in the software can't be waived with a license in most European countries.

The Tiki session also provided some interesting ideas, including visually mapping a Wiki using the Graphviz package and rendering location information usingMapServer and its PHP extension.

We're also discussing how to make OSCOM more visible and work better. Some ideas:

• Loosen the restrictions on getting feeds aggregated on Planet OSCOM and try to get more feeds there. Theoretically all CMS and web related content would be acceptable, but we still don't want any cat pictures
• Present OSCOM more clearly as a "common specifications" project for CMSs, like Freedesktop.org does for GNOME, KDE and other desktops
• Create a "We participate in OSCOM" link button campaign and try to get Open Source CMSs to link there
  Concern: Why would CMS projects want to link to their competitors? Maybe we should remove the CMS matrix and be more a specifications and interop body

To support making Planet OSCOM more active, Chregu installed the software running Planet PHP there. The old net.nemein.rss powered aggregator will be replaced by this after Christian has time to add some features and tweak the CSS to better shape.

The big problem for Planet OSCOM has constantly been how to find more interesting feeds to be aggregated there. One solution there would be to use the relationship mapping features of Frassle to find new relevant feeds. After some planning with Shimon Rura, this could work in the following way:

• Planet OSCOM sends its list of subscriptions every night to Frassle in OPML format
• Frassle would download and parse the feeds, and try to find related content (based on common links)
• Frassle would return a list of new feeds found to Planet OSCOM, which would automatically subscribe to them

This would all require a bit of hacking, both in adding import/export capabilities to Frassle and in ensuring Planet OSCOM gets good feeds, but it would be a very interesting proof-of-concept for mapping related feeds. If it would work out, it could provide a model for all news aggregators on how to find new content.

After the actual conference program we brainstormed with Thorsten Scherler to the OSCOM Wiki about CSS naming conventions that would enable different designs to be used with same XHTML DIV structure.

In the evening we had a nice dinner followed by quite a few beers in El Lokal, a leftist pirates' hideout styled place. Discussion ranged from participatory budgets and other democratic innovations in Brazil, and the state of Bolivian Navy after the Guano wars of late 19th century to Open Source business models and travel in Russia.

El Lokal closed around 2am, and we continued to a party in a creepy 70s styled factory building in the tech area of Zürich. On saturday I'll fly back to Helsinki.

I'm now sitting in an old, creaking commuter train, surrounded by beautiful Finnish autumn colors. Today has been a pretty typical day for me in IT sales, starting with back luck with train schedules that forced me to sit most of the day in this old train instead of the fancier InterCity trains that come with power outlets and cafeterias. What has happened so far:

• Wake up
• Make finishing touches to a customer-specific Intranet demo
• Arrange some meetings for the rest of the week
• Check out appropriate train schedule to another city
• Because of some last-minute CSS modifications almost miss the train, forcing to lane-split with the motorcycle to the railway station
• Make it to the train, the demo front page still broken because of the CSS fixes
• Connect your laptop over the slow Bluetooth-GPRS connection and fix the CSS
• Reread the RFP and note that you've forgotten one feature, call colleague and ask him to implement it
• Reach the target city and take a taxi to the client
• Exchange some awkward pleasantries with CEO of a competing company at the door
• Hold the demo and discussions with the client, experience some issues with both the latest Firefox and the client's proxy
• Take taxi and train back
• Provide quotes for some new projects to partners over the phone

The connection problems in this process got me thinking again about better offline access to my data. Most of our back-end systems run using the Midgard Framework and OpenPSA, and there would be several options. Now I use the lightweight solution where:

• Apple iCal keeps a read-only version of my OpenPSA Calendar
• I can blog using MarsEdit and post when back online

What other data would be convenient to have available offline? At least contacts and email spring to mind.

Contacts could probably be synchronized one-way by downloading a vCard file of all contacts from OpenPSA Sales, as Apple Address Book automatically receives and imports them. The problem here would be the same as with calendar: not being able to sync the data back to the server.

As to email, Thunderbird has kind of offline mode available, but I would have to keep the inbox quite minimal to be able to use it. Maybe a more aggressive folder usage strategy would help here. Essentially I should archive all interesting documents to folders specifically created for each customer or project. TODO items I can easily drag-and-drop to our support mailbox which gets imported to OpenPSA Support.

His notion might have backgrounds in only looking at the projects listed on OpenSourceCMS.com, which only lists lightweight, mainly PHP-based content management systems, not any of the heavier-duty ones.

However, it is true that most Open Source CMSs are not that good. A major cause for that is duplication of effort. Everybody wants to build their own CMS and not improve the projects started by others, and so the wheel has been invented a huge amount of times. OSCOM seeks us to improve that by advocating collaboration and usage of common standards.

Let's take a look at how the improvement recommendations apply to Midgard CMS:

Make it easy to install. Your tool will see better adoption if you stop to consider the out-of-the-box experience before you ship it.

This has traditionally been the weak point in Midgard. There have been many dependencies to solve and packages to compile. However, Midgard 1.6.0 is a big improvement to this.

The Debian packages made by Piotras and Daniel's packages for most RPM based distributions made with Build Buddy will make the actual installation very easy and having MidCOM environment available out-of-the-box helps too.

Make it easy to get started. Give first-time users a series of quick wins that become increasingly complex. When I first log in, I want to create a Web page.

Even after installation it has been difficult to figure out how to get started. Now MidCOM and Aegir are bundled in the midgard-data package and so the Getting Started guide should be easy to follow. Midgard 1.6.0 also provides a friendly Welcome Page.

On a longer term there will also be the Midgard Site Creation Wizard.

Write task-based documentation first. Most systems have installation instructions that are quite good: "First do this, then do this, this, and this." But when it comes to actually using the CMS, they revert to feature-based docs, carefully outlining what each feature does, and typically from a back-end perspective.

We're mainly guilty as charged. The new documentation chapters Getting Started and Using Midgard CMS seek to help with this, though.

Separate the administration of the CMS from the editing and managing of content.

Midgard does this already. MidCOM Authoring Interface System (AIS) is the end-users' content management interface that is provided as part of the website itself. For site developers and administrators there is the Aegir interface which provides access to users, templates and code.

Users of a public web site should never - never - be presented with a way to log into the CMS.

This really depends of preferences. Maintainers of small business websites like to have the login link handy so they don't have to remember or bookmark it, whereas bigger organizations usually want to hide it, and potentially disable access to the editing interface from public network completely.

In MidCOM Site Template there are three possibilities here, depending on site settings (/midcom-admin/settings):

• Login link is always displayed (default)
• Login link is never displayed
• Login link is displayed only for specific port (internal staging port, SSL etc)

Stop it with the jargon already. I don't know what a portlet is. Or a component, module, block, or snippet.

Good point. Being mostly techies themselves, CMS developers usually fall into using jargon. And since there is no standardized vocabulary for content management, the jargon may vary greatly between projects. Jargon should not be allowed in marketing descriptions for the CMSs, and even elsewhere it should be documented or accompanied with a description.

Why do you insist Web sites have "columns"? I've used quite a few systems now that have the notion of a 3-column layout. They give me the ability to turn columns off and on, and put "portlets" into "content-slots". Where does this assumption come from?

The three-column layout is a very typical convention in blog engines, community CMSs and portal systems modeled after Slashdot. Most real CMSs provide a less cookie-cutter like approach.

In other news, Piotras reported that according to SecuritySpace Survey, Midgard usage grew 40% during September. Apparently we're doing something right.

• All work positions will appear as resources in the group calendar
• Doctors can apply for a particular shift by making a reservation
• Email notifications will be generated monthly about unallocated shifts and sent to all doctors
• After each day the times of the work shift will be copied by the system to the doctors' hour reports
• The doctors check the generated hour reports and modify or add details as necessary
• The hour reports will be used for invoicing and customer reports

This way the doctors can easily control their availability and make their preferences on positions and shifts visible to the management. The management will also have a clear view into distribution of work loads, doctor availability and the filling of the shifts. Since hour reports will be automatically populated from the work plan, this will also reduce the amount of duplicate reporting needed.

Some modifications will be required to OpenPSA to make it work better with shift planning.

• Coloring tentative reservations differently from final reservations in the resource and week calendar views
• Enabling linking calendar events with tasks or processes
• Creating the copying tool for populating hour reports from the calendar events

Documentation about particular work positions or locations will be stored as attachments to the tasks. This enables doctors to quickly access them from the OpenPSA front page.

In addition to using Projects and Calendar, the client will also start using some other parts of OpenPSA, including Sales for managing new business projects and Discussion for company's internal chat.

To help make the system more popular the Horde webmail application will also be integrated to the OpenPSA interface.

The organization works in a very virtual and distributed way, and so OpenPSA will provide them with all the communication and management tools they need for efficient operation. Other reasons why the chose OpenPSA included a very good feature match, a friendly user interface, and cheap hosting costs.

Since this was our first hunting trip we concentrated mostly on getting familiar with the forest area and what game can be found there. We slept the night in a Finnish teepee (laavu) with a fire to keep warm.

During the reconnaissance trips we saw rabbits, reindeer, swans and several species of arctic birds. I got close enough to try to shoot a willow ptarmigan (riekko) from about 35 meters but unfortunately missed. We also got close enough to a rabbit but decided not to shoot because we had too light shots loaded into our shotguns.

Some points for the next trip:

• Driving 12 hours each way was quite tiring. We should consider taking the car train to Kolari instead
• Camping in middle of the hunting area probably scared some game away. Next time we could camp elsewhere or rent a cabin from Muonio
• We should take a rifle in addition to the shotguns. We could've shot at least one black grouse (teeri) with a longer range weapon
• We should try to find a general purpose shotgun cartridge. Something around 3mm shots could work for both grouse and rabbits
• We need to find more about the game we're trying to hunt. Activity periods, habitats etc. to make them easier to find
• Some Skeet shooting would be good for accuracy

Some photos can be found from the Muonio gallery.

WebDAV is an HTTP based file transfer protocol supported by most major operating systems and Microsoft Office. WebDAV support now makes OpenPSA Documents a much more useful document repository.

The WebDAV server was implemented with the PEAR HTTP_WebDAV_Server package. So far I've only tested it as a network filesystem for Mac OS X and Windows XP and with the Goliath and DAV Explorer WebDAV applications. On Mac everything works quite smoothly but there can still be some glitches with Linux and Windows.

I would be happy to receive more test reports with other DAV clients. To try it out you need the following:

• Midgard 1.5.0 or later
• Latest CVS version of OpenPSA
• PHP 4.3.x
• The PEAR HTTP_WebDAV_Server package

Once all these are installed and running you can try the WebDAV server by pointing your DAV client to the /docstore_dav/ subdirectory of your OpenPSA system (note: the actual OpenPSA system, not OpenPSA Manager). For example, http://www.example.com/openpsa/docstore_dav/.

In Mac OS X Finder this happens by clicking Go -> Connect to Server or pressing Command-K. On Windows XP this happens via going to My Network Places and adding a new one.

Now the server stores quite verbose debugging information to /tmp/docstore-webdav.log. If you encounter issues, please mail me the relevant pieces of that log file. Logging will be turned off by default in a more stable release.

Caveats

• Folder copy/move action support is very hacky
• The WebDAV server does not yet support the access control system in Documents
• There are problems with special characters in file names
• Locks are currently used only for information, following them is up to the client
• Looks like WinXP allows only MS Office to directly open and save documents to an SSL-encrypted Web Folder, other applications require a local copy
  The WebDrive application solves this by mapping the encrypted Web Folder to a drive letter.
  As pointed out by Alan, Novell WebDrive provides a free tool for the same (Tomi noted that the license says it is free only if used together with other Novell products. Can anyone confirm?).
  Unencrypted Web Folders can be mounted without external tools.
• Nautilus 2.6.3 seems to have problems with the whole DAV connection

Here is log file of the current implementation being tested with the WebDAV litmus test tool.
Note: this file was first saved to our OpenPSA repository and then inserted from there to this blog post via MarsEdit. Desktop integration rocks!

Categorization works quite simply; the MetaWebLog API connector for the de.linkm.newsticker looks at its schema definition, and if it finds specific field definitions it will enable categorization. The two options here are:

Multiple categories per post:

"categories" => array (
"description" => "Categories",
"datatype"    => "multiselect",
"location"    => "parameter",
"multiselect_selection_list" => array (
"cat1" => "Category 1",
"cat2" => "Category 2",
            ),
        ),

Or single category per post (as is currently used on this blog):

"category" => array (
"description" => "Category",
"datatype"    => "text",
"location"    => "parameter",
"widget"      => "select",
"widget_select_choices" => array (
"cat1" => "Category 1",
"cat2" => "Category 2",
            ),
        ),

Note: the category field must be stored in parameter location for MetaWebLog API support to work.

Now that this works well, I was able to set my MarsEdit to complain if I try to save an entry without setting a category. Categorization is important on this blog as it is used by the different Planet aggregators.

This means that now I can almost completely manage this blog from a desktop client. Only thing remaining would be handling the separate abstract fields, but I might as well make my next layout do without them.

The other new thing is that the net.nemein.rss news aggregator for Midgard CMS now has preliminary support for the Bloglines API. Bloglines is a popular web-based news aggregator that can be used as a central syndication server to reduce RSS-induced congestion.

It is easy to set net.nemein.rss to fetch it news from Bloglines instead of querying the servers independently:

• Register to Bloglines and subscribe to the feeds you want to aggregate
  Note: you can populate the Bloglines subscription list by uploading the OPML list of subscriptions you get by accessing /channels.opml in net.nemein.rss
• Create a topic handled by net.nemein.rss
• Go to Settings and select Bloglines from Subscription mode
• Enter your Bloglines username and password to net.nemein.rss

The infrastructure for this seems to work. Unfortunately I was unable to test this with a real production setup because Bloglines Web Services seem to respond extremely slowly today, causing MagpieRSS to timeout.

Updated 22:33: After adding some debugging calls I found out that the reason for problems with getting feeds from Bloglines was with HTTP Basic authentication. Bloglines uses email addresses as usernames.

While fopen happily opened such an URL after the email address was rawurlencoded, the Snoopy library in MagpieRSS was a different case. As I found out, it uses PHP's parse_url function which doesn't support @-signs in usernames.

I fixed this by a quick hack to the Snoopy fetch method:

$URI_PARTS = parse_url($URI);
if (!empty($URI_PARTS["user"])) {

  // PATCH for Bloglines support, @ in usernames (bergie)
  if (strstr($URI_PARTS["user"],"%40")) {
    $URI_PARTS["user"] = str_replace("%40","@",$URI_PARTS["user"]);
  }
  // END PATCH

  $this->user = $URI_PARTS["user"];
if (!empty($URI_PARTS["pass"]))
  $this->pass = $URI_PARTS["pass"];

To make things easier I upgraded net.nemein.rss to include latest MagpieRSS. This means that Atom feeds should be supported now as well.

Even though the Bloglines API support works now, it still seems to be phenomenally slow, at least with my 100 subscriptions.

We were thinking in OSCOM 4 about how to get the different Open Source CMS projects to feel more connected with the OSCOM process. One part of this was to get some link buttons that would make it easier for the projects to link to OSCOM.

Marc Infield from Infield Design responded quickly to Gregor's request. Here are his OSCOM "stamps":

Note: this logo is not under the open content license used on my weblog

The usage policy for these is still unresolved. Some ideas would be, though:

• The winged stamp would be the official OSCOM logo, usable only by the OSCOM association
• The other stamps could be used by individuals, projects and companies as a badge showing participation to the OSCOM process
• For companies and individual developers this means attending OSCOM Sprints or conferences actively and having a weblog or news feed aggregated on Planet OSCOM
• For Content Management Systems it means that they have to be available under an OSI-approved license and listed on the OSCOM CMS Matrix
• We could have similar logo policy as Debian has

This way the OSCOM stamp would be a quality criteria for CMS projects, telling that they are committed on working on implementing common standards in their system and developing the field of Open Source CMS in general. It would also enable end-users to distinguish real Open Source projects from proprietary ones, a bit like the OSI keyhole does for licenses.

Comments?

Midgard 1.6.0rc2 was released earlier today. I decided to try it on my local iBook.

Most of the stuff seems to install just like in my earlier installation, except that some packages have been renamed. midgard-lib is now midgard-core and mod_midgard is now midgard-apache1.

First problem was that I tried to install Midgard to a custom prefix, /usr/local/midgard, and midgard-config failed to give correct include path for that. After a bit of investigation, I found out that this was broken it this commit.
Rambo pointed out that this was due to incorrect Perl string comparisons in the code. Fixed now.

Next change to the installation notes was that configure for midgard-php4 needed to have the apxs path specified:

$ ./configure --with-midgard-config=/usr/local/midgard/bin/midgard-config\
   --with-apxs=/usr/local/apache/sbin/apxs

Another thing to note was that since Midgard's Apache module has changed its name, the old module must be commented out from httpd.conf if you have an earlier Midgard version installed.
Also, in that case apachectl restart won't be enough. You have to run:

/usr/local/apache/sbin/apachectl stop
/usr/local/apache/sbin/apachectl start

After the successful Midgard installation the next thing was to turn to midgard-data. Midgard 1.6.x series have a new database setup tool, datagard. Unfortunately it didn't run on Mac at first, but Piotras helped me with that and promised to fix some Fink-related path issues in CVS.
Here's how datagard looks like:

When datagard had upgraded my old Midgard database to the new MultiLang format, I was ready to access my Midgard Welcome Page. It greeted me with:

Next I'm testing setting up a new database with datagard.

All in all, Midgard installation on Mac OS X is still a bit difficult because of the dependencies. Chris Stephens pointed me to an interesting project that could help here:

MAMP is a Mac OS X installer (or disk image) package that installs the whole Apache, MySQL and PHP combo into the Applications folder and provides a Quartz application for running the processes. If we could get Midgard installed into this, it would make things a lot smoother.

For years Midgard application development has been constrained by the fact that most of the programming work has had to be made through a browser window. Now there is a solution through WebDAV.

Earlier usage of better editors has been possible through two slightly hacky solutions:

• PHPmole is a nice IDE for PHP. However, it is written using the PHP-GTK toolkit, making it difficult to install
• The other solution was synchronizing code snippets to filesystem using the Aegir FileSync AddOn. However, this didn't work for creating new snippets in the file space

But yesterday I wrote a new Midgard WebDAV Server class, initially with only snippet editing support. With this system the Midgard snippet library space can be exposed as a network filesystem, or a Web Folder in Windows. This means that the code snippets can be managed completely with all the regular editors and IDEs.

Here's how browsing the /net/nemein MidCOM component space looks like on my OS X box:

The WebDAV Server class can be found from src/php-libs/webdav directory of the Midgard CVS repository. It requires PHP 4.3+ and the PEAR HTTP_WebDAV_Server package. To use it, create an active and authenticated page with empty style and the following content:

<?php
mgd_include_snippet("/MidgardDav/Server");
?>

Since this seems to work quite well (although tested only on Mac), we wanted to see how we could improve our development work using WebDAV. The first solution that came to mind was using the ultra-cool collaborative editor SubEthaEdit. With it we can easily see what the others in the Nemein team are doing, and get comments and review done. It really makes pair programming much more efficient.

As I write this I'm sitting in a WiFi-capable cafe, hacking on some components together with Kaukola. Here's how it looks (we were adding a new feature to the de.linkm.taviewer component):

The lines with blue background have been last edited by me, and the ones with pink background by Kaukola.

Based on my earlier blog entry, there was an interesting talk in OSCOM 4 about CSS Naming Conventions.

My after-talk discussions with Thorsten Scherler led to development of OSCOM specification for CSS Naming Conventions.

I've now used the XHTML skeleton from the specification for some websites, and have been generally quite happy with it. Here is a simple Midgardization of it. Simply paste it to the <(ROOT)> element of your style, and then add the CSS formatting to the <(css)> element.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN""http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="&(midcom_site["site_language"]);" lang="&(midcom_site["site_language"]);">
  <head>
    <title><(page-title)></title>
    <meta http-equiv="Content-Type" content="text/html; charset=&(midcom_site["site_encoding"]);" />
    <style type="text/css">
      <!--
        <(css-local)>
        <(css-extra)>
      -->
    </style>
    <link rel="stylesheet" href="&(midcom_site["uri"]);style.css" type="text/css" />
    <(head-extra)>
  </head>
  <body<(bodytag-extra)>>
    <div id="container">
      <div id="branding">
        <div class="grouplogo">
          <!-- Insert logo here -->
        </div>
        <div id="branding-tagline">
          <?php echo $GLOBALS["midcom_site"]['site_welcome']; ?>
        </div>
        <div id="branding-trail">
          <(breadcrumb)>
        </div>
      </div>

      <div id="nav">
        <div id="nav-main">
           <(navi)>
        </div>

        <div id="nav-language">
         <!-- Language switching links -->
        </div>

        <div id="search">
          <div class="search-input">
          </div>
        </div>
      </div>

      <div id="content">
        <div id="content-main">
          <(content)>
        </div>
      </div>

      <div id="siteinfo">
        <div id="siteinfo-credits">
          Created by <a href="http://www.nemein.com/">Nemein Oy</a>.
          Powered by <a href="http://www.midgard-project.org/">Midgard CMS</a>.
        </div>
        <div class="lastmodified">
          <(last-updated)>
        </div>
        <div class="siteinfo-legal">
         <!-- Copyright disclaimer and possible licensing -->
        </div>
        <div id="feedback">
        </div>
        <(edit-this-page)>
      </div>
    </div>
  </body>
</html>

The places with comments are ones I'm still thinking how to pull dynamic content into.

Helia will be using OpenPSA for managing all their corporate connections, including students' work orientation periods and their service sales.

However, some of the screens in Sales have been left with quite an industrial look by Eero. One of the worst was the campaign query tool, which is used for searching contacts to be included to a campaign (mass mailing, event registration etc). This query form was quite hideous to begin with, but with addition of some new fields it simply didn't scale.

I've now reorganized it for better clarity:

Previously the query fields were organized quite randomly, but now they're in four separate groups:

• Area selectors (country, post codes)
• Company type selectors (business area, number of employees)
• Connection type selectors (products offered to them, sales project statuses)
• Result criteria (sorting etc)

Also, the screen now allows direct creation of new campaigns.

Planet Midgard is the blog aggregator displaying what's going on in the Midgard community.

Planet Midgard is now running latest version of net.nemein.rss aggregator, meaning a bunch of new things:

• Support for feeds in Atom format (previously we could aggregate only RSS feeds)
• UTF-8 support, meaning that we can now aggregate blog postings in non-western characters (especially Russian seems to be popular in the Midgard community)
• Hackergotchi support: if your feed has been marked to contain a "hacker head", it will be displayed together with your posts. See Planet GNOME for a good example on this

So, with these updates I would like to call for two things:

First of all, if you're a member of the Midgard community (contributor or active user), please get your blog aggregated on Planet Midgard. If you already have a blog, just mail me the URL to your RSS or Atom feed.

And if you don't have a blog, please start one. Blogs are a great way to communicate your ideas and stuff you're working on.

It is very easy to start blogging, either just create a new Midgard topic powered by the de.linkm.newsticker component, or sign up to one of the free services like Advogato or Blogger.

Note that we can also aggregate news releases from Midgard companies, and blog postings in languages other than English. Planet Midgard already aggregates Nico's posts in German, Alexander's posts in Russian and WALHI's posts in Indonesian.

Second, if you're already aggregated on Planet Midgard, please make a hacker head image of yourself. This gives a face to your posts, adding to the community feeling. If you see who is posting, it is easier to feel it as a conversation:

The hacker head (or hackergotchi) is an approximately 65 pixel wide and 85 pixel high transparent PNG image showing your face detached from its surroundings and added with a drop shadow. See some examples in Planet GNOME.

Once you have your hackergotchi image done, upload it somewhere and mail me the link (you can also mail me the image itself).

If you don't have the necessary graphics skills, mail URL to image you want to have it made from here and somebody will help you out.

BTW, for those with RSS aggregators (like NetNewsWire or Thunderbird), Planet Midgard is available at http://www.midgard-project.org/planet/rss.xml

Updated 2004-12-14: Hackergotchis displayed on Planet Midgard are now displayed also on a separate collection page.

Major Finnish retailer Anttila was given the Finnish Quality Award 2004 yesterday by Speaker of Parliament Paavo Lipponen. Excellence Finland has an announcement on the award in Finnish.

I've worked together with Virpi Mikkonen and the rest of the Anttila team in several related projects, and they are really committed to the quality process. The projects we've implemented have included management of customer feedback using OpenPSA Support and process diagram integration into their Midgard-powered Intranet.

Congratulations to everybody involved!