openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Xen <>
Subject Re: Differentiate or Die
Date Fri, 16 Sep 2016 11:08:48 GMT
Jim Jagielski schreef op 09-09-2016 20:11:
> One of the great things about FOSS is the tight connection
> between users and developers. After all, most developers are
> users that have an itch to scratch.
> If there are things that the user community wants, then
> chances are good that developers will be jazzed about working
> on them, or, at least, the pool of potential developers
> might be increased.

This is hardly ever the case.

The whole point of developing is that users who are not developers, can 
also use it.

There is no great project that can come about by mere itch-scratching. 
You cannot take a 100 developers that are not connected and have them 
agree on a product that needs to surface.

What I mean is that this might work for small deviations of an already 
existing project, but I venture that most successful (smaller) projects 
are started by individuals that may be scratching their own itch, but 
they are also visionary about it and are doing something they really 

A bigger entity like OpenOffice needs vision that is shared by multiple 
people (or the group as a whole) and cannot depend on random or spurious 
individuals who seek about to change something. That's like individually 
trying to change the leaves of a tree, but only a small part of them. 
You can never change the tree that way.

Most of the stuff that has been suggested of what I've seen is only 
small, meagre changes, if I can put it that way. Changes that do not 
really require vision at all, at least not something bigger than what 
there already is.

If the user wants something but cannot develop it, and if the developer 
wants something, and can, we have a problem, because users (in general) 
and developers are not the same kind of people.

The general request in general of users in FOSS to endlessly file 
unwanted bug reports is one example. They are not treated as users, but 
as developers, and this doesn't work. People become disheartened over 
such onslaught of bugs and the constant requirement to file them.

A developer needs to be responsible, and needs to responsibly listen to 
the users. That's the only way it can work. You need to be a service 

For me, rare is the occasion that a FOSS developer will say: right, you 
are right, I am going to implement that thing for you.

It happens. But not that often.

Mostly they want your free time, and not do anything themlves, and then 
have you develop their feature that they might want, but they will only 
say so after the fact whether they actually do. Lazy bums, I call them 

Free labour and you can turn it down as much as you like ;-).

Recently for me the AutoFS developer was interested in a feature or 
discussion, and the libblkid developer instantly agreed to develop 
something, as it was apparently needed to fix other things.

Both are kernel projects, so maybe there is a hint ;-).

The only thing you can do, potentially, ever, is to envision a future 
and then agree on it. You need vision to start with. You cannot 
haphazardly have individuals make minor changes or even structural 
changes that don't change the base project or where it was going. There 
was once a company that had vision and a product came about.

And now, if you don't agree to have the same level of vision, you won't 
go anywhere. You will stay stuck where you are right now.

> But open source, and open source projects, should not be
> run in a normal, corporate s/w development mode, where some
> "entity" decides what features are needed, etc... We should
> be in touch with what our users, and our potential users, want.

You are right, and pardon me if I misinterpreted your message a little 
bit (you were top-posting).

But the corporate mode ideally also just listens to users.

And then creates a product that they know will sell.

And this is true of everyting. Just because you are FOSS and there is no 
money involved doesn't mean you should create unsellable products.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message