Bjoern Michaelsen talks about growing the LibreOffice community

Bjoern Michaelsen is on the Board of Directors at The Document Foundation. We talked to him at the recent LibreOffice Conference in Rome about the challenges of growing a community. Also, we look ahead to some new ideas for hackfests.

Download LibreOffice: https://www.libreoffice.org
Get involved: http://tdf.io/joinus
Support us: https://www.libreoffice.org/donate/

Yeah I don't know about the numbers but

just the places that we are.

It grew every time and I think

it's also just that you expect so much more

and take so much more for granted.

It's really dangerous actually.

If you just grew along with the

project and you don't realize

the changes have been on the way.

There was one of the things for example

at FOSDEM we have this issue,

where we discussed, I think,

where do we go for dinner, and

essentially we realized that just to go somewhere with

everyone is not going to work in Brussels!

And it used to work in the beginning

and I said "Well, why don't we go somewhere"

Well at some point you grow

two sizes then you realize that

you have to take

well to organize things differently

and to to really take care

to do things more decentralized, because

if you centralize things, well

at some point it doesn't scale because

you end up with just the tiny Board [of Directors]

trying to keep track of everything around it

and not being able to, because

what do you really want is that people just

feel empowered to do stuff less than themselves.

And the longer the distances are,

the harder this gets.

I'm from Hamburg, which is the city

that was already the city of StarOffice,

before it was OpenOffice,

before it was LibreOffice.

So there are a lot of people already there

I always had an

information advantage in that way,

once I joined the project.

I'm late to this

compared to others like Eike [Rathke].

There are even more from the start so

I'm not even strictly speaking

a founder of LibreOffice

because I was still at Sun at that point of time. So,

I joined like, yeah, half a year later.

But since I've been in Hamburg

I've seen quite a bit of the beginning there.

But this is exactly the things that

we need to change to get more visibility

and transparency to people outside:

That we are only just people and there's nothing

that we don't want to talk to someone.

This is really not what it is.

It's mostly that, I think,

there's roughly a number of 150 people that

you can keep like connections to and

remember and keep friendships with, and

beyond that you just keep losing track

and it's really hard to just be

on the same personal level.

Because we're so successful right now.

So we grew too fast

we were just successful! I'm sorry!

Well, there were lots of things.

You only think about things that weren't going well

because you learned from them

so we learned a lot! But...

yeah, I think,

like I've said: one of the things is really

you have to remember, always, that

there are mistakes and that it's that

you're...

you can't take everything for granted.

So you have to be willing to to learn and

to adapt because things change and

the market changed, the project changed in

the environment changed, and

the people who are interested in the project changes

and now all these things are moving

and you can't stick to just something

because it was the right thing to do

at a certain point in time.

You always have to reevaluate

what's the right thing for the current situation and

maybe, or even for the future.

If you're just working for the current situation

you're already behind.

Again, like I, said I care deeply about the people

and I think LibreOffice is a project

where one of the major advantages

is not so much the

technical stuff that we can offer

but the project, and the way it is done

and the way - what you can do with it

as a project and not as a product. So

it's very much about an experience

like being in this project and feeling that you can

do change and, then that you can

make a change in the project and with

that outside of the project. But

not so much like it's a given thing that is

lying there then we just stick on the

branded icon and that's it.

It's something to be involved in really.

And I think this is something we

constantly have to work on to improve

because there's this arc we have to cross,

this river we have to cross unlike other

projects, and ideally we want I think -

I would like the project to be like the

Linux kernel was in the

beginning -in the early days. And it set off

so easy, in quotation marks,

because it was used exactly by the people

who contributed.

It was the system administrators,

seeing: oh this is something I can use,

and then they improved it

because they had a problem.

It's different for LibreOffice,

because our users are very

far apart from the typical C++ hacker thesedays.

So there's a huge huge river to cross

and we need to bridge this,

and we're doing this like:

we started with just developers

and in early days

we had Italo [Vignoli] on board

from the start doing marketing but

in the beginning it was mostly just

getting something to build and that's it.

We had no real coordinated QA or something.

So then we built QA which got us

a little bit closer to the users

and so on. So we need to check these steps to

bridge this whole divide, and

get really good connections and look at

the whole pipeline - and with the weakest point

to get communication flowing, like

communication flowing and one direction

and the product essentially, and

the other one.

Which is in total, like I said

I don't care too much about the product

because the product is just one thing

in the whole project which is

this whole pipeline moving things in

both directions.

Essentially this means that we are a lot closer together.

I mean there are marketing for Linux

but they are not marketing Linux per se.

They're marketing like a company

doing a distribution and things like that. So

this is very separated, because I think in Linux

this is already a self-contained thing that

mostly works for itself.

At least there have been, and

there are quite a few still, distributions of Linux

that were very small, self-contained and

