deegree PSC Meeting (2012-09-27): Strategy meeting with invited guests

PSC Attendees: HermanAssink, JensFitzke

Guests: TorstenFriebe (TMC), Bernhard Reiter (Advisor), MarkusSchneider (TMC)

Location/Time: Essen, Germany, Linuxhotel / 10:15 - 16:10 h CET

1. Agenda

Introduction
Expectations
Discussion
Actions

2. Introduction

The idea to have a meeting like this came up in the July PSC meeting and was further refined in the September meetings: 2012-09-03 and 2012-09-17. It was first labeled "Commercial aspects", but during the discussion in preparation for the meeting it turned out that its central topic is the project community.
As guests the PSC invited Torsten Friebe and Markus Schneider (both TMC members) and Bernhard Reiter (Intevation).
With this setting we are able to represent both the project's committees and the three main supporting companies (IDgis, lat/lon, Occam Labs).
Unfortunately, due to urgent tasks in his job KlausGreve could not attend.
All meeting members sponsor their own participation except Bernhard who is paid for his attendance and advice.

3. Expectations

As a start a collection of the participants' expectations to the meeting was compiled as follows:

We shall be able to establish an institution or organization as a means to better embrace the community.
We shall find a way to make deegree a 'real' open source project.
The project's representation shall be more attractive, friendly, open.
The project's products shall be more professional and easy to use.
We shall be able to increase the user base.
We shall discuss/clarify/change the roles of the PSC, TMC and the companies involved in the project.
We shall better communicate that there is a distinction between lat/lon (as a company) and deegree (as a project or initiative)
We shall be able to find a way to raise money for the project's continuity, especially regarding general activities (like maintaining the infrastructure, marketing and outreach, general software engineering tasks).
We shall think about Bernhard's proposal of using the term 'initiative' rather than 'project'. NOTE: In these meeting notes the term 'project' is used to refer to deegree as an ongoing initiative.

4. Discussion

The discussion was extensive and took most of the day. It covered the following topics.

4.1. deegree's market position

During the discussion it turned out that deegree's market position is not clear at all. Especially when looking at neighbour projects the following questions appear:

In how far is deegree comparable to e.g. UMN Mapserver or Geoserver and in how far does deegree want to be like those?
What is the main user group of deegree (compared to other projects)?
How important is a world-wide user base (compared to e.g. a user based with a clear focus on Europe)?
How do we approach/enlarge this user base (most efficiently)?

It became clear that we had to focus on the project's stakeholders...

4.2. Stakeholders / Inside and Outside

We obviously have to deal with two main groups of stakeholders in the project ...

... where on the left are the technicians, mostly individuals, doing technical or operational stuff (the project's 'back end'). They usually do not spend money, but time on the project. On the right are users, mostly as institutions which are interested in high-quality products and solutions based on deegree (the project's 'front end'). They are willing to pay for this.

This leads to the following challenges:

The two groups need to be addressed differently, according to their needs.
The project needs a mechanism to organize the pool of resources, especially with regard to main infrastructure, code maintenance or outreach activities.

4.3. A formal project organisation or institution

A formal project institution might help to improve the overall project's organisation, appearance and momentum. On the other hand it will absorb quite some money to establish such an institution. Bernhard's advice here was not to invest any effort in this as long as 1) the role and responsibility of the institution is not 100 per cent clear and 2) resources to establish the institution are limited (which currently is the case).

In the discussion we have been playing around with metaphors for the institution, namely "umbrella" and "pool"...

... where the institution might act as an umbrella to protect their members (against the rain or the sun) or it can be seen as a pool (of resources, where you can jump in). Instead of establishing this institution we will rather

improve the project's internal communication
improve the project's outer apperance
by doing so derive rules for a community and a partner model

At a later stage - when resources are available and necessary rules are identified - we might then be able to establish a deegree institution.

4.4. A partner model

The term 'partner model' refers to a set of rules and regulations which define how a set of institutions (namely companies) can work together to support the deegree project. Currently the following three companies are mainly investing into the project: IDgis, lat/lon, and Occam Labs.

The future partner model shall include structures and procedures to define

what a partner is
if there are different kinds of partners
different kinds of input (resources)
accession and leaving
how partners interplay
how resources can be pooled

5. Actions

The results of the meeting will be documented publicly available in the deegree wiki (this page)
The deegree-users mailing list will be the dedicated main communication/decision channel of the project. This will be annouced by an email which refers to the meeting results and which will be send to all deegree mailing lists (PSC action).
The three main supporting companies (IDgis, lat/lon, Occam Labs) have committed themselfs to spend each 10 hours "extra" per month solely for the purposes of the community. This commitment has a minimum lifetime of 6 months. They will ask the community for them to decide how the time is spend best.

'Leading by example' is the way to go here. This means that everybody will use the communication channel in a way in which he/she expects it to be used. This includes an attitude of humbleness and the explicit objective not to put forward yourself or your company:

It is always good to read a good book. Bernhard's suggestions are: Karl Fogel 'Producing Open Source Software' and Jono Bacon 'The art of community'

6. Other stuff

For reference - An overview of the meeting pin board:

CategoryDeegreeOrganisation