Community driven?

[RGB]

Since 2005, one of the most voted issues, support PS-OpenType/OTF/(SFNT with CFF) fonts for PDF export and printing (more than 190 votes) passed with few to none comments from the OOo staff.
This situation went on up to when the RedHat people said in this message that they will move to otf fonts and avoid to deliver ttf duplicates of those fonts "just to work around OpenOffice.org bugs" (sic)
That not so polite message was sent on July 24th, 10:31 AM, the same day, only three hour later the target milestone for issue 43029 was set to OOo 3.2 ("maybe even 3.1").
That makes me think on the community role inside the OOo project... and feel quite disappointed.

[acknak]

Interesting chain of events. Thanks for bringing it up. If it's any consolation, I know how you feel.

But even though Sun could do a better job of working with the community, they're probably about as "community driven" as any open-source project. In the end, the people who write the code drive the project: they decide what's most important, and what direction the project takes, and "input from the community" is only one small factor in those decisions.

While Linux is something of a poster child for open source, it's really not typical. Most projects have very few people contributing code and thus all the power is in the hands of the few who do. OOo is no different in that respect.

Even in this case, I think what made more of a difference in getting this feature moving was the availability of code from another project. I suspect that if the code wasn't in the pot, there would have been no change. implementing support for a new font format has to be a tough job at best, and it will be even slower if the developer is not familiar with the font technology.

It's still way better than proprietary software, where you never get to have any influence or interaction with the developers, and discussions like the ones you reference happen behind closed doors.

[RGB]

Thanks, acknak
I think that the problem here is not only related with "hard heads" (every human being is able to break stones with his/her head under certain circumstances) but mainly on how the relation with volunteers/contributors/critics is handled.
Another example is how the solver component in Calc was managed:
http://kohei.us/2007/10/02/history-of-calc-solver/
Sun re-write from scratch the whole thing to avoid the introduction of code with a copyright not owned by them!
In my experience, even if with hard heads, open source developers are quite open minded and responsive. Maybe they don't agree with you, and in that case they will be the "winners", but you can always talk with them (there are exception, I know, but the dialogue tends to be possible)
I remember suggesting two "features" on the mailing list of an open-source project. One of those features was immediately implemented. About the second suggestion the developer told to me "it is possible, but needs a lot of work".
I was the looser, but at least I understood why.

[ccornell]

to avoid the introduction of code with a copyright not owned by them

This is actually a LOT more important than most people realize. Lawyers love it when a project - especially one with as high of a profile as OOo - has a mixed bag of copyrights in the source. This gives them all sort of place to play at nitpicking and finding legal loopholes for causing legal trouble.

If Sun does not have joint copyright on ALL the source that goes into OOo (which is given via the SCA that all developers must sign and fax in to Sun) then the source cannot be included. Why? The SCA legally protects the source code as a complete unit. This is no different than the requirements for other projects like Mono or RHDS, and even the FSF - all of which insist on a joint copyright assignment for code contributions. If there is a mishmash of copyright, then Sun cannot protect OOo from the legal vultures.

In the case you quoted, the author opted not to sign an SCA... and Sun could not legally accept his code contribution. That's it. Signing an SCA is a hard requirement for ALL upstream code contributions. If a developer refuses to sign an SCA, then no matter how important, or how good the code he or she writes is, it cannot be used as part of the core code.

[RGB]

Thanks, ccornell!
Now I understand a few more things...
I googled for SCA and seems not so bad: even if you grant them the right to do whatever they want with the code, they accept to deliver all derivatives with a FSF or OSI licence:

"... Any contribution we make available under any license will also be made available under a suitable FSF (Free Software Foundation) or OSI (Open Source Initiative) approved license."

http://www.openoffice.org/licenses/sca.pdf
The first complain remains, though