Language Selection

English French German Italian Portuguese Spanish

A cure for unfair competition in open source

Filed under
OSS
Drupal

In many ways, open source has won. Most people know that open source provides better quality software, at a lower cost, without vendor lock-in. But despite open source being widely adopted and more than 30 years old, scaling and sustaining open source projects remain challenging.

Not a week goes by that I don’t get asked a question about open source sustainability. How do you get others to contribute? How do you get funding for open source work? But also, how do you protect against others monetizing your open source work without contributing back? And what do you think of MongoDB, Cockroach Labs, or Elastic changing their license away from open source?

This article (in five parts) talks about how we can make it easier to scale and sustain open source projects, open source companies, and open source ecosystems.

Read more

Part 2 From Dries Buytaert on Parasites That Hurt FOSS

  • How takers hurt makers in open source

    In part 1 of this article, I introduced the concept of open source Makers and Takers, and explained why it is important to find new ways to scale and sustain open source communities. Here in part 2, I’ll dive into why Takers hurt Makers, as well as how the “prisoner’s dilemma” affects the behavior of takers.

    To be financially successful, many Makers mix open source contributions with commercial offerings. Their commercial offerings usually take the form of proprietary or closed source IP, which may include a combination of premium features and hosted services that offer performance, scalability, availability, productivity, and security assurances. This is known as the open core business model. Some Makers offer professional services, including maintenance and support assurances.

    When Makers start to grow and demonstrate financial success, the open source project that they are associated with begins to attract Takers. Takers will usually enter the ecosystem with a commercial offering comparable to the Makers’ but without making a similar investment in open source contribution. Because Takers don’t contribute back meaningfully to the open source project that they take from, they can focus disproportionately on their own commercial growth.

Last part of the series in which Drupal's founder explains FOSS

  • 3 suggestions for stronger open source projects

    If, like most economic theorists, you believe that organizations act in their own self-interest, we should appeal to that self-interest and better explain the benefits of contributing to open source.

    Despite the fact that hundreds of articles have been written about the benefits of contributing to open source—highlighting speed of innovation, recruiting advantages, market credibility, and more—many organizations still miss these larger points.
    It’s important to keep sharing open source success stories. One thing that we have not done enough is appeal to organizations’ fairness principles.

    While a lot of economic theories correctly assume that most organizations are self-interested, I believe some organizations are also driven by fairness considerations.

    Despite the term Takers having a negative connotation, it does not assume malice. For many organizations, it is not apparent if an open source project needs help with maintenance, or how one’s actions, or inactions, might negatively affect an open source project.

    As mentioned, Acquia is a heavy user of Varnish Cache. But as Acquia’s chief technology officer, I don’t know if Varnish needs maintenance help, or how our lack of contribution negatively affects Makers in the Varnish community.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

More in Tux Machines

Today in Techrights

Android Leftovers

LibreOffice 6.4.5 finally for Slackware 14.2

The Document Foundation recently released version 7.0.0 of their Libre Office suite of applications. The packages for Slackware-current can be found in my repository. But the situation for Slackware 14.2 used to be different – I got stuck after LibreOffice 6.2 because the newer source releases (6.3 and onwards) require versions of system software that our stable Slackware 14.2 platform does not offer. From time to time during the last year, when there was time and the build box was not compiling packages, I messed around with the libreoffice.SlackBuild script in futile attempts to compile recent versions of LibreOffice on Slackware 14.2. I failed all the time. Until last week. After I had uploaded the new KDE Plasma5 packages to ‘ktown‘, I had an epiphany and decided to use a new approach. What I did was: question all the historic stuff in the SlackBuild script that got added whenever I needed to work around compilation failures; and accept that the compilation needs newer versions of software than Slackware 14.2 offers. The first statement meant that I disabled patches and variable declarations that messed with compiler and linker; and for the second statement I stuck to a single guideline: the end product, if I were able to compile a package successfully, has to run out of the box on Slackware 14.2 without the need to update any of the core Slackware packages. Read more

Web Browsers: New Tor RC, Firefox/Mozilla Trouble, and Web Browsers Need to Stop

  • New release candidate: 0.4.4.4-rc

    There's a new alpha release available for download. If you build Tor from source, you can download the source code for 0.4.4.4-rc from the download page. Packages should be available over the coming weeks, with a new alpha Tor Browser release likely in the coming weeks.

    Remember, this is a release candidate, not a a stable release: you should only run this if you'd like to find and report more bugs than usual.

  • Mozilla is dead

    If Mozilla wants to survive, the management will be fired with unearned compensation, the most important departments will be strengthened, products that nobody ordered will be discontinued and the organization will be limited to its core competence. Browser, email, security, adaptability and the fight for a free Internet. And they work with all their might to ensure that the products will become an integral part of everyday life and all operating systems.

    Three months. That’s all the time they have for a clear signal. After that, users have to make a decision. Unfortunately, it will probably only be something with chromium.

    Poor Internet.

  • Web browsers need to stop

    I call for an immediate and indefinite suspension of the addition of new developer-facing APIs to web browsers. Browser vendors need to start thinking about reducing scope and cutting features. WebUSB, WebBluetooth, WebXR, WebDRM WebMPAA WebBootlicking replacing User-Agent with Vendor-Agent cause let’s be honest with ourselves at this point “Encrypted Media Extensions” — this crap all needs to go. At some point you need to stop adding scope and start focusing on performance, efficiency, reliability, and security5 at the scope you already have.