As a WordPress veteran, I’ve observed the fluctuations in the ecosystem for many years now. I’ve also written about my thoughts on the current state of things at various points in the past, but today I want to focus on that again with an eye on the future. I’m going to say things the way I see them and the way I think they are in this article; feel free to disagree in the comments section if you think I’ve got anything wrong.

First, a Bit of History

I’m going to start with some historical context as I feel that it’s very important when thinking about the present state and future possibilities.

Over the past twenty years, we’ve seen a significant shift in the way people use and perceive the internet. In the early days, the avenues of the web were synonymous with freedom. For the first time ever, we could make our voice heard by the world wherever and whoever we were. The creation of tools like WordPress was essential in allowing users to publish their content. Users didn’t mind taking some time to understand the technical part of things, such as downloading the WordPress software, installing it on a server, setting up a domain etc.

Nowadays, the internet looks quite different. Users have gravitated towards centralized platforms that provide an easy-to-use interface for creation, and an audience too. They’ve been seduced by the slick interfaces and addictive nature of many social networks and platforms, and have long-forgotten ideals about decentralization and open-source software.

This is the present that WordPress finds itself in today, with competitors like Wix, Squarespace, Shopify and Webflow, all of which are centralized platforms for creation. WordPress has the biggest market share, helped by its tremendous growth over the past two decades and its first-mover advantage (all other platforms launched many years after WordPress). But the challenge going forward is to keep its position while faced with these formidable competitors.

The WordPress Ecosystem

Now, I want to spend some time describing all the components of the WordPress ecosystem.

Matt Mullenweg – The Founder

Matt Mullenweg is the co-founder of WordPress, together with Mike Little. Matt has been the leader and figurehead of WordPress since its founding in 2003, and has become a billionaire through Automattic, the company he founded soon after he launched WordPress.

Matt makes his investments in other companies through Audrey Capital. Through the success of Automattic, he’s been able to go on and invest in many other interesting companies, a list of which is on the Audrey Capital website.

Automattic – Matt’s Company

Automattic is a company founded and run by Matt Mullenweg, who is also the co-founder of WordPress. It is still private but has done several funding rounds and is currently valued at around $8 billion. Yes, you read that right.

Automattic now owns various web products, such as Tumblr and Day One, but the company made its money through WordPress.com.

WordPress.com – The Cash Cow

The first point of confusion for any prospective WordPress user is the differentiation between WordPress.com and WordPress.org.

WordPress.org is the site that hosts the open source software known as WordPress.

WordPress.com is the hosted version of WordPress and is run by Automattic, a company founded by Matt Mullenweg, also a co-founder of WordPress.

WordPress.com has become very similar to the other centralized systems that I mentioned previously (Squarespace et al) and is obviously a big money maker for Automattic.

Here we start seeing how things are twisted to the benefit of the commercial side of WordPress (making money for Automattic). Note how the screenshot above raves about the “millions of people that call WordPress.com home” and makes no mention of the fact that the majority of those are using WordPress the open-source software not WordPress.com, the hosted version.

WordPress.org – The Open Source Software

WordPress.org is where you can download the open-source WordPress software. It’s also the de-facto home of the “WordPress community”, and you will find the forums, plugin and theme download pages, etc there.

WordPress was launched at a time when most content management systems were closed source. The fact that WordPress was launched as an open source project was the single most important driver to its success. By being free, it quickly gained adoption among both users and developers.

WordPress Plugin (& Theme) Developers

WordPress plugin and theme developers are what made WordPress grow into the behemoth it is today. They built upon and extended the functionality of WordPress in a bazillion ways, turning WordPress into by far the most flexible publishing software on the planet.

The only real alternative to WordPress if flexibility and extensibility is your main goal, is to build your website from scratch using custom code or a coding framework as a base. If you’re not a developer or don’t have the means to hire one (or an agency) then WordPress is your only feasible choice. All you need to do is pay a few hundred dollars to acquire the set of plugins that you need to concoct whatever flavor of website you desire.

WordPress Users

By WordPress Users, I mean individuals or companies that are using WordPress to power their websites. This group numbers in the millions.

WordPress Agencies

These are companies that build web solutions for their customers using WordPress. They are typically not that interested in WordPress as a project beyond it being a means to an end. Some are more invested in WordPress and even create and sell a few plugins of their own.

The Current State of WordPress

In 2022, I’ve seen WordPress reach a peak of negativity among plugin developers, mostly due to the fact that they have always been underappreciated by WordPress leadership. Towards the end of the year, the WordPress powers that be suddenly removed the install growth charts from the .org repository without any real explanation. When questioned about it, Matt, Otto (one of the lead devs) and JJJ (another developer close to the core team) offered conflicting reasons, leading to even more speculation and outrage. Plugin developers were adamant about wanting the feature back as it is essential to them in monitoring how their plugin is performing in the market, but there was no real sense of caring from Matt and the core team.

