Who Created and Owns WordPress? A Business Guide

“Who WordPress” is usually shorthand for several practical questions: who created WordPress, who owns it, who runs WordPress.org and WordPress.com, and who should a business hire to build or maintain a WordPress website. The direct answer is that WordPress began in 2003 with Matt Mullenweg and Mike Little, the open-source software is developed by a global contributor community, the WordPress Foundation protects key trademarks, and Automattic operates the separate WordPress.com hosted service.

That distinction matters for Indian and global businesses because the name “WordPress” can refer to different entities. It may mean the free open-source content management system available through WordPress.org, a website built with that software, the WordPress community, or the commercial WordPress.com hosting service. Confusing these can lead to unsuitable hosting choices, unclear ownership, unexpected plugin limitations, weak maintenance arrangements, or contracts that leave a supplier controlling critical accounts.

For a founder, ecommerce manager, marketing leader, procurement team, or enterprise technology department, the more useful question is not only who WordPress belongs to. It is also who will be accountable for discovery, design, development, content migration, integrations, security, performance, testing, launch, maintenance, and handover. A capable provider should explain the selected architecture, identify third-party dependencies, document scope and exclusions, protect administrator access, and leave the customer with usable records and ownership.

This guide explains WordPress governance in plain language and then turns that knowledge into a practical buying framework. It covers WordPress.org versus WordPress.com, open-source licensing, the roles of the Foundation and Automattic, when WordPress fits a business, how to compare a freelancer, agency, in-house specialist, or managed team, and what an Indian business should verify before starting. Where additional capability is needed, Rudrriv development support can help with requirement discovery, defined projects, dedicated professionals, ongoing support, and managed delivery.

Quick Answer: Who Is Behind WordPress?

WordPress was started in 2003 by Matt Mullenweg and Mike Little as a fork of b2/cafelog. Today, the open-source WordPress software is developed by a global community of contributors and is distributed under the GNU General Public License. The WordPress Foundation protects the WordPress and WordCamp trademarks and supports the project’s open mission.

WordPress.com is different. It is a hosted commercial service operated by Automattic. A business can therefore use WordPress without buying WordPress.com, usually by installing the open-source software on a hosting provider of its choice.

Before commissioning a website, decide which model you are buying, who controls the accounts, who maintains the technology, and who is responsible for testing, security, backups, licences, revisions, deployment, and handover.

Key Takeaways

• WordPress is open-source software: it is not owned as a conventional proprietary product by one web agency or hosting company.
• Matt Mullenweg and Mike Little started WordPress: the first public release arrived in 2003.
• WordPress.org and WordPress.com are different: one represents the open-source project and resources; the other is a hosted service operated by Automattic.
• The WordPress Foundation protects key trademarks: trademark ownership is different from ownership of the open-source code.
• Your business should own its website assets: keep control of the domain, hosting, administrator accounts, content, analytics, backups, and paid licences.
• Provider choice depends on delivery complexity: use a freelancer, agency, dedicated professional, or managed team according to the scope and governance needed.
• Launch is not the finish: WordPress requires updates, security monitoring, backups, performance checks, and planned maintenance.

What This Page Covers

• Who created WordPress and how the project began.
• Who owns or governs the software, trademarks, and hosted services.
• The difference between WordPress.org, WordPress.com, Automattic, and the WordPress Foundation.
• Who should use WordPress and when another platform may fit better.
• How to choose a WordPress developer or delivery model in India.
• What to include in scope, pricing, security, ownership, and handover terms.
• How Rudrriv can support a WordPress project or managed website programme.

Table of Contents

1. Basis and trusted sources
2. Who created and owns WordPress
3. Who should use WordPress
4. WordPress delivery models
5. Planning and provider selection
6. Freelancer vs agency vs managed team
7. Scope, pricing, and timelines
8. Quality and handover
9. Mistakes to avoid
10. Final checklist

Basis and trusted-source approach

This guide is based on official information from WordPress.org about the project, the official WordPress history, the WordPress licensing and features overview, the WordPress Foundation trademark policy, and WordPress.com information about Automattic. It also uses practical project-planning, provider-selection, security, ownership, and delivery-management considerations.

Platform features, hosting plans, software versions, plugin compatibility, commercial pricing, and contributor roles can change. Verify current information through the relevant official documentation and confirm project-specific obligations in writing.

Who created WordPress, and who owns it?

WordPress was created by Matt Mullenweg and Mike Little in 2003, but the software now operates as a community-developed open-source project rather than a conventional product owned and controlled by one company. The original project grew from b2/cafelog, and thousands of contributors have since shaped code, documentation, translations, design, accessibility, support, testing, and releases.

The four entities businesses commonly confuse

• WordPress software: the free, open-source CMS distributed under the GPL.
• WordPress.org: the project website providing software downloads, documentation, themes, plugins, contributor resources, and community information.
• WordPress Foundation: a nonprofit organization that protects WordPress-related trademarks and supports open access to the software.
• WordPress.com and Automattic: WordPress.com is a hosted service, and Automattic is its parent company.

