Language Selection

English French German Italian Portuguese Spanish

“To whom much has been given, much is expected in return” – Free Software economics

Filed under
LibO
OSS
OOo

When it comes to Free Software projects, there’s a profound, deep misunderstanding about who does what and how it’s being done. Using the now overused quote, developers write a code “because they have an itch to scratch”, means that there can be twenty different motivations to contribute to Free Software. No one needs to explain or justify his or her contribution. In the real world, one of the most common motivation is money, be it in the form of a salary, a fee, or a transaction involving the developers to fix whatever bug or develop a new feature. Most of the FOSS projects I know -excluding Firefox- do not pay developers directly for fixing bugs except in very specific circumstances and by definition not on a regular basis. The LibreOffice project is no different. The Document Foundation serves the LibreOffice project by financing its infrastructure, protecting its assets and improving LibreOffice in almost every way except paying for development on a regular basis. What this means, in other terms, is that the Document Foundation does not provide support; nor does it provide service to customers. In this sense, it is not a software vendor like Microsoft or Adobe. This is also one of the reasons why there is no “LTS” version of LibreOffice; because the Document Foundation will not provide a more or less mythical “bug-free version” of LibreOffice without ensuring the developers get paid for this. The healthiest way to do this is to grow an ecosystem of developers and service providers who are certified by the Document Foundation and are able to provide professionals with support, development, training and assistance.

Read more

More in Tux Machines

Red Hat Announces General Availability of Red Hat Enterprise Linux 5.11

Red Hat, Inc. RHT, +0.07% the world's leading provider of open source solutions, today announced the availability of Red Hat Enterprise Linux 5.11, the final minor release of the mature Red Hat Enterprise Linux 5 Platform. Red Hat Enterprise Linux 5.11 reiterates Red Hat’s commitment to a 10-year product lifecycle for all major Red Hat Enterprise Linux releases and offers a a secure, stable, and reliable platform for critical enterprise applications. Read more

New Code Starts Lining Up For X.Org Server 1.17

X.Org Server 1.17 is planned for release at the start of 2015 and thus puts the closing of the merge window in the middle of October. While some xorg-server 1.17 code has already landed, more is on the way. X.Org Server 1.17 will continue with refining the in-server GLAMOR code that was merged with 1.16 for 2D acceleration in a generic manner over OpenGL. X.Org Server 1.17 is also looking to integrate the universal KMS mode-setting DDX driver. Keith Packard on Monday also shared several other code branches he's looking at as material for the 1.17 release. Read more

More Intel DRM Changes Queued For Linux 3.18, Including Old i830M Fixes

With the drm-next merge window for Linux 3.18 closing, Intel's open-source developers have submitted another round of changes for ultimately landing with the Linux 3.18 kernel. Intel has already sent in multiple pull requests of new DRM graphics driver code to push into drm-next for the Linux 3.18 merge window. Among the changes include various Cherryview improvements for the forthcoming low-power Atom SoC, and code clean-ups and continued Broadwell tweaks. Another Git pull request landed in drm-next over the night. Read more

Speeding up the Debian installer using eatmydata and dpkg-divert

The Debian installer could be a lot quicker. When we install more than 2000 packages in Skolelinux / Debian Edu using tasksel in the installer, unpacking the binary packages take forever. A part of the slow I/O issue was discussed in bug #613428 about too much file system sync-ing done by dpkg, which is the package responsible for unpacking the binary packages. Other parts (like code executed by postinst scripts) might also sync to disk during installation. All this sync-ing to disk do not really make sense to me. If the machine crash half-way through, I start over, I do not try to salvage the half installed system. So the failure sync-ing is supposed to protect against, hardware or system crash, is not really relevant while the installer is running. Read more