For many years now, those who have been working in the space for a long time have felt that WordPress is an ecosystem that is run by one man, Matt, acting as the dictator. He has been sometimes referred to as the “benevolent dictator”, but his sense of judgment and benevolence is being questioned more and more as time goes by. The close circle of people high up in the WordPress hierarchy has also fallen out of favor, again mostly due to their dismissive and entitled attitude. There is certainly the sense that WordPress is far from an open system when it comes to the major decisions taken.

Web developers in general tend to hate WordPress due to their perception of it being bloated and badly coded. While there is a strong element of truth there, the codebase has changed a lot over the years, moving from being almost 100% PHP-based to being more of a JS-based system. The attitude, whether justified or not, still prevails, and most serious developers prefer using a cleaner framework like Laravel for their projects. This makes it harder for WordPress companies to hire competent developers.

WordPress agencies are having a good time, since the popularity of WordPress with end users doesn’t seem to be waning, in fact it is reportedly still growing year over year, although there are some debates around that statement as well.

WordPress as a system has definitely enjoyed much better years as regards to reputation, but it is undoubtedly the case that there are still millions of sites running it and many new sites popping up every day, so agencies have no worries about finding new clients.

Enterprise-focused agencies are a niche on their own, dealing with their own trials, as Magne from Dekode can attest. However, it is also true that their business is doing well and also growing, so along with agencies doing work for mom-and-pop shops and small businesses, this is a good niche to be in.

What about the end users though? These are by and large the biggest part of the WordPress ecosystem. For end users, there still isn’t much of an alternative to WordPress if they are the DIY types and have a very specific type of site they want to build. The lack of alternatives stems from the fact that WordPress is the only system out there to have so many plugins. Sure, end users can choose Squarespace, Wix, and the rest of the hosted systems out there. They offer a slicker experience and better UI, but they will always lack in features and flexibility compared to WordPress.

On the other hand, end users are also frustrated by moves that have been imposed on them by Matt and his cronies over the years. Gutenberg is a glaring example, and a look at the reviews will tell you all you need to know.

Again this is an example of Matt being an absolute dictator and shoving his wishes down everyone’s throat. Here’s one of the recent reviews at the time of writing this article:

No one step set WordPress back as far as this one plugin and set of features has. Now with the infiltration of Gutenberg modules into the official WP code contributions represents a devolution and corruption of WordPress principles, a rotting of it to the core. As an avid long term fan and developer of WordPress for 12+ years, nothing comes close to Gutenberg in how much it’s damaged the functioning and operation of WordPress, adding needless complexities to the user and developer experience, adding no tangible upsides, and breaking the long upheld principle of backwards compatibility. This plugin and mostly its integration into the WP core is a disaster and has damaged WordPress as a whole.

The Future

I know many WordPress plugin and theme business owners who have totally given up on WordPress and exited the space altogether. Typically, they have sold their businesses to a bigger plugin company like Awesome Motive, or to hosting companies that are trying to emulate the hosted environment provided by WordPress.com.

Others are still trying their best to survive within the changing WordPress ecosystem, although the way I see it, things are not looking great going forward.

I’ll end with a question – What’s next?

For users who have become frustrated by the complexity of WordPress and the janky experience, will they move to a service like Squarespace, Substack, Wix or Webflow? Will they wake up to the abusive pricing strategies by some WordPress plugin sellers and the overall horrible experience of having to pay subscription fees to several plugin suppliers to keep their website running year after year?

For the plugin developers who are seeing their chances of success within the WordPress space trending towards zero, what are the alternatives? Shopify is one platform that is becoming more and more attractive, as it opens up the possibilities for developers extending the core functionality and building significant businesses around that model.

I welcome your comments and discussion.

My journey with WordPress goes way back, in 2006, to be exact. Over the years I’ve been first and foremost a user (running various blogs on WP), but I’ve also developed on the platform and run various plugin businesses too. For a while, I also ran an agency where I advocated hard for the benefits of open-source systems and WordPress specifically. This was at a time when the vast majority of websites were either custom coded or run on proprietary closed-source CMS systems, even before the growth of social media.

Back then WordPress really was the solution to democratizing publishing (its slogan) but over the past circa 20 years of its existence, things have changed a lot.

I’ve already highlighted my concerns with the trajectory it has been taking over the past few years, as well as raising doubts whether the slew of acquisitions are a good thing for the space.

Today I want to bring attention to a particular Trac ticket about a change in the .org codebase that took everyone by surprise.

The most commonly cited superpower of WordPress is its community, but there are serious reasons to think that this community is very fractured.

In my view, WordPress community is very generic and we need to understand what we mean when we speak about that. Here’s my take on what makes up the WP community:

