It’s now time for Part 3 of our “Building Studio in Public” series! In today’s post, we’ll explore how the Studio app connects with other open source projects, with a focus on its key relationship with WordPress Playground. We’ll also dive into the benefits and challenges of this symbiotic relationship, showing how both projects mutually benefit from improvements and bug fixes.

If you’re following the series, be sure to check out past posts:

As a reminder, Studio is our free and open source local WordPress development app.

How Studio connects to other open source projects

Studio relies on various open source projects, with the primary one being WordPress Playground which provides a local WordPress server, handling everything from running PHP code to serving static files and managing a database. This allows developers to test WordPress sites, plugins, and themes in a local, sandboxed environment.

WordPress Playground utilizes Emscripten to compile the PHP interpreter to WebAssembly, enabling PHP to run in the browser and other platforms—a significant leap for WordPress development.

By way of WordPress Playground, Studio also makes use of other open source tools like the SQLite integration plugin.

Studio itself is open source, which means the codebase is available for review, contribution, and forking by the community. This openness fosters collaboration, encourages innovation, and enables rapid identification and resolution of issues.

Because of the open source nature of Studio and the projects it uses like WordPress Playground, we are not blocked by missing or undesired behavior of our libraries but can instead help uncover issues or opportunities for enhancement in these projects and contribute the necessary fixes and improvements. Instead of building workarounds, we can directly enhance Studio’s performance and capabilities by submitting fixes to the actual problems. 

This creates a virtuous cycle of improvement, showcasing how open source collaboration drives innovation and helps solve complex challenges.

Challenges we discovered working with WordPress Playground

WordPress Playground is powerful, but since it makes WordPress run in an unusual environment–the browser instead of a server–some things work differently than developers expect. While using it to power Studio allows us to achieve all the good things, like a fast setup, we also had to overcome some challenges:

1. Cross-platform compatibility: Ensuring that WordPress Playground runs smoothly on different operating systems (Windows, macOS, Linux) and across browsers requires extensive testing and fine-tuning.
2. Performance: Managing multiple resources (PHP interpreter, WordPress site, database, and file system) while running multiple sites in Studio can strain performance. You can learn more about how we maintain high performance in Studio here.

3. Plugin and theme compatibility: Although WordPress Playground creates a full environment for running sites, some plugins and themes rely on extensions that are not included in WordPress Playground by default. Adjustments are often necessary to accommodate support for the different plugins and themes.
4. Database handling: WordPress Playground uses an SQLite database instead of MySQL, fundamentally altering how WordPress operates. This shift requires adaptations for database queries and compatibility with plugins and themes.

These complexities sometimes lead to incompatibilities, bugs, or performance issues. However, we believe the benefits of WordPress Playground far outweigh the challenges, and we are committed to addressing them by contributing to the Playground project. Thus not only Studio works better, but everyone who uses Playground has a better experience.

In turn, Studio also benefits from contributions from other Playground users.

Our recent contributions to WordPress Playground and other open source projects

As part of our contributions to the Studio app, we recently focused on improving the compatibility of plugins, themes, and workflows in sites. The following are some of the fixes we made that contributed to the projects.

MySQL database compatibility

With a pull request, we helped improve the compatibility of sites connecting to MySQL databases, making Studio more flexible in handling various site configurations and expanding its capability to support more diverse WordPress setups.

Symlink support

We submitted two contributions (PR 1, PR 2) to add crucial support for handling symlinks in sites, greatly improving file system compatibility and flexibility. This enhancement significantly improves the development workflow, enabling developers to maintain cleaner project structures and more efficiently manage their themes and plugins across multiple projects. It also facilitates easier version control and collaboration by allowing links to external repositories without duplicating files.

Windows media upload fix

A fix resolved critical issues with uploading media on sites when using the Windows version of the Studio app, ensuring a smoother experience for Windows users. This contribution addressed a significant functionality gap, ensuring that Studio provides a consistent and reliable media management experience across all supported operating systems.

WordPress core and extension upgrades

Another contribution fixed the process of upgrading versions of WordPress, plugins, and themes. This improvement streamlined the update process within Studio, allowing developers to maintain their WordPress installations and associated extensions easily.

WooCommerce compatibility

This pull request significantly improved compatibility with the WooCommerce plugin, expanding Studio’s utility for e-commerce development. This contribution addressed specific database queries and operations that were incompatible with the SQLite database used in sites created with Studio. The SQLite integration plugin involves different complexities to allow seamless integration with the WordPress ecosystem, and this contribution addresses one of the main pain points of using WooCommerce in local WordPress environments.

cURL extension compatibility

We contributed the ability to enable the cURL extension on PHP used with Playground which turned out to be a requirement by a significant number of plugins for external API calls or remote data fetching. This broadens the range of plugins that can be used effectively within Studio and WordPress Playground.

File creation compatibility

A fix improved compatibility with plugins that create files using umask to set file permissions, enhancing the file system operations. This was crucial for plugins that generate caches, create custom CSS or JavaScript files, or manage uploads in non-standard ways. By resolving these file operation issues, we ensured that a broader range of plugins could function correctly within Studio, providing a more accurate representation of how sites would behave in a production environment.

All the above examples demonstrate how collaborative contributions help Studio evolve, making it more compatible with the vast array of plugins and themes in the WordPress ecosystem.

How to contribute

If this post has inspired you to contribute to open source projects (we’re big fans), here’s how you can get involved with some of our favorite open source projects:

Together we can build incredible tools for the community! 🙂

Ready to build?

If this information has piqued your interest, or if you’re developing WordPress sites, start leveraging the power of Studio today. It’s free, it’s open source, and it seamlessly integrates into your development workflow.

