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.