• WordPress leadership
• plugin and theme developers that create free and premium products for WP
• service providers (WP-specific or not) that create solutions using WP as part of their toolset
• millions of end users who have no interest beyond using WP to power their site/s

The unique selling point of WordPress really is its flexibility. That flexibility comes from the fact that thousands of developers have built plugins and themes to cater to every possible need a website builder can have.

WordPress leadership, with founder Matt Mullenweg firmly at the helm and in control of things, likes to preach about community as one whole part, but it has become increasingly obvious that this is a fallacy.

Plugin and theme developers have felt unappreciated for many years, with many incidents over WordPress’ history fueling this feeling.

The removal of plugin growth stats is the latest such incident, and the public outcry from developers and users (and the responses from WordPress leadership) has really illustrated that things are severely broken at the top and we need to find a fix to avoid WordPress going into a long-term death spiral.

Here’s what went down.

On Friday 30th September 2022, the active install growth chart in the plugin repository was officially removed in a commit by Scott Reilly (coffee2code), a Tech Ninja at Audrey HC, LLC – an investment and research company run by Matt Mullenweg – WordPress co-founder and CEO of Automattic.

A very vague reason was given for the change, and in the ensuing hours and days many plugin developers were up in arms, and rightly so. A discussion ensued on WordPress trac, and there has been no resolution yet.

The ticket in question is #6511, go and have a look at the comments there before you come back to read the rest of this post.

I will add my two cents while looking at the bigger picture, because I believe that decisions like this really are very impactful in the long run.

In my humble opinion, failure to address the multitude of questions raised and going directly contrary to the wishes of the much-hailed “WordPress community” would confirm the following:

• WordPress is decentralized only in name; in practice being a centralized entity with power in the hands of a few who can decide whatever they want without having to give any justification for their decisions.
• There is no real incentive to help people build small businesses and earn a living through building plugins within the WordPress ecosystem. It is more desirable for acquisitions to happen more and more in order for the few big companies to obtain tighter and fuller control of the WordPress experience.
• Individual developers and small teams can no longer compete reasonably with the long-time big players and should be preparing for acquisition by said big players, and looking at moving into other systems that have more opportunity and a growing rather than shrinking pie.

It is understandable that there are many interests involved, and as in any other industry, money talks, but I think an honest discussion must be had on the future of WordPress.

Actions like the one raised in this ticket only fuel the idea that the big guys in this space no longer care about the people whose work (whether voluntary contributions to WP core or through running plugin/theme businesses) has enabled WordPress to be in the dominant position it is today.

Hopefully, this Trac ticket will serve as the beginning of a more open WordPress and a confirmation that plugin developers still matter and are very much appreciated in the community. That is truly my hope, as the opposite would paint a very bad future for those building businesses within the WordPress plugin ecosystem.

This is an article that reflects on the high number of acquisitions we’ve seen happen in the past few years (2018-2021) within the WordPress space. There are basically a handful of companies behind all the big acquisitions, so there is no doubt that the product space is becoming more centralized, and these big companies now wield enormous power.

This article is an adaptation from a comment I left on the article on the WP Mayor blog entitled Is There a Future for Small WordPress Businesses?. Check that out as well.

Having moved out of WordPress myself (aside from being a normal user, running my own blogs on it) a few years ago, I can empathize with Pippin’s reasons for selling. It’s never easy to let go of a successful business, even if there is good money to be made in selling it, and I’m really happy for him. I remember when Pippin was just starting out in WordPress, and he’s been a massive positive influence on WordPress over many years, putting a lot of energy into not only building his products but also educating thousands through his articles on development and later his insights on running a WordPress business. He deserved every bit of success while running his businesses and the handsome payout one gets when selling a company of this scale.

I happened to write some of my thoughts on WordPress last year, so check out that article for my opinions, which remain relevant today.

While the streak of acquisitions we’ve been seeing in the WordPress space are to be expected, they are also a sign that the space has changed a lot over the almost two decades since WordPress’ inception. Particularly the last 5-10 years have seen accelerated growth. Leaving aside any emotional reactions one might have, I think it’s important for everyone involved with WordPress to be clear on what WordPress is nowadays and where it stands in the grand scheme of things.

For that, we need to start with an understanding of the web’s history and where WordPress fits in. WordPress caught the wave of the transition between Web 1.0 and Web 2.0.

Web 1.0 refers to the read-only, static, version of the internet, where there were relatively few sources of information and there were high barriers to publishing your own content and obtaining visibility. The web in those days was just an extension of traditional one-way media like TV and radio.

Web 2.0 changed everything, and it became known as the read-write web, meaning that now we could interact with things on the web and more importantly publish our own content. That’s where WordPress and other similar open-source projects came in. WordPress eventually came to dominate the open-source blogging and CMS market.

