Building Products for Hosting Providers Means Building for More Than One Customer

In hosting, “the customer” is rarely one person.

That’s easy to miss if you come from a more direct product environment. A user has a problem, they buy or install the product, they use it, and the product team watches what happens. Even that model is messier than it sounds, but at least the path is visible.

Hosting adds layers.

A provider may buy the product. An operations team may live with it every day. A support team may have to explain it when something goes sideways. An agency or developer may configure it. A small-business owner may experience the outcome without knowing the product exists. A site visitor may be the person who actually feels the benefit when something works or the pain when it doesn’t.

If a product team treats all of those people as one generic customer, the product model isn’t finished yet.

They’re not all customers in the same commercial sense. That’s the point. Hosting products move through a chain of buyers, operators, support teams, and end customers. If the product only works for one part of that chain, it doesn’t really work yet.

This is the hosting-specific version of starting with the experience, not the feature list. The experience just has more people inside it.

The Buyer Needs a Business Reason

The provider buying or bundling the product needs a reason that fits the business.

That reason may be revenue. It may be retention. It may be risk reduction, support deflection, differentiation, customer trust, operational efficiency, or some mix of all of those.

This is especially true in hosting because providers operate at scale and on thin margins. A feature that looks small in isolation can become expensive when it has to be explained, supported, billed, monitored, and renewed across thousands or millions of customers.

The buyer isn’t only asking, “Is this useful?”

They’re asking:

  • Can we sell it?
  • Can we support it?
  • Does it fit our existing customer relationship?
  • Does it reduce a real cost or create a real opportunity?
  • Does it make us look more valuable to our customers?
  • Will this become another thing our team has to apologize for?

That last question isn’t usually in the procurement checklist. It should be.

Products that create customer confusion, operational surprises, or support burden burn trust faster than their feature list earns it.

The Operator Needs It to Behave

The person operating the product often has a different set of needs.

They need it to install cleanly. They need logs that make sense. They need failure modes that don’t ruin their morning. They need alerts that point to a decision instead of merely creating anxiety. They need configuration that doesn’t require a private translation layer between engineering, support, and the customer.

This is where many otherwise good products struggle.

The sales story may be clear. The demo may be compelling. The underlying technology may be strong. Then the product reaches the people who have to make it work in the provider’s environment, and suddenly the real product appears.

How hard is it to deploy?

How much does it assume about the provider’s stack?

Can support understand what happened without escalating every case?

Can the provider safely enable the important parts by default?

Can the team tell the difference between a product issue, a customer issue, and an expected tradeoff?

The operator doesn’t need a prettier promise. They need the product to behave predictably inside the messy system where it’ll actually run.

The End Customer Needs a Clear Outcome

The end customer often doesn’t care about the architecture.

That’s not an insult. Most people running a website aren’t trying to become experts in hosting infrastructure, DNS, runtime protection, malware cleanup, backup retention, caching layers, or abuse workflows. They want their site to work. They want their business to be reachable. They want problems to be understandable and fixable.

That means a hosting product has to create value that survives translation.

If a provider sells a security product, the end customer needs to understand what is being protected, what action they might need to take, and what happens when something goes wrong. If a provider offers performance tooling, the customer needs to understand the outcome, not the internal elegance of the caching strategy. If a provider offers backups, the customer needs confidence that restore will work when the day is already bad.

The end customer may never see the product dashboard. They may never read the technical documentation. Their experience may be mediated entirely through the provider’s control panel, email, support team, invoices, and incident notifications.

That’s still the product.

The Support Team Needs Context and Recoverability

Support is sometimes treated as the place where product problems go after launch.

In hosting, support is part of the product experience from the beginning.

A confusing setting becomes a ticket. A vague alert becomes a chat. A false-positive security decision becomes an urgent escalation. A billing surprise becomes a cancellation risk. A feature that requires too much customer education becomes a repeated conversation across every support channel.

That means support needs more than a help article. They need context they can trust, language they can use with customers, and recovery paths that don’t depend on heroic escalation every time something gets weird.

Support cost isn’t just an operating expense. It’s product feedback with a timestamp.

That doesn’t mean every support ticket is proof of bad design. Hosting is complicated, customers vary widely, and some problems genuinely require human help. But when the same question appears again and again, the product is probably asking too much of the people around it.

Good product teams don’t only ask how support can answer faster. They ask why the question is necessary.

Defaults Matter More Than Documentation

Documentation matters. Clear setup guides matter. Release notes matter.

Defaults matter more.

Most customers won’t study every option before making the safest choice. Many won’t know which choice is safest. Some won’t know there was a choice at all.

That gives hosting providers and their product partners a lot of responsibility. The default setting often becomes the real product. The recommended path becomes the customer’s path. The warning that appears at the right moment may matter more than a perfect help article three clicks away.

This is why product work in hosting has to include packaging, onboarding, control-panel placement, alert language, support tooling, and recovery flows. Those things may look secondary from the outside, but they decide whether the customer actually receives the value.

If the right behavior requires a busy customer to understand the whole system first, the product is depending on luck.

Distribution Is a Product Constraint

Channel products sometimes fail because the team treats distribution as a go-to-market problem that starts after the product is built.

In hosting, distribution is part of the product.

Does the product fit the provider’s existing packages? Can it be trialed without creating operational risk? Does it map cleanly to the provider’s billing system? Can it be explained by sales without overpromising? Can it be enabled by support without a fragile checklist? Does it create value before the customer has to make a complicated decision?

These questions shape what should be built.

A product that only works when sold directly by experts may be a good product, but it may not be a good hosting product. A product that requires every end customer to become aware, motivated, educated, and technically confident before it works will struggle in a channel where the provider owns much of the relationship.

The product has to fit the path it travels.

Name the Customers Before Naming the Features

When a hosting product is being planned, I like to name the customers separately.

The provider needs a business case.

The operator needs predictable behavior.

The support team needs context and recoverability.

The end customer needs a clear outcome.

Sometimes those needs point in the same direction. Sometimes they create tension.

An aggressive default may improve protection for the end customer but create support risk for the provider. A flexible configuration may help advanced operators but confuse smaller customers. A powerful feature may help sales but require an implementation burden the provider isn’t ready to carry.

Those aren’t reasons to stop. They’re the actual product decisions.

The mistake is pretending there is only one customer and then being surprised when the product succeeds for one audience while failing for another.

Build for the Relationship

Hosting providers don’t only sell infrastructure. They sit inside an ongoing relationship with the customer.

That relationship includes trust, billing, support, renewals, incidents, security scares, migrations, growth, and the occasional very bad day. Products that fit that relationship can create value beyond the feature itself. Products that ignore it create friction in places the original product team may never see.

This is why building for hosting providers is such good product discipline.

It forces the team to think beyond the immediate user interface. It requires business value, operational reality, support cost, customer understanding, distribution, defaults, and recovery to be part of the same conversation.

That’s the real work.