had almost no marketing.

And they just like -

You don't see much from them but they

existed all the time. So

It's very different for us

and maybe, also this is the other thing,

that our developers are not really power users of the product.

Not at all.

So you often come across the situation

where someone says

"Oh I've got this bug with this feature", and the

developer says he's working on this area of code,

and has never really realized this feature exists,

and what it should do,

and what does the use case is for -

so just because it's such a huge product.

So just because of the hugeness of the product,

we also need non developers

to actually tell developers what is the real use case

and what's what's being done with the project,

and with the product

outside of the hands of a developer

who might take his minutes of a meeting and

that's about it.

And the question there is

do you see it as a product or as a project?

And I think the companies that I know, part

of the ecosystem, they make you see that

this is a product. And they have a clear

customer or client relationship

with people there that are paying them

for level 3 support and stuff like that.

It's not exactly the same with us

as TDF being an NGO.

We want to make the world a better place,

to put it the most simple terms. You can

read the details and the statutes! But

in general, we are not there to just serve

one specific user.

We're there to serve, well

to make this thing better as a whole.

And this is not about an individual user.

So the question is:

Does it help the project as a whole?

And again it's like:

does it get people interested in their project?

Do we get more people, maybe, to contribute?

And this might very well be a

user experience improvement. Because, I mean

one of the easiest ways

to get people involved or interested

in a project is to like talk about

styles and the colors of buttons and stuff.

So you might use that, actually, to

generate interest and get someone involved

in the project. And then carry on

and see, once they're in there...

Someone who used to be a simple user,

like a customer, gets involved and

it becomes more than that,

and sees: OK this is the problem, but

in the discussion realizes that there are

conflicting goals. And how do we...

How can this be solved in a way that serves

all the interested parties.

Because in many cases it's not that

there is simply a bug to fix and the

work to do, but there are

conflicting goals and there are two ways

to resolve something. We have to decide

which one is actually the

road to take, and well...

The default action is actually "doers decide", so

if someone says "I'm doing this", then you have to

have real good reasons to say

"But I want this done because it's better". So

the default is always to go where

there's actually movement and solving a solution.

But sometimes you do end up with conflicts

that are harder, in that...

You have...

One example is "zombie" bugs that

always come back!

Typical is, for example, layout

in the text application, in Writer.

You have an rendering issue where

like a table is not rendered on the first page

but on the second, or has moved back, and

just to make an example:

Someone complains, "Oh

I've got this table on the next slide

not like in this other application". And

someone fixes that, and the table is then

as it is in the other application. And

then someone else comes along with

another document, and that used to be fine

until this fix was in,

which solved it for one document

but it broke it for another.

And then you they have two cases.

And this is not an artificial example,

but it's a little bit more complex in reality!

Often you have cases

where you can say, "OK,

we can do THIS document right

or THAT document."

Then you have to judge which is more common, and

which is the more generic case

and that's

one of the reasons why I have

high respect for our, QA team because

they all have to do decisions like that.

In the beginning when we started LibreOffice

everyone invested a lot of their free time.

And also the companies

that started with LibreOffice

invested or did a lot of front-up investment.

And they had lots of

strategic interest in the project

getting started.

And this changed a bit.

We are now having companies

in the ecosystem.

Many of them have very

direct goals towards customers, and to

serve problems for them.

And in a way,

because we're so successful, everyone

assumes that LibreOffice will just

carry on on its own.

And we're having hackfest events,

where we essentially

just get together and

solve problems on the product. In the

beginning there were so many problems - we

had no we had no issues solving

hard and urgent problems right there!

And since,

for example, we have a lot of TDF staff now,

the urgent problems are

taken care of

to a large part by

employees or contractors of TDF.

And we are left with

product issues for example.

It's still important to do these hackfests

and to get new people involved, and show how to

get started on this.

But the developers for example,

like I said, work for companies

that have their very own goals.

And just going there on their free time

leads to them being stuck, with

something burning down right now

in their company.

They're not able to like take care of the

foundation's issue, or the project issue

at that point in time. So the idea is to

maybe hire these people as consultants,

and have them exactly for this

time frame, so that they can spend

the whole time really for the project without

interruptions from their day business.

And because this is their day business then.

And work together with someone

from the community who wants to

learn about the project and

how to be a developer, and

essentially grow

maybe into a developer, or someone who

can contribute in a better way

to LibreOffice. And right now this is very

developer-centric, but the idea really is

to have this in a way that

you can really see and learn from this.

And maybe if you are not a developer, you can also

just watch what developers do

to understand what the actual work is,

and maybe see that

this is an opportunity. In comparison to

other products you never see how this is

being done, and here you can just

go there, be there and see how the

sausage machine really works in the inside!

And might make some weird decisions that

developers make sometimes seem more understandable.