At that point in time, it was very cool to have your own website or blog, and people were relishing the prospect of being able to share their thoughts online. The revolution was huge, and we saw a big shift in information decentralization, moving from the big-money media to independent small publishers and individual bloggers. Knowing HTML and CSS as well as your way around domains and hosting was a badge of honor, this stuff was very cool back then.

Over the years, however, many of the ideals that WordPress and Web 2.0 stood for were lost by the wayside. Users started preferring the ease-of-use of centralized platforms like Facebook and Instagram, and web blogging itself went into a decline. Of course, WordPress moved beyond being just a blogging platform, and the addition of e-commerce capabilities made it a very nice all-rounder tool. However, it also lost its way for a few years (more on that in my blog post) before the big push for Gutenberg in a last-ditch attempt to stay relevant in the publishing space when faced with formidably polished publishing interfaces by Squarespace, Wix and other hosted platforms. Only time will tell whether this move was even successful, as the Gutenberg plugin is literally one of the most hated plugins I’ve ever seen, with an overwhelming number of 1-star reviews in the WP repository as of today.

In any case, I think that WordPress is by no means the web darling it once was. The spate of acquisitions we see happening definitely increase centralization and move away from one of the core ideals that the early WordPress community espoused – that of decentralization and power to the small guy. Let’s remember that WordPress enabled thousands of young web enthusiasts from all over the world to make a living online and even start their own web businesses selling themes, plugins or related services. In those early WordPress years, it was one of the only avenues for geographically or financially disadvantaged people to get out of the rut they were in. It was definitely a lifesaver for me and I will forever be grateful to WordPress as an open-source project and the wonderful people I met in this community.

Now, the big deal is that we are moving towards Web 3.0. It’s already happening, driven mainly by the invention of Bitcoin, which paved the way to more expansive blockchains like Ethereum that enable smart contracts, decentralized finance and even governance structures through DAOs.

In many ways, I feel the same about crypto and Web 3.0 as I did when WordPress and the shift to Web 2.0 happened. The focus is again on the principles of decentralization, permissionless access, censorship resistance, as well as the new ideas of monetization and privacy.

For the technically-inclined, here’s a nice overview of Web 3.0 architecture. If you haven’t yet dabbled with Web 3.0 apps and want to know more, it’s a great read. It requires quite a paradigm shift and from a development standpoint, I feel that it’s a bigger leap to make compared to the one we made from Web 1.0 to Web 2.0 and I don’t think many people in WordPress are taking notice. WordPress is a tool built by and for millennials, but the new generations are used to different ways of publishing online. Within the WordPress space, meanwhile, we just obsess about the market share that magically grows year after year, but I don’t think that metric is that relevant anymore. WordPress is no longer a sexy and revolutionary tool as it once was, and that’s the more important fact to keep in mind.

Zooming back into the WordPress space, I do believe that these acquisitions are not great news for product owners in general. In this particular case, there are the specific hazards that Carl Hancock and Mark mention. This is one reason why I feel that the WordPress space has grown a lot but at the same time remained very immature in certain areas. The lack of an official plugin store (app store) has driven almost all premium plugin developers to use either EDD or Freemius. These two businesses in turn become excellent acquisition targets, and if you’re worried about the EDD acquisition, wait till Freemius gets acquired. The latter is a hosted service, so they hold all the important data and metrics on their end, and they’d be visible to any company that acquires them. The founders of Freemius are friends of mine, and again, they provided a sorely needed product in the WordPress space, and worked extremely hard at making it a success, but this big danger remains in the case of an eventual acquisition, which in my opinion is only a question of time.

Now, whether you like it or not, the future of WordPress involves many more acquisitions and centralization. With the big players getting bigger, it is undoubtedly harder for the traditional single web enthusiast or developer to develop a product that generates meaningful income. This is not something new, however, it’s already been the case for several years. There will be success stories, but they will be fewer and further between.

The first decision you need to take, in my opinion, is whether you want to be in the WordPress space at all. As I mentioned, personally I find Web 3.0 much closer to my ideals and so I’m devoting my time there. You could also be building apps for Shopify or other platforms, or building a SAAS. I don’t see any special advantages in building a WordPress business over some of the alternatives I mention. It used to feature a lower barrier of entry technically and financially speaking, but I don’t think this is the case anymore.

If you still love WordPress and feel strongly that you want to build products for WP, then perhaps it’s time to focus more on building businesses that are “built to sell”, as Pippin himself mentioned in his announcement post. You might want to think twice about building a competitor to EDD, Yoast SEO, AffiliateWP, and other major plugins, because it’s extremely hard for you to compete. Instead, you might want to focus on businesses that the big companies in the space will find interesting as an acquisition target. That will provide you with a potential big payday as well as a very probably job with a successful company should you accept that proposition.