Not just building a feature a provider can buy.

Building a product the provider can sell, operate, support, and trust on behalf of the people who depend on them.

Open Source Support Can’t Depend on Charity

Companies depend on open source software.

They use it to build products, operate infrastructure, serve customers, and make money. In many cases, the company couldn’t function without it.

Then someone asks whether the company should help support the projects it depends on, and the conversation turns strangely charitable.

Is supporting open source a nice thing to do? Is it part of being a good member of the community? Can we find a little budget for sponsorship this year?

Those aren’t bad questions. They’re simply not enough to sustain something a business relies on.

Charity is optional. Dependencies aren’t.

That distinction matters more now than it did when I first started drafting this argument years ago. Open source is no longer something companies use at the edges because a developer found a helpful library. It’s the foundation under products, infrastructure, AI systems, security tools, cloud platforms, developer workflows, and the web itself.

We’re also seeing more public recognition that open source is infrastructure. The Sovereign Tech Agency now lists more than 100 supported technologies and tens of millions of euros invested in open digital infrastructure. That kind of funding is useful. It’s also a sign of how large the maintenance problem has become.

If a project is critical enough for governments, foundations, and companies to describe it as infrastructure, then supporting it can’t depend on whether someone feels generous this quarter.

xkcd comic showing a large modern digital infrastructure stack balanced on a small open source project maintained by one person.
Critical systems often depend on open source work that is easy to overlook until it fails.
Comic: “Dependency” by Randall Munroe / xkcd, used under CC BY-NC 2.5.

Money Matters

Companies need to make money.

That isn’t a criticism. Revenue lets a company pay employees, support customers, invest in new products, and continue operating. A company that doesn’t care about financial sustainability won’t be a reliable partner for very long.

Open source projects need sustainability too. Code has to be maintained. Reports have to be reviewed. Releases have to be tested. Documentation has to be written. Security issues have to be handled carefully. Contributors need help becoming maintainers, and maintainers need the ability to step away without putting the project at risk.

Much of that work is difficult to see precisely because someone has been doing it well.

When a company treats support as a donation, that support has to compete with every other worthy cause. The budget may survive one year and disappear the next, even though the company’s technical dependence hasn’t changed.

A more durable model starts by recognizing support as an investment in infrastructure.

That’s a different conversation inside a company. Donations are nice. Risk reduction, dependency health, predictable maintenance, security response, and operational continuity are business concerns.

Free to Use Doesn’t Mean Free to Sustain

Open source licenses give people important freedoms. Depending on the license, those freedoms may include the ability to use, study, modify, and redistribute the software.

They don’t promise that another person will maintain the software forever.

This is where expectations can become badly misaligned. A company adopts a project because it’s capable, flexible, and free to use. Over time, it becomes critical. The company expects timely security responses, compatibility, documentation, roadmaps, and help when something goes wrong.

Those expectations are understandable. They’re also work.

The license may not require the company to fund that work. Sustainability asks a different question: what behavior gives the company the reliable dependency it wants to keep having?

Companies Need More Than Code

Most businesses don’t actually want a pile of source code.

They want confidence.

They want to know whether a project is maintained. They want a clear way to report a security problem. They want to understand the direction of the project before a change surprises them. They may need support, migration guidance, compatibility information, or someone accountable for helping when the software fails.

This creates several kinds of value an open source project or its surrounding ecosystem can provide:

Support

Companies will pay for access to people who understand the software deeply and can help resolve important problems.

This can come from a commercial company, a foundation, a maintainer collective, or independent experts. The exact structure matters less than whether the support is reliable and the people providing it are connected to the project.

Risk Reduction

Funding maintenance, security work, testing, release engineering, and documentation reduces the risk attached to a critical dependency.

This is often easier to justify internally than a general donation. Companies already spend money reducing operational and supply-chain risk. Open source shouldn’t become invisible merely because there wasn’t a traditional vendor invoice.

Participation

Companies need a practical way to understand what’s changing and provide useful input.

Telling them “anyone can participate” is technically true and often practically useless. Meaningful participation may require learning unfamiliar tools, attending meetings in another time zone, following several discussion channels, and understanding years of project history.

A funded liaison, regular briefing, advisory group, or clearly documented feedback process can lower that barrier without selling control of the project.

Accountability

Businesses often need to know who will respond when something goes wrong.

Open source communities are right to resist the idea that volunteers owe every user an enterprise service-level agreement. If a company needs guaranteed response times or contractual accountability, it should pay an organization prepared to provide them.

The answer isn’t to pressure maintainers into behaving like an unpaid vendor. It’s to build a commercial layer where commercial guarantees are actually possible.

WordPress Is a Useful Example

WordPress is the ecosystem I know best, and it’s a useful example precisely because the support doesn’t come from one company in one way.

Automattic has put enormous time and money into the project for years. So have companies like 10up, XWP, Bluehost, Yoast, and rtCamp, to different degrees and at different times. Some of that support shows up as sponsored contributors. Some shows up as core committers. Some shows up in release work, testing, documentation, accessibility, performance, hosting knowledge, community work, and the unglamorous maintenance that keeps a project usable.

The 2023 Year in Core post makes the point in numbers. It counted 1,079 people contributing to WordPress Core through Trac, including 472 first-time contributors. It also matched contributors to at least 286 companies. Automattic, Yoast, 10up, Bluehost, and XWP all appeared among companies with more than 100 contributions that year, and rtCamp appeared among the small group of companies with at least 10 people credited on Trac.

Those numbers shouldn’t be treated as a perfect scoreboard. The post itself is careful to say the data covers code contributions to the WordPress codebase on Trac, not every kind of contribution across the project. It doesn’t capture all of the community work, events, documentation, support, training, project management, plugin ecosystem work, or the many ways people help that don’t land as a commit.

Still, the pattern matters.

In the 2022 Year in Core data, Yoast, Automattic, 10up, Bluehost, and other companies were again visible in the contribution numbers. In the 2021 Year in Core data, Automattic, Yoast, and Bluehost were prominent, and 10up appeared among the few companies with more than ten people credited on Trac.

The specific numbers move around. That’s normal. Company strategy changes. Product priorities change. People move. Release cycles emphasize different areas of the codebase. A healthy ecosystem shouldn’t require every company to contribute the same way every year.

What matters is that commercial participation can be made visible enough to recognize, discuss, and improve.

WordPress has plenty of tensions around contribution. Every large open source project does. But it also shows that companies can put real money, time, and people into a project because that project helps support their business.

That’s different from charity. It’s not only goodwill, and it shouldn’t need to be defended as a favor to the community. It’s a company helping sustain the infrastructure, ecosystem, and user trust that its own products and customers depend on.

That’s the kind of exchange open source needs more of.

Payment Can’t Buy Governance

Once money enters the conversation, another risk appears.

A company may reasonably expect value for its investment. That doesn’t mean it should be able to buy the project’s decisions.