These entities are connected historically and operationally, but they are not interchangeable. The practical consequence is that a self-hosted WordPress website can be hosted with many providers and developed by many independent specialists. A WordPress.com website is delivered within the commercial service and plan structure of WordPress.com.

Who should use WordPress for a business website?

WordPress is suitable when a business needs flexible content management, broad integration options, control over publishing workflows, and access to a large ecosystem of themes, plugins, developers, and hosting providers. It can support simple corporate sites as well as complex publications, ecommerce stores, membership systems, learning platforms, and multi-site programmes.

Good-fit situations

• Marketing teams need to publish and update pages without developer involvement for every change.
• A company requires custom forms, CRM connections, analytics, multilingual content, or structured landing pages.
• An ecommerce business needs WooCommerce or another integrated commerce approach.
• A publisher or knowledge organization manages frequent articles, categories, authors, media, and search.
• An enterprise needs multiple sites with common governance but local content ownership.
• A service business wants a scalable foundation for SEO, lead generation, and ongoing content.

When WordPress may not be the best first choice

Another platform may be better when the primary requirement is a highly specialized software product, real-time application, intensive transaction engine, or tightly controlled hosted environment with minimal technical ownership. The decision should follow a requirements assessment rather than popularity. Compare functionality, security, integrations, performance, editorial workflows, internal skills, vendor dependency, total cost, and long-term change needs.

WordPress services and engagement models

The right WordPress engagement model depends on whether the business needs one clear deliverable, embedded capacity, recurring maintenance, or an accountable cross-functional team.

A provider should recommend the smallest model that can responsibly meet the requirement. That is usually more useful than forcing every website into the same package.

Step-by-step guide to plan and start WordPress work

Step 1: Define the website outcome

State whether the project must generate enquiries, sell products, publish knowledge, support members, serve partners, or replace an outdated platform. Define target users and the actions they should complete.

Step 2: Inventory the current environment

Record the domain, hosting, WordPress version, theme, plugins, custom code, integrations, analytics, backups, traffic, content volume, administrator users, licences, and known issues.

Step 3: Write a requirements brief

List required page types, features, integrations, content responsibilities, languages, accessibility expectations, security needs, launch date, budget range, and internal approvers.

Step 4: Choose the technical approach

Decide whether to use a standard theme, custom theme, block theme, page builder, headless architecture, WooCommerce, multisite, or another pattern. Require the provider to explain trade-offs.

Step 5: Shortlist relevant providers

Compare experience with similar website types, not only generic portfolios. Ask who will actually work on discovery, design, development, QA, migration, and support.

Step 6: Request a detailed statement of work

The scope should specify deliverables, milestones, assumptions, exclusions, revision rounds, client dependencies, testing, deployment, training, documentation, warranty, and maintenance.

Step 7: Review ownership and access

Keep the domain, hosting, administrator account, analytics, payment gateway, email, backups, and licences under business control wherever practical.

Step 8: Plan quality assurance

Agree testing for functionality, browsers, devices, forms, checkout, performance, security, accessibility, redirects, analytics, and content accuracy.

Step 9: Launch through a controlled process

Use a staging environment, approved backup, deployment checklist, rollback plan, DNS coordination, monitoring window, and named launch decision-maker.

Step 10: Complete handover and maintenance

Receive credentials, code, source files, licence records, documentation, training, backup confirmation, open-issue list, support contacts, and update schedule.

In-house vs freelancer vs agency vs managed team

Choose the delivery option by scope breadth, continuity, coordination needs, and accountability rather than by label alone.

A hybrid model is common: an internal owner controls priorities while an external team supplies design, development, testing, and specialist support.

Scope, pricing, timelines, and communication

WordPress pricing should be tied to a written scope because two websites with the same page count can have very different complexity. A five-page corporate site built from an established design system is not comparable to a multilingual ecommerce store with subscriptions, ERP integration, customer accounts, custom search, migration, and high traffic.

Main cost drivers

• Discovery, user journeys, information architecture, and content planning.
• Custom UI design, reusable blocks, responsive behavior, and accessibility.
• Theme or plugin selection, custom development, API work, and integrations.
• Content writing, editing, media preparation, and migration.
• WooCommerce, payments, tax configuration, shipping, subscriptions, and product data.
• Performance optimization, security hardening, backups, monitoring, and hosting.
• Browser, device, functional, accessibility, regression, and acceptance testing.
• Training, documentation, launch support, warranty, and ongoing maintenance.

For Indian procurement, compare whether quotations include GST, third-party licences, hosting, premium plugins, stock assets, payment-gateway fees, content entry, migration, testing, and post-launch support. Use milestone payments linked to accepted outputs rather than vague percentages of completion.

Timeline planning

A realistic schedule includes discovery, content readiness, design review, development, integration access, migration, testing, revisions, stakeholder approval, and deployment. Delays often come from missing content, slow approvals, changing requirements, or unavailable third-party credentials. The provider should identify these dependencies before committing to a date.