I hope this was helpful, as always I like to be honest about things with no bad intentions. I am really curious to see what’s in store for WordPress in the years to come, and as a user I hope it remains a major player as a publishing tool, not only in the much-touted market share, but in actual functionality and ease-of-use. Who knows, maybe WordPress also somehow crosses over to Web 3.0 as well.

I love building stuff with my son, and one of our latest projects (admittedly more apt for me than for him as he’s too young to be building these kits), was the Lego buggy 42124. This is a great kit that is fun to build but it is let down by the fact that it is controlled using a smartphone. I don’t like using smartphone remote controls and I definitely don’t want my son looking at a screen at a young age, so I set out to figure out a way to use a hardware remote control.

Turns out it’s quite easy to do. I used Pybricks to add custom code to the Lego hub, then ordered a Lego remote to pair with the buggy.

The code I used can be found below. I set the left red button to “ludicrous mode” which enables the buggy to function at full speed. Otherwise, I set it to run at 50% speed since my son is too young to control it at max speed, especially indoors. This way we can both use it and have some fun while using the appropriate speeds.

Lego Buggy (42124)

from pybricks.pupdevices import Motor, Remote
from pybricks.parameters import Port, Direction, Stop, Button
from pybricks.hubs import TechnicHub
from pybricks.tools import wait

# Initialize the motors.
steer = Motor(Port.B)
front = Motor(Port.A, Direction.COUNTERCLOCKWISE)

# Connect to the remote.
remote = Remote()

# Initialize the hub.
hub = TechnicHub()

# Read the current settings
old_kp, old_ki, old_kd, _, _ = steer.control.pid()

# Set new values
steer.control.pid(kp=old_kp*4, kd=old_kd*0.4)

# Find the steering endpoint on the left and right.
# The middle is in between.
left_end = steer.run_until_stalled(-200, then=Stop.HOLD)
right_end = steer.run_until_stalled(200, then=Stop.HOLD)

# We are now at the right. Reset this angle to be half the difference.
# That puts zero in the middle.
steer.reset_angle((right_end - left_end)/2)
steer.run_target(speed=200, target_angle=0, wait=False)

# Set steering angle for the buggy
steer_angle = (((right_end - left_end)/2)-5)
print('steer angle:',steer_angle)

# Now we can start driving!
while True:
    # Check which buttons are pressed.
    pressed = remote.buttons.pressed()

    # Choose the steer angle based on the right controls.
    if Button.LEFT_PLUS in pressed:
        steer.run_target(1400, -steer_angle, Stop.HOLD, False)
    elif Button.LEFT_MINUS in pressed:
        steer.run_target(1400, steer_angle, Stop.HOLD, False)
    else:
        steer.track_target(0)

    # Top speed controls
    top_speed = 50
    if Button.LEFT in pressed:
        top_speed = 100         

    # Choose the drive speed based on the left controls.
    drive_speed = 0
    if Button.RIGHT_PLUS in pressed:
        drive_speed += top_speed
    if Button.RIGHT_MINUS in pressed:
        drive_speed -= top_speed
    if Button.RIGHT in pressed:
        print('Battery voltage:',(hub.battery.voltage())/1000,"V")
        wait(100)          

    # Apply the selected speed.
    front.dc(drive_speed)

    # Wait.
    wait(10)

Lego Top Gear Rally Car (42109)

I also bought the Lego Top Gear Rally Car (42109) and used similar code with a second remote I bought. Now we can race the cars against each other. I can adjust the speed of each through code to adapt it to our different abilities.

Here’s the code I used on this car. I added some things like changing the remote light buttons and naming the remote so that the car would connect to a specific remote out of the two I have, and thus avoid confusion. I also correspondingly changed the hub’s light color.

from pybricks.pupdevices import Motor, Remote
from pybricks.parameters import Port, Direction, Stop, Button, Color
from pybricks.hubs import TechnicHub
from pybricks.tools import wait

# Initialize the motors.
steer = Motor(Port.B)
front = Motor(Port.D, Direction.COUNTERCLOCKWISE)

# Connect to the remote and set the light on the remote
remote = Remote('topgear', timeout=None)
remote.light.on(Color.RED)

# Print the current name of the remote.
print(remote.name())

# Choose a new name.
remote.name('topgear')

# Initialize the hub.
hub = TechnicHub()
hub.light.on(Color.RED)

# Read the current settings
old_kp, old_ki, old_kd, _, _ = steer.control.pid()

# Set new values
steer.control.pid(kp=old_kp*4, kd=old_kd*0.4)

# Set initial top speed value
top_speed = 100

# Find the steering endpoint on the left and right.
# The middle is in between.
left_end = steer.run_until_stalled(-200, then=Stop.HOLD)
right_end = steer.run_until_stalled(200, then=Stop.HOLD)

