The Unsaid Document Foundation

The Document FoundationThe will be Document Foundation is out from a month, and it is now time to share some thoughts about past, present and future actions taken around subjects like copyright, the legal and governance structure and the code development process.

How did we know about the TDF?

The TDF announce, as the community itself  happened to know later, is the result of about 10 months of work, a period of time during which the self-selected group of the OpenOffice.org members – now known as the “TDF Steering Committee” – took some important decisions.

TDF Fast Start, not without complications.

The TDF Steering Committee (SC) invited Oracle to join, asking them to give away the OpenOffice.org mark. Inviting a corporation to join a will-be foundation without a document describing a draft legal and governance structure sounds a bit naïve, though.

Why the SC gave such a short notice is unclear. OpenOffice.org community members have been treated like second citizens, while TDF first-hour supporters have been giving all the time to provide feedback and quotes.

As a long time member of the OpenOffice.org community and as a founding member of one the oldiest OpenOffice.org associations ( PLIO), I found odd myself being noticed only two days in advance. Knowing about the decision to go without Oracle, some of us would have asked time for a second thought, maybe coming up with better alternatives.

Community members didn’t get a chance to give any advice, though.

Code contributions: are they all good?

How to contribute is well explained, but unfortunately some not-so-innocent requests for contributions are not without risks.

In fact fixing German mispelling in internal APIs could bring to future problems, since additional upstream modifications will keep using the old APIs names. Other decisions are considered even riskier by expert developers, so that “easy hacks” may easily turn into complicated issues to cope with in the future.

“Easy hacks” let new contributors feel part of something that looks thing, but coding it is good only if it doesn’t increment project’s “technical debt“.

Including dictionaries in language packs is not the default, but OpenOffice.org users were used to them.

Also QA processes should be relevant to the LibreOffice project.

Discussing and elaborating development guidelines should be a priority, probably more important than enabling people to make cosmetic changes.

Contributor agreements: are they bad?

SC members have been promoting the idea that copyright assignment is bad from the very first day, while eminent members of our community asked to reconsider this position. While individuals may prefer to avoid the burden of copyright agreements, corporations and companies tend to like them more.

Looking for possible solutions to balance different interests in play should be a priority. Take Joomla! (draft) contributor agreement, or the OpenNMS approach – both derived from Sun Contributor Agreement -  are both some of the many available sources which would worth to be investigated further.

Viable open source projects must be sustainable, and LibreOffice is no exception to the rule. OpenOffice.org has always been a single vendor sponsored open source community, and until now it missed the opportunity to become a corporate dominated development community. Novell+Red Hat developers’ involvment with LibreOffice is a confirmation of such possibility.

Having on board corporations should be a priority, and to get there the way to go is truly open process (à la GPLv3) – to discuss about all above mentioned issues.

Related Posts