How to verify quality, ownership, and handover

Quality is verified through agreed evidence, not through a demonstration that only works on the developer’s device. Each milestone should have acceptance criteria and records.

• Review the site on approved browsers, screen sizes, and devices.
• Test all forms, emails, search, login, checkout, payment, account, and integration flows.
• Run performance checks using representative pages and realistic hosting.
• Confirm redirects, metadata, indexability, sitemap, analytics, consent, and Search Console setup.
• Review administrator roles, plugin sources, update status, backups, security controls, and recovery procedures.
• Check accessibility fundamentals, keyboard use, labels, headings, contrast, and alternative text.
• Verify ownership of domain, hosting, code, content, media, licences, analytics, and third-party accounts.
• Receive deployment notes, architecture summary, maintenance schedule, training, credentials, and open-issue register.

For ongoing support, agree reporting on updates applied, backup status, security events, uptime, performance, resolved requests, pending risks, licence renewals, and planned improvements.

Common WordPress mistakes to avoid

• Confusing WordPress.org with WordPress.com: compare control, hosting, plugins, code access, and service responsibility before choosing.
• Buying by visual mock-up alone: a polished design does not prove performance, accessibility, security, maintainability, or integration quality.
• Using too many plugins: every plugin adds maintenance, compatibility, security, and performance considerations.
• Allowing supplier-only ownership: critical accounts should not depend on one provider with no documented transfer process.
• Skipping staging and backups: updates and launches should be tested and reversible.
• Ignoring content readiness: missing copy, product data, images, and approvals often delay delivery more than coding.
• Accepting unlimited-scope language: define features, revisions, exclusions, and change control.
• Treating launch as completion: plan updates, monitoring, backups, licences, security, performance, and improvements.

Three practical WordPress examples

Indian professional-services firm

The firm wanted a modern website and selected a provider mainly on price. The quote excluded copy migration, CRM form integration, speed work, and post-launch support. The correct approach was to define lead journeys, page templates, content ownership, integration requirements, testing, and a support period before comparing proposals. A defined project with documented handover reduced ambiguity.

Growing ecommerce company

The company assumed “WordPress” automatically meant a standard website. Its real requirement involved WooCommerce, inventory synchronization, payment gateways, shipping logic, coupons, customer accounts, analytics, and peak-load readiness. The correct plan separated commerce requirements from presentation, tested third-party integrations, assigned product-data ownership, and established rollback and monitoring. A managed team was more suitable than a single generalist.

Enterprise content migration

A department needed to move thousands of pages from a legacy CMS. The common mistake was to treat migration as copying text. The correct approach mapped content types, URLs, metadata, redirects, authors, media, permissions, accessibility, analytics, and approval workflows. Specialist development, content migration, QA, and SEO coordination were required, with milestone verification and a detailed handover.

Who WordPress project checklist

• Confirm whether the requirement is self-hosted WordPress, WordPress.com, WooCommerce, multisite, or another architecture.
• Document business goals, users, page types, features, integrations, content, languages, and accessibility needs.
• Identify the client project owner, technical owner, approvers, and content contributors.
• Verify the named delivery team and relevant experience.
• Require a detailed statement of work, milestones, assumptions, exclusions, and revision rules.
• Keep domain, hosting, administrator, analytics, payment, and backup control with the business.
• Agree security, data access, plugin selection, update, backup, and incident procedures.
• Define testing, acceptance, deployment, rollback, training, warranty, and maintenance.
• Record ownership and licensing for code, design, content, images, fonts, themes, plugins, and services.
• Complete handover with credentials, documentation, source files, renewal records, and open issues.

How Rudrriv can help

Rudrriv can support businesses that need WordPress development capability, dedicated specialist talent, or a structured outsourcing engagement. Depending on the requirement, support may cover discovery, design, development, migration, WooCommerce, integrations, testing, performance, maintenance, or managed delivery.

The best starting point is a concise brief and an honest assessment of internal capacity. A small defined project may be sufficient for a clear website build. A dedicated professional may suit an ongoing backlog. A managed team may be more appropriate when design, development, quality assurance, content migration, project management, and support must move together.

Summary: Who WordPress refers to and what businesses should do

WordPress was started by Matt Mullenweg and Mike Little, but today it is a global open-source project developed by a broad contributor community. The WordPress Foundation protects important trademarks, while Automattic operates WordPress.com as a separate hosted commercial service. Understanding these distinctions helps a business choose the right platform model and avoid assumptions about ownership, hosting, support, or control.

For a website project, focus on the practical decision: define the scope, select a provider with relevant capability, agree the timeline and communication process, protect accounts and intellectual property, set quality and revision controls, verify deployment, and complete a documented handover. Internal delivery may be enough for a small, well-understood site. Specialist, agency, dedicated-professional, or managed-team support becomes useful as complexity, integrations, risk, and delivery volume increase.

“At Rudrriv, we make it easier for businesses to access the right expertise, execute important work, and scale with confidence.”