# We are now at the right. Reset this angle to be half the difference.
# That puts zero in the middle.
steer.reset_angle((right_end - left_end)/2)
steer.run_target(speed=200, target_angle=0, wait=False)

# Set steering angle for the buggy
steer_angle = (((right_end - left_end)/2)-5)

# Now we can start driving!
while True:
    # Check which buttons are pressed.
    pressed = remote.buttons.pressed()

    # Choose the steer angle based on the right controls.
    if Button.LEFT_PLUS in pressed:
        steer.run_target(1400, -steer_angle, Stop.HOLD, False)
    elif Button.LEFT_MINUS in pressed:
        steer.run_target(1400, steer_angle, Stop.HOLD, False)
    else:
        steer.track_target(0)

    # Top speed controls
    if Button.LEFT in pressed:
        top_speed = 75
    if Button.RIGHT in pressed:
        top_speed = 100   
    if ((Button.RIGHT in pressed) and (Button.LEFT in pressed)):
        top_speed = 40 

    # Choose the drive speed based on the left controls.
    drive_speed = 0
    if Button.RIGHT_PLUS in pressed:
        drive_speed -= top_speed
    if Button.RIGHT_MINUS in pressed:
        drive_speed += top_speed

    # Print battery voltage    
    if Button.RIGHT in pressed:
        print('Battery voltage:',(hub.battery.voltage())/1000,"V")
        wait(100)           

    # Apply the selected speed.
    front.dc(drive_speed)

    # Wait.
    wait(10)

Lego Go Kart (42109 variant)

from pybricks.pupdevices import Motor, Remote
from pybricks.parameters import Port, Direction, Stop, Button, Color
from pybricks.hubs import TechnicHub
from pybricks.tools import wait

# Initialize the motors.
steer = Motor(Port.B)
front = Motor(Port.D, Direction.COUNTERCLOCKWISE)

# Connect to the remote and set the light on the remote
remote = Remote('topgear', timeout=None)
remote.light.on(Color.GREEN)

# Print the current name of the remote.
print(remote.name())

# Choose a new name.
remote.name('kart')

# Initialize the hub.
hub = TechnicHub()
hub.light.on(Color.GREEN)

# Read the current settings
old_kp, old_ki, old_kd, _, _ = steer.control.pid()

# Set new values
steer.control.pid(kp=old_kp*4, kd=old_kd*0.4)

# Set initial top speed value
top_speed = 100

# Find the steering endpoint on the left and right.
# The middle is in between.
left_end = steer.run_until_stalled(-200, then=Stop.HOLD)
right_end = steer.run_until_stalled(200, then=Stop.HOLD)

# We are now at the right. Reset this angle to be half the difference.
# That puts zero in the middle.
steer.reset_angle((right_end - left_end)/2)
steer.run_target(speed=200, target_angle=0, wait=False)

# Set steering angle for the buggy
steer_angle = (((right_end - left_end)/2)-5)

# Now we can start driving!
while True:
    # Check which buttons are pressed.
    pressed = remote.buttons.pressed()

    # Choose the steer angle based on the right controls.
    if Button.LEFT_PLUS in pressed:
        steer.run_target(1400, -steer_angle, Stop.HOLD, False)
    elif Button.LEFT_MINUS in pressed:
        steer.run_target(1400, steer_angle, Stop.HOLD, False)
    else:
        steer.track_target(0)

    # Top speed controls
    if Button.LEFT in pressed:
        top_speed = 75
    if Button.RIGHT in pressed:
        top_speed = 100   
    if ((Button.RIGHT in pressed) and (Button.LEFT in pressed)):
        top_speed = 40 

    # Choose the drive speed based on the left controls.
    drive_speed = 0
    if Button.RIGHT_PLUS in pressed:
        drive_speed -= top_speed
    if Button.RIGHT_MINUS in pressed:
        drive_speed += top_speed

    # Print battery voltage    
    if Button.RIGHT in pressed:
        print('Battery voltage:',(hub.battery.voltage())/1000,"V")
        wait(100)           

    # Apply the selected speed.
    front.dc(drive_speed)

    # Wait.
    wait(10)

Lego 4×4 Extreme Off-Roader (42099)

from pybricks.pupdevices import Motor, Remote
from pybricks.parameters import Port, Direction, Stop, Button
from pybricks.tools import wait

# Initialize the motors.
steer = Motor(Port.C)
front = Motor(Port.A, Direction.COUNTERCLOCKWISE)
rear = Motor(Port.B, Direction.COUNTERCLOCKWISE)

# Lower the acceleration so the car starts and stops realistically.
front.control.limits(acceleration=1000)
rear.control.limits(acceleration=1000)

# Connect to the remote.
remote = Remote()

# Find the steering endpoint on the left and right.
# The middle is in between.
left_end = steer.run_until_stalled(-200, then=Stop.HOLD)
right_end = steer.run_until_stalled(200, then=Stop.HOLD)