If funding becomes pay-to-play governance, the project stops serving its wider community and begins serving its largest sponsors. Users lose trust, unpaid contributors lose influence, and the project becomes open source in license more than in practice.

Healthy support separates access from control.

A sponsor may receive support, briefings, risk reporting, implementation help, or a structured way to offer input. It shouldn’t receive an automatic veto over maintainers or users.

This is one reason clear governance matters. Companies need to know what their money does and doesn’t buy. Maintainers need boundaries they can point to. Contributors and users need confidence that participation still matters.

Projects Have Work to Do Too

It’s easy for an open source project to say that companies should contribute more. It’s harder to make contribution practical.

Projects asking for sustained support should be able to explain:

  • What work needs funding
  • Who will do it
  • How priorities are chosen
  • How progress will be communicated
  • What supporters receive
  • What supporters don’t control
  • How the investment benefits the wider project

This doesn’t require turning every project into a company. It does require treating sustainability as a product and governance problem rather than waiting for someone to feel generous.

The project has to make the value legible.

That may feel uncomfortable. Many maintainers started by solving a problem, not by building a funding model. But if the project wants sustained support from organizations, someone has to explain the exchange clearly enough that a product leader, security leader, procurement team, or executive can justify it.

The alternative is hoping the right person inside the company cares enough and has enough influence to push support through manually. Sometimes that works. It doesn’t scale.

Companies Have Work to Do Too

Companies should know which open source projects their products and operations depend on.

That sounds basic, but many organizations can’t answer it confidently. They know the direct dependencies in a particular application but not the transitive dependencies, build tools, libraries, infrastructure components, and community services underneath them.

Once those dependencies are visible, the company can assess:

  • How critical is this project to us?
  • How concentrated is its maintenance?
  • What would happen if releases or security work stopped?
  • Are we creating support burden without contributing useful reports or fixes?
  • Can we fund the project directly?
  • Should we buy support from a company employing maintainers?
  • Can employees contribute during paid time?
  • Can we help with documentation, testing, infrastructure, or governance instead of only code?

Money is important. It’s not the only useful contribution.

The goal is a relationship where the project’s health is part of the company’s dependency strategy.

That relationship also needs humility from the company. Money doesn’t make a company the main character of a community. If the only contribution a company is willing to make is one that gives it special control, the project has every reason to be cautious.

Good support should make the project healthier for everyone who depends on it, not just more responsive to the loudest or richest user.

Build an Exchange That Can Last

Open source support motivated by generosity is worth appreciating. It just isn’t a durable foundation for critical infrastructure.

Companies need reliable software, reduced risk, useful participation, and accountability. Projects need money, time, maintenance, contributors, and governance that protects the community.

The opportunity is to build an honest exchange between those needs.

Companies should be able to explain why supporting a project is good for the business. Projects should be able to explain what support makes possible. Neither side should have to pretend that money is shameful or that a license creates an unlimited obligation to serve.

Open source is built on shared value.

Its support models should be too.

Cleaned Isn’t Fixed

Operation Endgame’s SocGholish takedown was good news.

It was also a warning.

Law enforcement and private-sector partners disrupted SocGholish infrastructure, took down 106 servers and domains, and cleaned 14,971 compromised WordPress sites. That’s real work. Those sites were being used as part of a malware delivery chain, and removing that active abuse protected real people from real harm.

But this is the part that can’t get lost in the headline:

Cleaned isn’t fixed.

Removing injected malware from a site doesn’t necessarily change the condition that let attackers put it there in the first place. If the way in was a stolen administrator password, that password still needs to be rotated. If the way in was an unpatched plugin, that plugin still needs to be updated or removed. If an unauthorized admin account was added, it still needs to be found and deleted.

The cleanup bought time. The fix is what happens next.

The Site Was Part of Someone Else’s Attack Chain

SocGholish, also known as FakeUpdates, is a good example of why web security can’t be treated as a problem that stops at the edge of one website.

The visitor doesn’t have to know anything about WordPress. They may not even care what platform the site runs on. They land on a legitimate site, see what looks like a browser update prompt, and are tricked into installing malware.

The compromised site becomes the delivery point. The site owner’s brand, domain reputation, and visitor trust get borrowed by the attacker.

That should make every host, agency, plugin developer, and site owner pause for a second. A vulnerable site isn’t only a risk to itself. It can become infrastructure for somebody else’s campaign.

This is why the 14,971 number matters. It’s not just a count of affected websites. It’s a picture of how quickly legitimate places on the web can be turned into stepping stones when basic controls fail.

And it wasn’t the whole picture. Shadowserver’s special report covered more than 1.4 million instances of compromised WordPress sites that were available for use by SocGholish between May 2023 and May 2026. The cleanup number is the urgent operational win. The larger dataset is the strategic warning.

The Doors Were Familiar

One reason SocGholish is useful as a lesson is that the entry points aren’t mysterious.

Shadowserver’s report points to the kinds of compromise paths anyone who has worked in web security will recognize: leaked or reused credentials, password guessing, vulnerable CMS code, vulnerable plugins or themes, hosting-platform issues, third-party services, and credential-stealing malware.

That’s not exotic. It’s Tuesday.

And that should shape the response. If we treat this as a strange, one-off malware event, we miss the point. The same conditions that made those sites useful to SocGholish exist across the web every day:

  • Administrator accounts with weak or reused passwords
  • No multi-factor authentication on privileged access
  • Plugins and themes that are installed but no longer maintained
  • Unknown admin users that nobody has audited
  • Domains and DNS accounts that are trusted but barely monitored
  • Sites that are cleaned after infection but not hardened afterward

The remediation guidance from Dutch police was refreshingly practical: change login credentials, enable multi-factor authentication, delete unknown WordPress accounts, and keep WordPress, plugins, and related software up to date.

That isn’t glamorous advice. It’s the work.

AI Is Changing the Time Window

The SocGholish takedown happened the same week the Five Eyes cyber security agencies issued a joint statement about AI and cyber risk.

The important point wasn’t simply "AI is scary" or "use AI for defense." The more useful point was that AI is compressing time.

For a long time, many web security practices have assumed there’s a useful window between vulnerability disclosure and widespread exploitation. Maybe that window was weeks. Maybe it was days. It was rarely comfortable, but it was something defenders could build process around.

Patch cycles, WAF signatures, support queues, vulnerability triage, customer notifications, manual cleanup, and incident response plans all quietly depend on time.

That assumption is getting weaker.

When attackers can find, weaponize, and scale exploitation faster, the old "we’ll get to it soon" model breaks down. The Five Eyes statement is clear that leaders need to treat cyber resilience as a business issue, not just a technical one. That matters because speed isn’t only an engineering problem. It’s an operating model problem.

The statement also makes a point that should sound familiar to anyone who has worked through real incidents: more tools aren’t the same thing as better resilience. The basics still matter. They just have to happen faster and more reliably.