After downloading Studio, connect it to your WordPress.com account (free or paid) to unlock features like Demo Sites.

Updated WordPress developer Automattic on Wednesday published details of its efforts to pressure rival WP Engine to sign a trademark license agreement costing millions of dollars.

As well as contributing to and steering the direction of the open source web publishing system WordPress – used by millions and millions of websites – Automattic also provides commercial hosting of WordPress-based blogs. WP Engine, meanwhile, also sells WordPress hosting, and the pair have been beefing.

Automattic, annoyed at WP Engine using “WP Engine” as a name to do boffo business, likened WP Engine to cancer, and wanted the biz to pay millions of dollars in trademark usage fees to, in Automattic’s mind, support the development of WordPress. WP Engine says it shouldn’t have to cough up.

Now, pulling back the curtain further on that drama, Automattic has made public a term sheet, which appears to date back to February 2023, that it was trying to get WP Engine to sign that would make the latter pay “a royalty fee” to fund work on the open source WordPress software that both organizations rely on.

The proposed seven-year Trademark License Agreement [PDF] calls for WP Engine to pay eight percent of its gross revenue on a monthly basis to Automattic, or in the form of WordPress software development time contributed by salaried employees, or a combination of the two options.

It also includes a ban on forking software from Automattic, its WooCommerce subsidiary, or its affiliate’s software (eg, plugins and extensions) “in a manner that disrupts any partnership between Automattic and its commercial partners.”

As an example, the term sheet specifically forbids “changing attribution codes included in any software by Automattic.” Attribution codes are metadata in online transactions that let e-commerce merchants understand the effectiveness of marketing campaigns on product orders. Automattic did not provide any details about whether WP Engine is currently doing this.

WordPress software is subject to the GPL-v2 license. WooCommerce is also “fully open source.”

Both outfits last week issued dueling cease and desist letters, with Automattic accusing [PDF] WP Engine was violating its trademarks, while WP Engine claiming [PDF] Automattic CEO Matthew Mullenweg was demanding payment and making false, disparaging statements that interfered with its business.

Mullenweg contends that WP Engine, backed by venture capital firm Silver Lake, is profiting from WordPress software without giving back to the project. And based on those claims, Automattic’s WordPress.org last week cut off WP Engine’s access to its servers, thereby preventing WP Engine customers with WordPress websites from updating their themes and extensions.

On Friday, in the wake of community criticism, Mullenweg – through WordPress.org – announced a three-day reprieve for WP Engine until October 1, 2024, so his rival could stand up its own software update service.

WP Engine did not immediately respond to a request for comment, though the company’s status page indicates they’ve deployed an alternative update server.

What complicates the debate is that Matthew Mullenweg, CEO of Automattic and co-creator of WordPress, is also a director of the non-profit WordPress Foundation, which chiefly oversees the open source project.

Mullenweg also owns WordPress.org personally, which is not the same as the WordPress Foundation. The fact that the term sheet says WordPress.org would direct the work of WP Engine employees if the time-donation payment option were chosen makes it unclear who or what entity would be the actual beneficiary of said work.

And his dual role has led critics to argue that Mullenweg should step down from the foundation due to concerns about conflict of interest. It has also led a petition on the website unprotected.org asking the America’s consumer watchdog the FTC to investigate Automattic’s business practices.

“It has become common for individuals to establish non-profits to develop open-source software (OSS) using unpaid labor and public contributions,” the petition states. “However, they may then leverage their for-profit entity to monopolize and privatize the gains, creating a market imbalance.”

The FTC declined to comment.

In an email, Bruce Perens, one of the founders of the open source movement who drafted the original Open Source Definition, told The Register, “Let’s be clear about WP Engine: It’s built on WordPress. There would be no business without WordPress. And it’s a large business with big revenue, operated as if it’s funded by private equity.

WP Engine … has to increase returns to the investors. What do they do? Cut any voluntary expense, which includes returning any value to the creators of WordPress

“Private equity always demands big returns, regardless of the harm they do to the business. One of my customers has been completely destroyed by them – they are still operating but on such thin resources that they can’t dedicate the time of one engineer to work with me on an open source compliance review, even if I do it for free.

“So, WP Engine is in that situation, and has to increase returns to the investors. What do they do? Cut any voluntary expense, which includes returning any value to the creators of WordPress. I’m told that WordPress asked for eight percent of revenue, which sounds fair to me considering that it’s the basis of WP Engine’s business.

“But because it’s an open source project, WordPress can ask but can’t demand that money, so they have to turn to hostile enforcement of their trademark and denying access to their updates.”

Perens said the situation exemplifies how open source is broken, with some 60 percent of developers being unfunded.

“As you know, I’ve been working on the Post-Open project, which would make it possible for the developer to demand revenue not only from companies like WP Engine but from their deep-pocketed users,” he said.

“As more problems like the WordPress dispute come up, I think people will understand that being able to demand a fair return on their work is essential to continuing the partnership between developers and users fairly, without this sort of dispute.”

The Register asked Automattic to elaborate on its concerns about attribution codes, whether WordPress.org has resumed blocking WP Engine, whether Automattic has made a monetary demand to any other WordPress hosting firm, and whether Mullenweg’s dual roles as CEO of Automattic and director of the WordPress Foundation represent a conflict of interest.

We’ll update this story if we hear back. ®

Updated to add at 0145 UTC, October 3

On Wednesday, WP Engine filed a federal lawsuit [PDF] against Mullenweg and Automattic.

In a statement to The Register, a WP Engine spokesperson summarized the suit’s allegations, thus:

For years, my friend Mia sold personalized T-shirts at local markets and online marketplaces, but she always dreamed of reaching a wider audience. Having her own website. Her e-shop.

(more…)