# We are now at the right. Reset this angle to be half the difference.
# That puts zero in the middle.
steer.reset_angle((right_end - left_end) / 2)
steer.run_target(speed=200, target_angle=0, wait=False)

# Now we can start driving!
while True:
    # Check which buttons are pressed.
    pressed = remote.buttons.pressed()

    # Choose the steer angle based on the left controls.
    steer_angle = 0
    if Button.LEFT_PLUS in pressed:
        steer_angle -= 75
    if Button.LEFT_MINUS in pressed:
        steer_angle += 75

    # Steer to the selected angle.
    steer.run_target(500, steer_angle, wait=False)

    # Choose the drive speed based on the right controls.
    drive_speed = 0
    if Button.RIGHT_PLUS in pressed:
        drive_speed += 1000
    if Button.RIGHT_MINUS in pressed:
        drive_speed -= 1000

    # Apply the selected speed.
    front.run(drive_speed)
    rear.run(drive_speed)

    # Wait.
    wait(10)

Troubleshooting

If you’re having issues getting the code to work, you can try both editors:

• beta.pybricks.com
• code.pybricks.com

You can also use this code to verify that a connection is being successfully made by your controller with the hub:

from pybricks.hubs import TechnicHub
from pybricks.pupdevices import Remote
from pybricks.parameters import Button, Color
from pybricks.tools import wait

hub = TechnicHub()

# Make the light red while we connect.
hub.light.on(Color.RED)

# Connect to the remote.
my_remote = Remote() 

# Make the light green when we are connected.
hub.light.on(Color.GREEN)

while True:
    # For any button press, make the light magenta.
    # Otherwise make it yellow.
    if my_remote.buttons.pressed():
        hub.light.on(Color.MAGENTA)
    else:
        hub.light.on(Color.YELLOW)
    wait(10)

Lego 42124 Trike Variant

from pybricks.pupdevices import Motor, Remote
from pybricks.parameters import Port, Direction, Stop, Button
from pybricks.hubs import TechnicHub
from pybricks.tools import wait

# Initialize the motors.
steer = Motor(Port.B)
front = Motor(Port.A, Direction.COUNTERCLOCKWISE)

# Connect to the remote.
remote = Remote()

# Initialize the hub.
hub = TechnicHub()

# Read the current settings
old_kp, old_ki, old_kd, _, _ = steer.control.pid()

# Set new values
steer.control.pid(kp=old_kp*0.5, kd=old_kd*1)

# Find the steering endpoint on the left and right.
# The middle is in between.
left_end = steer.run_until_stalled(-200, then=Stop.HOLD)
right_end = steer.run_until_stalled(200, then=Stop.HOLD)

print('left end:',left_end)
print('right end:', right_end)

# We are now at the right. Reset this angle to be half the difference.
# That puts zero in the middle.
steer.reset_angle((right_end - left_end)/2)
steer.run_target(speed=100, target_angle=0, wait=False)

# Set steering angle for the buggy
steer_angle = (((right_end - left_end)/2)-20)
print('steer angle:',steer_angle)

# Now we can start driving!
while True:
    # Check which buttons are pressed.
    pressed = remote.buttons.pressed()

    # Choose the steer angle based on the right controls.
    if Button.LEFT_PLUS in pressed:
        steer.run_target(400, -steer_angle, Stop.HOLD, False)
    elif Button.LEFT_MINUS in pressed:
        steer.run_target(400, steer_angle, Stop.HOLD, False)
    else:
        current_angle = steer.angle()
        deadband = 3  # Define a deadband range of +/- 3 degrees
        if current_angle > deadband:
            steer.track_target(0)
        elif current_angle < -deadband:
            steer.track_target(0)
        else:
            steer.stop()

    # Top speed controls
    top_speed = 50
    if Button.LEFT in pressed:
        top_speed = 100         

    # Choose the drive speed based on the left controls.
    drive_speed = 0
    if Button.RIGHT_PLUS in pressed:
        drive_speed += top_speed
    if Button.RIGHT_MINUS in pressed:
        drive_speed -= top_speed
    if Button.RIGHT in pressed:
        print('Battery voltage:',(hub.battery.voltage())/1000,"V")
        wait(100)          

    # Apply the selected speed.
    front.dc(drive_speed)

    # Wait.
    wait(10)

Lego 42160 Audi e-tron

from pybricks.pupdevices import Motor, Remote
from pybricks.parameters import Port, Direction, Stop, Button, Color
from pybricks.hubs import TechnicHub
from pybricks.tools import wait

# --- Motor setup for Audi RS Q e-tron (42160) ---
# Adjust ports if your wiring is different.
steer = Motor(Port.D)  # steering motor