If your organization needs three weeks to identify exposed assets, two more weeks to decide who owns the fix, and another week to communicate clearly with customers, AI didn’t create your risk. It exposed it.

Hosts Have a Different Responsibility

For a single site owner, the advice is direct: patch, rotate credentials, enable MFA, audit users, and watch for reinfection.

For a host or platform provider, the question is larger.

It’s not enough to ask whether your customers were on this specific cleanup list. The better question is whether the conditions that made those sites vulnerable exist on your platform.

They probably do.

That doesn’t mean the platform is bad. It means shared hosting, managed WordPress, agency-maintained sites, long-lived plugins, delegated ownership, and small-business websites create a complicated security environment. A host can’t personally manage every customer’s password, plugin choice, DNS provider, and admin workflow.

But a host can shape defaults.

A host can reduce the number of unsafe choices customers have to make. It can make risky conditions visible before an incident. It can give support teams clear signals instead of vague alerts. It can build security into onboarding, account recovery, plugin management, backups, malware cleanup, and customer communication.

That’s product work, not just security work. It decides what the customer sees, what they understand, what they trust, and what they actually do.

The best security capabilities in hosting are often the ones that change the customer’s path before something goes wrong. Easy MFA. Understandable patch visibility. Plugin risk presented in plain language. Malware cleanup that includes hardening steps. Recovery that doesn’t require a customer to understand the whole attack chain while they’re already stressed.

Security at this layer has to meet customers where they actually are.

Cleanup Has to Become a System

There’s a pattern that shows up after malware incidents:

  1. Detect the infection.
  2. Remove the visible malicious code.
  3. Tell the customer the site is clean.
  4. Move on.

That may be understandable operationally, especially when support queues are full and customers want the site back online. But it’s incomplete.

A cleaned site can still be unsafe. A restored backup can still include the vulnerable plugin. A changed password doesn’t help if there are two unknown admin accounts. A patched plugin doesn’t help if the attacker owns the domain registrar account. A malware scan doesn’t help if the original compromise came from a developer’s stolen credentials.

This is where the product experience matters.

After a cleanup, the user shouldn’t be left with a vague sense that they ought to "be more secure." They need a small, specific, prioritized set of actions:

  • Rotate administrator, hosting, database, FTP/SFTP, SSH, and relevant third party credentials.
  • Enable multi-factor authentication for privileged accounts.
  • Review admin users and remove anything that can’t be explained.
  • Update WordPress core, plugins, themes, and server-side dependencies.
  • Remove unused plugins and themes.
  • Review DNS, registrar, and CDN access.
  • Confirm clean public output, not just a clean dashboard.
  • Watch for reinfection patterns over the next days and weeks.

The point isn’t to scare every small-business owner into becoming a security engineer. The point is to make the next right step obvious.

AI Helps, But It Doesn’t Replace the Basics

There’s absolutely a role for AI in defense.

AI can help defenders triage faster, spot patterns across huge volumes of signals, prioritize vulnerable assets, summarize incidents, identify suspicious behavior, and reduce the amount of repetitive work placed on already-tired teams.

That’s useful. In many environments, it’ll become necessary.

But AI on top of weak fundamentals isn’t resilience. It’s a faster dashboard for an unlocked door.

If you don’t know what you host, who can access it, which software is exposed, which plugins are abandoned, where credentials are reused, or how quickly you can recover from a bad change, an AI system has very little solid ground to stand on.

The fundamentals aren’t less important because AI exists. They’re more urgent because AI changes the speed and scale of the fight.

The Practical Lesson

The SocGholish takedown is worth celebrating. It disrupted criminal infrastructure, removed active abuse from thousands of legitimate websites, and gave site owners a chance to close the doors attackers had been using.

But the durable lesson isn’t "law enforcement cleaned the sites."

The durable lesson is that cleanup is only one phase of security.

For site owners, the next step is hardening. For hosts, the next step is turning hardening into a repeatable product and support workflow. For leaders, the next step is making cyber resilience part of business continuity, customer trust, and market confidence.

The clock starts when the malware is removed.

What happens after that determines whether the site was fixed.

Start With the Experience, Not the Feature List

Product teams love feature lists.

Features are concrete. You can estimate them, assign them, build them, and put them on a slide. They give everyone the satisfying feeling that the product is moving forward.

Unfortunately, a team can deliver every feature on the list and still build the wrong product.

The problem usually starts before the first line of code. The team begins by asking, “What should this product do?” when the better first question is, “What should the customer be able to accomplish, and what should that experience be like?”

Those questions sound similar. They’re not.

I laid out this model in a talk for the WP London Meetup in March 2025, and am looping back to expand on the parts that matter most when putting it into practice.

Define Success First

Before deciding how to build a successful product, you have to decide what success means for this product.

Sometimes the answer is paying customers and profit. Sometimes the product fills a gap in a larger offering, improves retention, solves a costly support problem, or makes another product more useful. Success may mean adoption, ease of use, happier customers, or some combination of those things.

Those products won’t all be built or prioritized the same way.

This matters in hosting because the industry has shifted. Customers increasingly expect a complete solution, not simply space on a server and a list of tools they have to assemble themselves. A host may build a product to generate direct revenue, but it may also build one to help customers succeed, reduce churn, or make the rest of its services more valuable.

Name the intended outcome before debating the features. Otherwise the team may deliver exactly what it planned without knowing whether any of it worked.

Features Aren’t the Product

Imagine you’re building an onboarding flow for a security product.

The feature list might include account creation, domain verification, a scan, an alert, and a dashboard. That’s enough information to describe functionality. It isn’t enough to describe a useful experience.

What does the customer understand when the first alert arrives? Do they know how serious it is? Do they know what to do next? Can they tell whether the problem has been resolved? How much expertise does the product expect them to have?

If you don’t answer those questions, the product will answer them for you, usually through whatever was easiest to implement.

That’s how teams end up with technically complete products that confuse the people they’re supposed to help.

Work From the Outside In

I use a simple sequence when planning a product:

Product planning pyramid showing Experience, Flows, Interface, Design, and Functionality, with an arrow directing planning from the top down.

Engineering may build the pyramid from the bottom up, but product planning needs to move from the experience down.

This isn’t a waterfall process. These layers inform one another, and teams will move back and forth between them. The order is about where the product gets its direction.

A pyramid is normally built from the bottom up. Products often are too. The code, databases, infrastructure, and functionality support everything above them.

Customers experience the other end of the pyramid.

They care about whether the product helps them accomplish something, whether they understand it, and whether using it feels worth the effort or money. The top may be the smallest part of the picture, but it’s the part that gives everything underneath it a purpose.

You may build from the bottom up. You have to plan from the top down.

Experience

Start with the outcome and the customer’s state of mind.

What are they trying to accomplish? What do they know when they begin? What should they understand and be able to do when they’re finished? Where are they likely to be uncertain, frustrated, or afraid of making a mistake?

This is broader than whether the product is pleasant to use. A security customer may need to feel confident that taking action won’t break their site. A hosting provider may need to understand how a product affects support volume before enabling it for thousands of customers.

