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 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

Powerlink adapters are a fantastic invention that help those who have poor WiFi connections at home get a decent signal through the powerlines. I’ve tried various solutions to be able to make the best use of my fibre optic connections in rooms where the WiFi connection was playing around, and have finally settled on the Netgear adaptors.

I just wanted to write a few notes down here for my future self and others who might be in the market for one of these devices.

I’ve also tried the Devolo and TP-link options. I got the best product from each of these brands, but the Netgear was the clear winner. In fact, although it advertised lower speeds than the Devolo, it still came up on top in the end.

The difference between the Netgear and Devolo was very significant. I could reach the same upload speed with both but download speed on the Devolo was half that of the Netgear.

An interesting fact is that it’s the upload speed that suffered most with WiFi connections. I’m not sure why that is so.

I’m quite a fanatic about making backups of every digital asset I have, so having a reliable software to handle backups is essential to me.

The candidates for Mac backup:

• SuperDuper
• Carbon Copy Cloner
• FreeFileSync
• RsyncGUI

SuperDuper

SuperDuper’s website feels like we’re still in the 90s and it’s hard to trust such a website and the software it is selling. I’ve tried it but it didn’t feel as slick as Carbon Copy Cloner. The only advantage is it’s cheaper than CCC, coming in at $40.

Carbon Copy Cloner

Carbon Copy Cloner is the most polished of all the candidates and costs $60. It probably has a more stable and bigger dev. team behind it. SuperDuper seems more on the indie side. When it comes to backups saving you in the event of a meltdown, trust is essential. I get that from CCC. Having said that, both SuperDuper and Carbon Copy Cloner will do the same job and do it well.

Click here for a good comparison between CCC and SuperDuper.

FreeFileSync

FreeFileSync is what I’ve used for many years and it works fine. It’s open-source and completely free, so if money is an issue this should be your first choice. The GUI is good enough and I really couldn’t ask more from a free software, it does the job.

RsyncGUI

RsyncGUI is not developed to be an easy synchronize and backup tool. The main purpose is to ease the use of rsync and synchronize files on your Mac to remote FreeBSD and Linux servers. And of course restore files from remote servers. The UI might also be difficult to understand or complex if you don’t know what rsync is. It is not required to know rsync but it will ease the use and understanding of RsyncGUI. But it is though, possible to use RsyncGUI by just adding a source and remote backup catalog using default parameters.

If your plan is to use RsyncGUI as your main tool for backup of files, please investigate and understand the limits of it. RsyncGUI is quite powerful, but it is might not the primary backup tool for the average user of macOS.

My Choices

I use Time Machine to backup my various machines on a continuous basis, and Carbon Copy Cloner for more periodic backups or backups of specific folders to external media for archiving purposes.