# Both drive motors. If the car drives backwards, flip the sign of drive_speed
# below or change one/both to Direction.COUNTERCLOCKWISE.
front = Motor(Port.A, Direction.CLOCKWISE)
rear  = Motor(Port.B, Direction.CLOCKWISE)

# Hub + remote
hub = TechnicHub()
remote = Remote(timeout=None)

# Set both lights to a supported color
hub.light.on(Color.MAGENTA)
remote.light.on(Color.MAGENTA)

# --- Steering PID tweak (same idea as your buggy) ---
old_kp, old_ki, old_kd, _, _ = steer.control.pid()
steer.control.pid(kp=old_kp * 4, kd=old_kd * 0.4)

# --- Auto-center steering using the end stops ---

# Find the steering endpoint on the left and right.
left_end = steer.run_until_stalled(-200, then=Stop.HOLD)
right_end = steer.run_until_stalled(200, then=Stop.HOLD)

# We are now at the right end.
# The middle is half the difference between right and left.
center_offset = (right_end - left_end) / 2

# Define "0" as the middle by setting the current angle to center_offset.
steer.reset_angle(center_offset)

# Now command the motor to go to target 0 (which is the middle).
steer.run_target(speed=200, target_angle=0, wait=False)

# How far we can safely steer from center (small margin from hard stops).
steer_angle = center_offset - 5
if steer_angle < 0:
    steer_angle = 0  # safety clamp

print("left_end:", left_end)
print("right_end:", right_end)
print("center_offset:", center_offset)
print("steer_angle used:", steer_angle)

# --- Main control loop ---
while True:
    pressed = remote.buttons.pressed()

    # Steering with LEFT +/- buttons.
    if Button.LEFT_PLUS in pressed:
        steer.run_target(1400, -steer_angle, Stop.HOLD, wait=False)
    elif Button.LEFT_MINUS in pressed:
        steer.run_target(1400, steer_angle, Stop.HOLD, wait=False)
    else:
        # Hold center.
        steer.track_target(0)

    # Top speed controls
    top_speed = 100
    if Button.LEFT in pressed:
        top_speed = 60  # slow mode

    # Drive speed with RIGHT +/- buttons.
    drive_speed = 0
    if Button.RIGHT_PLUS in pressed:
        drive_speed += top_speed
    if Button.RIGHT_MINUS in pressed:
        drive_speed -= top_speed

    # Battery voltage on RIGHT center button.
    if Button.RIGHT in pressed:
        print("Battery voltage:", hub.battery.voltage() / 1000, "V")
        wait(100)

    # Apply the selected speed to BOTH drive motors.
    front.dc(drive_speed)
    rear.dc(drive_speed)

    wait(10)

Lego 51515 Robot Inventor

You can also use the same principles to connect to the Lego 51515 Robot Inventor hub. There are many things you can build with that kit, but below you can find the general framework for connecting the Lego remote to the 51515 hub:

from pybricks.hubs import InventorHub
from pybricks.pupdevices import Remote
from pybricks.parameters import Button
from pybricks.tools import wait

# Initialize the hub and the remote
hub = InventorHub()
remote = Remote()

while True:
    # Check if a button on the remote is pressed
    pressed = remote.buttons.pressed()

    if Button.LEFT in pressed:
        # Code for when the left button is pressed
        pass
    elif Button.RIGHT in pressed:
        # Code for when the right button is pressed
        pass
    
    # Delay to avoid rapid polling
    wait(10)

Using a PS4 Controller via BrickController2

BrickController2 is an app that lets you control LEGO creations with game controllers. To use a PS4 controller with BrickController2, follow these steps:

1. Pair the PS4 Controller with Your Device:a. Put the PS4 controller in pairing mode by holding down the “Share” and “PS” buttons at the same time until the light bar starts flashing.b. On your device (whether it’s an Android or iOS), open the Bluetooth settings.c. Look for the PS4 controller in the list of available devices. It might show up as “Wireless Controller” or something similar.

   d. Tap on the PS4 controller’s name in the list to pair it with your device. You might be prompted to confirm the pairing.

2. Open BrickController2:a. Make sure you’ve set up your LEGO devices in the app.b. In the “Controllers” section, you should see the PS4 controller listed if it’s connected. If not, try disconnecting and reconnecting the PS4 controller via Bluetooth.
3. Assign Controls:a. Once the PS4 controller is recognized in BrickController2, you can start assigning its buttons to control specific functions of your LEGO creation. This can include movement directions, rotations, or other actions.
4. Play and Control:Once you’ve set up the controls, you can use your PS4 controller to play with and control your LEGO models. Ensure the LEGO devices and the controller are both connected and in range for optimal performance.

Further Reading

• Brickset – reviews of Lego sets
• Rebrickable – alternate builds
  • GoPro mod
• MOCHub – “my own creation”
• RacingBrick on Youtube – fantastic Lego builds channel