The intended experience includes the practical and emotional conditions required for the product to be useful.

Flows

Once the experience is clear, map the steps that make it possible.

What starts the process? What decisions does the customer have to make? What information do they need at each point? What happens when something fails?

Flows expose assumptions early. A product that sounds simple in a feature list may require the customer to jump between systems, wait for another person, or understand terminology they’ve never seen before.

It’s much cheaper to discover that while mapping a flow than after building the interface.

Interface

The interface is the set of controls, messages, and information the customer needs to move through those flows.

This is where you decide what belongs on a screen, what needs emphasis, and what can wait. The interface should reflect the customer’s decisions, not the internal structure of the software.

Customers shouldn’t have to understand your architecture to use your product. They have their own work to do.

Design

Visual design gives the interface hierarchy, consistency, and clarity.

It matters. A lot. But visual polish can’t rescue a confused flow, and a beautiful screen can’t answer a question the product never considered.

Design works best when it has a clear job to do.

It also works best when it respects what customers already know. If nearly every table puts search and filtering at the top, that’s where people will look for them. Moving those controls somewhere more creative doesn’t make the product more innovative. It makes a familiar task harder.

There are good places to differentiate. Common interaction patterns usually aren’t one of them.

Functionality

Now the team has enough context to make better decisions about what to build.

Functionality is still critical. The difference is that it now serves an intended experience instead of defining one by accident.

Engineering should be involved throughout this process. Engineers understand the systems, constraints, and opportunities that shape what’s possible. Early technical input can prevent a team from designing an elegant fantasy.

That doesn’t mean implementation should lead the product. Feasibility should inform the experience, not silently replace it.

Build the Team Around the Questions

Different stages require different kinds of depth.

Early on, product, research, design, and engineering need to agree on the problem, the people affected, and the constraints. As the experience and flows become clearer, interaction and visual design can go deeper. As the team moves toward delivery, engineering and quality work naturally expand.

That doesn’t mean each discipline waits outside the room until its turn. Handoffs create their own problems. It means the team’s focus and staffing should match the questions that need answering.

On one product team, our user researcher also served as the UX designer. I owned quality control. Two people divided the UI work between visual design and implementation, a dedicated project manager kept the work coordinated, and a development team built the product with help from other engineers as needed.

That wasn’t the only team structure that could have worked. It fit the product and the people we had. More importantly, the responsibilities were visible. We knew who was learning from customers, who was protecting the intended experience, who was coordinating the work, and who was making it real.

Clarity should drive growth.

Research Has to Become Direction

User research isn’t simply talking to customers.

The harder work is taking what customers say, separating the recurring needs from individual preferences, and turning that information into something a team can use. Good research doesn’t hand engineering a stack of interview notes. It helps the team understand the problem well enough to make decisions.

Research should continue after the first plan. Prototypes, moderated testing, unmoderated testing, and small beta groups can show whether the product works the way the team thinks it does.

Beta groups need care. Participation fades, people get busy, and the group may need to be refreshed. That’s still cheaper than discovering after a broad launch that customers can’t find the thing you thought was obvious.

UX and UI Aren’t the Same Job

UX and UI are often treated as interchangeable labels. I don’t find that very useful.

UX is primarily an advocate for the person using the product. It focuses on research, scenarios, information architecture, flows, wireframes, prototypes, and whether the experience makes sense.

UI turns that structure into the visual and interactive system people will actually use: layout, controls, typography, color, branding, and implementation details.

There is overlap, and one skilled person may handle both. The distinction still matters because a polished interface doesn’t prove that the underlying experience is sound.

Give Quality a Clear Owner

Before the team starts building, decide who has the final say on whether the product is good enough.

Larger teams create plenty of opportunities for individual pieces to be acceptable while the whole product feels inconsistent. Someone needs the authority to say the edges are still too rough, the experience doesn’t match the intent, or the product is ready to ship.

This shouldn’t be arbitrary control or personal taste dressed up as quality. It should be accountability to the experience the team agreed to create.

Project management matters here too. Even a small team benefits when someone owns coordination, documentation, and the reasons behind decisions. That work lets specialists focus on their jobs and gives the team something to return to when the next iteration begins.

Stakeholders and marketing also need to be involved without replacing the customer as the center of the product. Product leadership includes keeping those groups informed, earning the necessary support, and translating their needs into the same set of decisions.

Plan for Change Without Moving Everything

Most products don’t end at launch.

They gain customers, new use cases, new requirements, and ideas nobody had during the first planning session. A team that plans only for version one can paint itself into a technical corner, but architecture isn’t the only concern.

Customers learn where things are.

Moving a familiar control or reorganizing a workflow can frustrate people even when the new design is theoretically better. The team may see an improvement. The customer experiences the loss of something they already understood.

You can’t predict every future feature, and trying to do so will create its own kind of overengineering. You can leave conceptual space for the product to grow. Think about where likely capabilities could fit, which parts of the experience need to remain stable, and how new work can be introduced without forcing customers to relearn the whole product.

Plan for the future without building all of it today.

Must-Haves Before Wow

Every product has a list of features that would be impressive in a demo.

Some of those ideas may become real differentiators. The danger is building them before the product has earned the right to be interesting.

Customers need the basics to work first. They need to understand the product, complete the central task, recover from mistakes, and trust the result.

The “wow” can build loyalty. The must-haves earn trust.

This doesn’t mean innovation always waits. Sometimes the differentiating idea is the simplest route to the customer’s outcome. But when a feature competes with the core experience, the core experience wins.

The balance continues after launch.

Marketing naturally wants visible features it can show in an advertisement, capture in a screenshot, and give customers a reason to talk about the next release. Those features matter.

The product also needs work that won’t earn an exciting announcement: performance improvements, confusing flows that need cleanup, maintenance, and expected capabilities that every credible competitor already has.

In a hosting control panel, activating and deactivating plugins isn’t a headline feature. It’s still something customers expect to be able to do.

On one team, we labeled roadmap work as “wow” or “must-have” and deliberately interspersed the two. The labels weren’t a scoring system. They made the tradeoff visible so the roadmap could keep the product dependable while still giving customers something new to be excited about.

A roadmap made entirely of must-haves becomes stagnant. One made entirely of wow features becomes unreliable.

A Better Starting Conversation

Before creating the feature list, get the team together and answer six questions:

  1. What does success mean for this product?
  2. Who is the customer in this situation?
  3. What are they trying to accomplish?
  4. What do they know, fear, and expect when they begin?
  5. What needs to be true for them to trust the outcome?
  6. How will we know the experience worked?

Then map the flow. Identify the decisions. Bring in the technical constraints. Decide what interface the customer actually needs. Only then turn the answer into functionality.

You’ll still end up with a feature list.

It’ll simply describe a product worth building.

Hanging My Hat at Monarx

I’m excited to share that I’ve joined Monarx as their new Vice President of Product.

For me, this feels like coming home. I’ve spent more than 25 years in the web space and over a decade working directly in hosting. Along the way, I’ve seen firsthand the challenges hosts face when it comes to protecting their customers. Security is hard, and it’s only gotten harder as threats have become more automated, more obfuscated, and more persistent.

That’s why I’m so energized to dig into security again—because Monarx is solving this problem in a way that actually works.

Monarx isn’t just another scanner or add-on. Their platform takes a fundamentally different approach: using AI and code de-obfuscation to analyze how code behaves, not just what it looks like. That means they catch things others miss—including zero-days and hidden attacks—while keeping false positives remarkably low. Even better, they’ve built it to run in the cloud, so it’s lightweight for hosting environments, and it integrates everywhere: Linux distros, control panels, you name it.

From a product perspective, that’s exciting. From a security perspective, it’s a leap forward.

What makes Monarx especially compelling, though, is how they’ve aligned their business with the hosting world. Whether a host wants to save money (through reduced support costs and server overhead) or make money (by selling security directly to customers), Monarx has built the tools, integrations, and even white-glove services to make that possible. As someone who deeply understands what both hosts and end users need, I see the potential here—and it’s big.

My role as VP of Product will be to shape the product strategy, ensure we’re building the right things the right way, and help Monarx continue to lead as the only cybersecurity platform designed for hosting companies and resellers.

It feels good to be back in the trenches of web security—helping solve one of the hardest, most important problems on the internet.

The Introvert Brain

Everyone’s brain, introvert and extrovert alike, has what I call a peak efficiency zone. When your brain is operating in this zone, it’s easy to be productive; you’re motivated, focused, thinking clearly, and getting things done. Your brain is performing like a sports car and using fuel like a subcompact. Everyone has this peak efficiency zone, but it’s not the same for everyone – it’s in a different place, if you will.

Understanding Your Peak Efficiency Zone

For me, this zone often emerges when I’m alone, surrounded by predictable or minimal noise, and reasonably relaxed. Engaging in tasks like planning, problem-solving, or coding allows me to capitalize on this highly productive state.

Others might find their peak efficiency in social settings—perhaps brainstorming with others in a bustling coffee shop, bouncing ideas off each other and feeling inspired. The ideas are creative, high-quality, and coming easily.

Regardless of where you find it, operating within your peak efficiency zone feels invigorating. But what happens when you’re outside of it?

The Stimulation Spectrum

Our peak efficiency zone lies along a spectrum of stimulation, ranging from under- to overstimulated. The optimal point on this spectrum varies for each individual. Notably, introverts tend to find their sweet spot on the lower end, while extroverts thrive with higher levels of stimulation. This isn’t just anecdotal—it’s backed by science.

Under-stimulated

When under-stimulated, you might feel lethargic, unmotivated, or mentally sluggish, even after adequate rest. It’s important to note that it’s not impossible to be productive even when your brain is under-stimulated, it just takes more effort – more energy – to force yourself to get things accomplished in spite of your lack of motivation and seemingly sluggish thoughts.

Over-stimulated

Conversely, over-stimulation can make your mind feel hyperactive yet unfocused. Thoughts race, but none settle long enough to be actionable. Again, productivity isn’t out of reach, but it requires significant energy to channel this mental chaos effectively.

The Neuroscience Behind It!

Obviously we want our brains to be operating at peak efficiency, but how? Understanding how this stimulation spectrum works in your brain is the first step. Our brains are amazingly complex but to simplify it as much as I possibly can, stimulation levels are basically controlled by two chemicals in our brain: acetylcholine and dopamine. Both are neurotransmitters, with dopamine being dominant when we are more stimulated and acetylcholine being dominant when we’re less stimulated. Together they have a heavy effect on the way blood flows through our brains which dramatically affects our ability to be productive.

Acetylcholine: The Introvert’s Ally

Acetylcholine is our brain’s default neurotransmitter, associated with focus and attention. If you’re an introvert like me, you love acetylcholine, even though you likely have never heard of it.

It’s stored in the Laterodorsal Tegmental Nucleus (go ahead, try to say that ten times fast) and travels through the Cholinergic Pathways to various areas all over the brain. For introverts, acetylcholine dominance facilitates deep thinking and sustained attention in low-stimulation environments.

Dopamine: The Extrovert’s Driver

Dopamine, often linked to pleasure and reward, becomes dominant in more stimulating situations. It’s more popular (read: widely known), which seems fitting since it’s an extrovert-favoring chemical. (Although it’s probably most well known for it’s association with addictive drugs and behaviors, which is outside the scope of our interest in it.)

Dopamine is used in various ways all over our body, but what we care most about is that it’s created in the Ventral Tegmental Area, travels through some pathways in the brain, and arrives at the Nucleus Accumbens. This is all part of the “rewards system” in our brains (more on this to come). When the Nucleus Accumbens processes dopamine it stimulates our brains, moving us further up that stimulation scale. And in introverts, who already want to be a little lower on that scale, our Nucleus Accumbens is much more sensitive to dopamine.

Blood Flow

I said that acetylcholine and dopamine have an effect on the blood flow of the brain, and that introvert brains are more sensitive to dopamine. And this is where it gets fascinating. The difference between an introvert and extrovert brain can be physically observed by doctors and scientists! That’s right, it’s not just a preference, it’s an observable difference in your brain!

Lets look at the extrovert first. Imagine an extrovert is relaxed – laying down, listing to calming music, reading, etc – so that the dopamine levels in their brain are low and acetylcholine is in control. A radioactive isotope is injected so that their blood flow can be traced through their brain, and the flow looks something like this:

The flow is fairly centralized. It travels through the areas that control our senses – taste, touch, sight, sound, hearing – as well as the autonomic functions like heartbeat, breathing, etc.

Now imagine an introvert goes through this same test, with the same dopamine levels as the extrovert. The flow of blood would look more like this:

As you can see it flows along a much longer path, flowing all the way out to the prefrontal cortex. Now it’s flowing through the areas of the brain that control empathy, self-reflection, memory, planning, and rational thought. This is what blood flow in a brain is like when your brain is at or near it’s peak zone.

Hacking The Rewards System

Understanding the brain’s reward system—especially how dopamine is involved—gives you more control than you might think. Dopamine plays a central role in motivation. It’s what pushes you to act, nudges you to try again, and gives you that “good job” signal when something goes right. But even though this is part of the “rewards system” it’s not about the actual reward—it’s about the anticipation of reward. Dopamine is released to tell you that a reward is possible and to encourage you to pursue it.

This is where things get interesting for introverts.

Because introverts are more sensitive to dopamine, we’re more likely to push ourselves beyond our peak-efficiency zone in environments where external dopamine cues are loud, rapid, or unpredictable. That could mean a chaotic office, a packed conference, or an overcrowded meeting. These settings might energize an extrovert—but for an introvert, they can quickly become draining.

One of the most important things I’ve learned as an introvert—especially one who genuinely enjoys meeting new people and learning from their perspectives—is this: every time you meet someone, there’s potential for a reward. Your brain recognizes that, and releases a bit of dopamine to encourage the interaction.

So what if you could harness dopamine on your terms?

You can. Once you understand how the reward system works, you can intentionally trigger as much or as little dopamine as you need—rewarding yourself in ways that keep you in your peak efficiency zone rather than pushing you past it.
At a conference, for example, I’ll meet and talk with as many people as I can—because that’s what I want to do, that’s the goal. But I seek out individuals or smaller groups, where the social stimulation is more manageable and the dopamine doesn’t flood in all at once. When I start to feel my energy dip or my focus fray, I’ll step away to somewhere quiet and let my dopamine levels settle. Because I’ve found that a 15-minute break followed by 45 minutes in my peak zone is far more effective than spending a full hour outside of it.

In short: when you understand how the reward system works, you stop hoping that you’ll be “in the zone” and you start navigating yourself into it—deliberately and on your own terms.

Embracing Your Neurological Blueprint

Understanding your brain’s wiring empowers you to create environments and routines that align with your natural tendencies. For introverts, this might mean seeking quiet spaces for deep work, scheduling downtime after social engagements, or engaging in solitary activities that recharge your energy.

Recognizing that introversion isn’t a flaw but a distinct neurological configuration allows you to leverage your strengths effectively. By working with your brain’s natural inclinations, instead of against them, you can better achieve the success you’re looking for.

Understanding and embracing your introverted nature isn’t just about personal growth—it’s about unlocking your full potential.

For a more in-depth exploration of this topic, watch my “Succeeding as an Introvert” and “Leading as an Introvert,”

Looking Back at 2021

Forgive me internet, for I have sinned. It has been 351 days since my last post on here. Here’s a short one on 2021 to try to get me back into the habit.

Last year was one of self-assessment and struggle for me. I’ve heard several people refer to it as a roller coaster, but I love roller coasters and can’t claim the same affection and appreciation for 2021. I can say it had a lot of ups and downs. You could take a graph of weekly average COVID infection rates in my state of Oklahoma, mirror it on the vertical, and relabel it “Aaron’s Mental Health and Happiness”. It would be alarmingly accurate.

While most of the biggest challenges of 2021 were personal for me, professionally there were some significant changes and encouraging progress as well.

Self-Assessment

Starting even before 2021, in the latter half of 2020, I took some of my own advice and sat down to write out what was important to me, what I enjoyed, and, just as importantly, what I didn’t enjoy. It was overdue. I tell people it’s a practice you should do quarterly, yet I hadn’t done it in a year – and so much had changed in that time!

Setting aside the personal and family parts of that list, because those are for me, there were a lot of similarities to years past in the things that were important to me – the open web, making enough money to provide the lifestyle I want for my family, feeling like I make a difference, helping others to succeed beyond just the company I’m at, traveling (I have to admit, I miss this), etc.

Then came the hard part – applying these things to my life to cause changes and bring my life more in line with what I want it to be. I don’t think I fear change, but I’m certainly wary of it. I like to know all the things, and change makes that hard but it was worth it.

The biggest professional change happened very early in 2021. I was tired of pushing so hard to steer a company toward embracing and building on the basic principles of the open web and to drive home the importance of open tooling and standards. Especially as reorganizations began to reduce my ability to effect the change I saw was needed. I don’t think I even realized how exhausting it was or how much it affected my happiness, until I stepped back and eventually left.

I didn’t dramatically change what I was doing, but I moved to a company that sees the importance of the open web as I do. Even considering the massive merger that that birthed Newfold from EIG and Web.com, pushing toward the open web with a company full of people that are pushing the same direction was definitely one of the better parts of 2021.

Exploring Professional Interests

The move to Newfold was strategic for another reason as well – to further distance myself from the “developer” label I’ve long been tagged with. I was absolutely a developer – for many years that was my primary marketed skill and it’s what really kick-started my career and brought me into WordPress. I still write code for personal projects and even professionally from time to time, but it’s been a while since I considered myself a developer. Breaking free of that label has been tough, but I think 2021 finally put that to bed.

There is nothing wrong with being a developer, but the skills I most enjoy employing are guiding products and the strategies around them, bridging the gap between developers and non-developers, and building and maintaining relationships. I’ve spent all of 2021 doing those very things.

I’ve been able to split my time, running product while also being involved in partnerships and acquisitions. I even went to my first ever CaboPress, and I have to say – you’d be hard pressed to find a conference anywhere that better facilitates the building of relationships.

A Happier Path Forward

Looking ahead at 2022 the thing I hope to focus on is personal happiness even with regard to my professional life. There’s a niggling little voice inside me telling me that’s selfish, but I’m working to ignore it. For me personal happiness will mean more time with family, less stress about work, and focusing on continuing to employ and improve the skills I truly enjoy.

Hanging My Hat Somewhere New

Last week was my final week at GoDaddy. It was a little over four years ago, when I joined GoDaddy as a full-time WordPress contributor. I went in with a goal to help make WordPress better, and GoDaddy really empowered me to do that during my time there. It was truly great and I’m going to miss it in so many ways!

What’s Next?

I continue to be passionate about the open web and open source software, like WordPress, as a part of it. I still strongly believe that the internet is the single most effective information sharing tool in all of history, and keeping it open and accessible to all is critical to humanity’s ability to make forward progress. And I’m still as excited as I’ve ever been to be a part of that.

But I’ve also become increasingly focused on the sustainability of the open web and the open products that make it up. If you look at the time and resources required for these things to exist, it’s expensive! Which is why in successful projects like WordPress, we see so many people who are paid in some way or another to work on it. Without those people WordPress would not be where it is.

And it’s good when companies do this as a social good or as something tangentially related to what they do, but I think true sustainability here requires more than that. I want to help companies align their products and services, their success, with the health and success of open source software and the open web. I want to help build symbiotic relationships that bring sustainable, ongoing benefit to the WordPress community and the web as a whole.

Where?

I’m super excited to be joining Endurance and the Bluehost family, to do just this. Endurance has already shown their commitment to the WordPress project and community. I look forward to helping them continue to align with that commitment in an effort to build toward the sustainability of the open web.

HackerOne Update

WordPress officially launched the WordPress bug bounty program on HackerOne May 15 of this year, almost six months ago. The goal was to leverage the tools HackerOne provides to improve the quality and consistency of our communication with reporters, and to reduce the time spent on responding to commonly reported issues in order to free our team to focus more time on improving the security of WordPress as well as our sites and other properties.

Success

Since that launch, we have paid out approximately $14,000 in bounties for thirty-nine unique reports – an average of more than $350 for each valid report – from twenty-two different hackers (researchers). This part is exciting! People are helping keep WordPress secure.

Struggles

It's amazing that we've been able to resolve these valid reports (not all were eligible for bounties, some were sent swag as a thank you), but there's more to the story. Those valid reports only account for roughly 16% of the overall reports. About five out of every six reports are invalid. These invalid reports still take time to process, test, etc.

Time is always valuable, but when working with a volunteer team it can feel even more so. Dealing regularly with invalid reports not only consumes a lot of time, but can also feel extremely useless – like a lot of work for no reason. We need to continue to focus on improving this process, but I'm extremely thankful to the people on the team that work to triage on HackerOne for us.

What Now

I would say that the program has been a success so far, so we want to continue it. We are actively working to address the biggest struggle we face, which are the invalid reports that take up so much time without yielding useful results. HackerOne offers some tools that we're trying to leverage to help.

  • Common responses – building up a repertoire of useful responses that can be easily sent to reporters takes time. We hope this will pay off in future time savings, as we no longer have to write the same basic response over and over.
  • Triggers – these allow us to automatically show one (or more) of our common responses to reporters as "Are you sure?" interstitials, based upon key words in the report. Adding some of these has helped and we hope to build a good collection of them as we go.
  • Reputation – HackerOne has both a reputation and a signal rating for all users. We can limit the ability to submit reports to only hackers with a minimum signal. There is a balance here. We don't want to miss out on valid reports, but we do want to reduce the noise.

We are also working with HackerOne to find other ways to might be able to improve our processes. Stay tuned!

The Open Web Matters

The internet is no longer a toy. It is no longer used only for fun or even simply for research. It is now an integral part of people’s lives, of businesses, and even entire economies. Comedian and science advocate, Bill Nye, was recently speaking about his new show Bill Nye Saves the World. Asked why he thought it was so important, he said:

I want clean water for everyone on Earth; renewably-produced, reliable electricity for everyone on Earth; access to the internet, or whatever the future of electronic information is, so that everybody in the world can participate in taking care of the planet.

Bill Nye to CNN

Water, electricity, and internet. It may sound crazy, but I would argue that the science guy is right. The internet is vitally important to the future of humanity. It needs to be protected, secured, and available. This cannot happen unless it is open.

History

CERN has restored a copy of the 1992 version of the site – the earliest copy researchers at CERN have been able to find.

The internet as we know it started around 1991. Tim Berners Lee, working with CERN, developed HTTP, HTML, and the first ever web browser. The internet was much more academic at that time and looked a lot like the pages of a research paper.

Around the same time, the Commercial Internet eXchange was trying to do something ground breaking. They were attempting to connect the various stand alone networks, mostly US governmental agencies, to allow traffic to be exchanged between them. The controversial thing at the time was that they wanted a no-settlement policy between the groups involved. We take this for granted, expecting to easily access any information or service on the web without caring where or how it’s hosted. Imagine an internet where this wasn’t the case. Where you could only access a small fraction of the available sites and services.

What if Amazon were on one network, Netflix another, Twitter and Facebook still another, and none of those networks would talk to each other without additional usage fees. Your sphere of information available to you would be incredibly different. Drastically limited. This is kind of Internet we could experience if we don’t keep the web open.

History of Modern Humans

Why is this so important? Why should I care?

To answer that we need to look at how the dissemination of information has affected the progress of humanity. Nine hundred years ago, in the early twelfth century, the French philosopher Bernard of Chartres spoke about the fast progress humans were making. He said that the moderns were like dwarves perched on the shoulders of giants (the Ancients) and thus were able to see more and farther than the latter. “And this is not at all because of the acuteness of our sight or the stature of our body, but because we are carried aloft and elevated by the magnitude of the giants.”

Never heard of Bernard of Chartres but the “shoulders of giants” phrase sounds familiar? Isaac Newton said the same thing over five hundred years later.

If I have seen further, it is by standing on the shoulders of giants.

Isaac Newton, 1675

It’s easy to see Isaac Newton as a giant. He gave us calculus and newtonian mechanics. We’ve used these as the basis for calculations to put people on the moon and to build skyscrapers that don’t fall over. The jet engine, a thing that in and of itself has forever changed the world, uses his principles and mathematics. Because people before Isaac Newton shared their knowledge openly with him, he was able to add to it and share that knowledge with future generations, who were able to leverage it to bring the peoples of our world closer in a way they never could have been otherwise.

Where the Danger Lies

Isaac Newton built on the works of those that came before him. Everyone since has built on his works. Shared information make this possible. It is integral to humanity’s ability to make consistent and rapid progress forward. The internet is the single most effective information sharing tool in all of history.

Isaac Newton was able to stand on the shoulders of those that came before him, whose work he had access to. With the internet, access no longer needs to be a limiting factor. Distance doesn’t matter. The implications for the progress of humanity are both serious and exciting!

There are two things that we need to look at to understand the threats against this open dissemination of information that the internet provides – net neutrality and closed systems.

Net Neutrality

What is net neutrality? You hear the term used a lot, especially when people are talking about legislation affecting the internet, but what does it really mean? Net neutrality, or the the Open Internet rules, cover three basic things according to the FCC:

  • No Blocking. Broadband providers may not block access to legal content, applications, services, or non-harmful devices.
  • No Throttling. Broadband providers may not impair or degrade lawful Internet traffic on the basis of content, applications, services, or non-harmful devices.
  • No Paid Prioritization. Broadband providers may not favor some lawful Internet traffic over other lawful traffic in exchange for consideration of any kind—in other words, no “fast lanes.” This rule also bans ISPs from prioritizing content and services of their affiliates.

The dangers of all these really come down to the honesty, integrity, and motivations of the people enforcing these limitations. Blocking bad/inaccurate content or throttling services that are less important to give precedence to ones that are more so, both sound fine – but who makes that decision? What group of people can decide that certain information isn’t accurate? Can that control or influence the thoughts and understandings of whole generations?

Now involve money. What happens when companies are able to pay to control the flow of information? When one drink giant pays to limit access to accurate information about their competitors while spreading inaccurate information? Or when tobacco companies can interfere with the ability of people to discover the actual risks of their products?

Free and open access to information is absolutely critical to our freedom as a people. Taking away people’s ability to make their own decisions, whether by force or by limiting access to information, is wrong.

Closed Systems

Many people easily identify the risks in the loss of net neutrality, but most miss the threat posed by closed systems. A system that you use, feed data into, and rely on that is closed source and owned by a company, is a danger. Whether it’s Facebook, Twitter, or Instagram for your personal data or Shopify, Wix, or Salesforce for your business.

It’s not that these systems are bad, but they are certainly dangerous. When another company owns the platform you rely on, what happens when your goals or needs diverge from theirs? Companies controlling the dissemination of information is dangerous.

What Can You Do?

When net neutrality legislation is on the table, take action! Inform yourself though, not all legislation is good. Spread the word about the dangers of a closed web. Vote with your dollars and your support. Use open platforms like WordPress and encourage others to do the same. Above all else be aware of the danger and watch for it.

Photo credit: Barefootliam.