Geeklog 2030: The Next Adventure Starts Now

There are moments in the life of a project when the most important question is no longer:

What should we fix next?

It becomes:

What could this become?

Geeklog has been with us for a long time. It has survived waves of change that completely reshaped the web: blogs, social networks, smartphones, cloud platforms, APIs, mobile-first design, social commerce and now artificial intelligence.

Many technologies disappeared along the way.

Geeklog is still here.

That alone should make us curious about what comes next.

Not because we need to chase every trend.

Not because we need to imitate bigger CMS platforms.

But because the web is changing once again, and this time the change reaches much deeper than design, devices or search engines.

It changes the way people ask, discover, choose and act.

And that opens an exciting question for our community:

What should Geeklog become for the next decade?

The web is moving from pages to intentions

For most of the web's history, we designed websites around pages.

A visitor arrived.

They opened a menu.

They searched.

They clicked.

They read.

Then perhaps they clicked again.

It was the visitor's job to understand how our information was organized.

That relationship is beginning to reverse.

Today people increasingly express an intention:

I want to understand this.

I want to compare these two solutions.

I need someone who can help me.

I want to know what is available near me.

I want to book this.

I want to buy that.

And they expect technology to help them move toward the answer.

The next generation of websites will therefore need to do more than publish information.

They will need to understand what they contain.

What if Geeklog knew what it was publishing?

Imagine an article that is not simply an article.

Geeklog knows that it talks about a place.

A technique.

A person.

A product.

A service.

An event.

A document.

And it knows how these things relate to one another.

Suddenly, a website is no longer a collection of isolated pages.

It becomes a small universe of knowledge.

A visitor reading about a technique could naturally discover the guide that explains it, the video that demonstrates it, the discussion where people share their experience, the professional who provides the service, or the event where they can learn it.

That feels less like navigating a database.

It feels more like exploring.

And I believe that is where Geeklog could become very interesting again.

Our data may become more valuable than our pages

This may be one of the most important ideas for the coming years.

A website has traditionally been designed to display information.

Tomorrow it will increasingly need to expose information.

Not expose private information, of course.

Expose meaning.

A product should be understandable as a product.

A service as a service.

An event as an event.

A place as a place.

Availability should be understandable as availability.

A price should be understandable as a price.

Humans can often understand these things simply by looking at a page.

Machines cannot always do that reliably.

Search engines, applications and AI assistants increasingly need structured information they can query and interpret.

This means that one of the most forward-looking things we can build for Geeklog may also be one of the least spectacular:

a clean, shared way for plugins to describe and expose what they know.

It sounds technical.

But underneath it is something almost philosophical:

Give information a shape, and new possibilities appear.

Store, Services and Booking tell a larger story

This is why the work around commerce should not be seen simply as adding a shop to Geeklog.

Store can be much more than a shopping cart.

Services can be much more than a directory.

Booking can be much more than a calendar.

Together they describe a journey.

Someone discovers something.

They understand it.

They decide they need help.

They find a service.

They check when it is available.

They reserve it.

Perhaps they pay.

The technology should disappear behind that journey.

That is the interesting part.

A training course could be described as a service, scheduled as a booking and paid through Store.

A free consultation might require no payment at all.

A digital book might need Store but no Booking.

Each plugin stays focused.

Together they become something larger.

Good architecture often has that quality.

Small pieces.

Clear responsibilities.

Unexpected possibilities when they connect.

Search could become discovery

Search is another place where we can rethink old assumptions.

Traditional search asks:

Which pages contain these words?

But a visitor may actually be asking:

What should I do?

Which option fits my situation?

Is there something available near me?

Can I calculate this?

Has someone already solved this problem?

A future Geeklog search could look beyond matching words.

It could understand the shape of the question.

Sometimes the best answer would be an article.

Sometimes a forum discussion.

Sometimes a downloadable document.

Sometimes a calculator.

Sometimes a service.

Sometimes a product.

Sometimes the answer might simply be:

Here are the three places on this site that will help you most.

That would turn search into guidance.

Perhaps the next great content type is not content

We have spent decades improving articles.

Better formatting.

Better SEO.

Better images.

Better navigation.

But sometimes another article is not what the visitor needs.

They need a tool.

A calculator.

A simulator.

A comparison.

A diagnostic.

A questionnaire that leads them somewhere useful.

Imagine an ecology site where an article explains insulation and, beside it, Geeklog offers a calculator that helps estimate what the visitor needs.

Or a technical site where a guide naturally leads to a configurator.

Or a professional site where an article becomes the first step toward an assessment.

Content explains.

Tools help people decide.

That combination could be powerful.

Artificial intelligence should arrive last, not first

This may sound strange in 2026.

Everyone is talking about AI.

Everyone wants a chatbot.

Everyone wants an assistant.

But I think the most interesting Geeklog strategy would be to resist the temptation to start there.

An AI sitting on top of badly organized information is still sitting on badly organized information.

Before teaching Geeklog to answer questions, we should help Geeklog understand what it already knows.

Before building agents, we should make actions clear.

Before asking AI to recommend services, we should describe services properly.

Before asking it to find availability, Booking should expose availability cleanly.

Then AI becomes useful.

Not magical.

Useful.

And because the foundations are open, Geeklog does not need to belong to one AI provider.

Today's provider can be replaced by tomorrow's.

The site remains ours.

The data remains ours.

The architecture remains understandable.

Geeklog could become a website that can answer back

Imagine arriving on a Geeklog site in a few years and asking:

I am a beginner. I need a solution for this problem. Where should I start?

Geeklog could guide you through its own knowledge.

It could find the most relevant explanation.

Show a practical tool.

Suggest a document.

Point toward a useful discussion.

Recommend a service if appropriate.

And perhaps later:

There is a workshop next month, 40 kilometres from you. Three places remain.

That is not merely an AI chatbot.

It is the entire website becoming more intelligent because its parts know how to speak to one another.

And eventually, websites may have visitors that are not browsers

There is another change worth preparing for.

Tomorrow, some visitors to our sites may arrive through software agents.

Someone might tell their assistant:

Find me a beginner course on this subject next month.

The assistant searches several sites.

One of them is powered by Geeklog.

If Geeklog can expose its services, locations, prices and availability clearly, the assistant can understand what the site offers.

Perhaps it sends the user there.

Perhaps one day, with permission, it completes part of the process for them.

The important thing is not predicting exactly how agents will work in 2030.

The important thing is ensuring Geeklog is not invisible to them.

This is not a call for twenty new plugins tomorrow

Quite the opposite.

Trying to build everything at once would probably be the fastest way to build nothing well.

The opportunity is to create foundations that make future ideas easier.

A common language between plugins.

Clean APIs.

Useful events.

Structured data.

Simple relationships.

Strong permissions.

Good multisite isolation.

None of these things look spectacular in a screenshot.

Yet they are the roots from which almost everything else can grow.

Store.

Services.

Booking.

Search.

Recommendations.

Marketing.

AI.

Agents.

Different branches.

The same tree.

There is beauty in building the right foundation

Developers know this feeling.

You write a small function.

It has one responsibility.

Its interface is clear.

Another part of the system can use it without knowing how it works inside.

Then another.

And another.

At some point the architecture begins to feel inevitable.

Good code has rhythm.

Good code leaves space.

Good code says enough, but not too much.

There is poetry in that.

Perhaps the same principle should guide the next chapter of Geeklog.

We do not need a giant revolution.

We need pieces that fit.

A clean interface here.

A better abstraction there.

A plugin that does one thing well.

A test that protects a behaviour.

A contributor who sees something the others missed.

That is how mature software moves forward.

A small community can still do ambitious things

Geeklog will never win a race based on the number of plugins or the number of developers.

Fortunately, that does not need to be the race.

A smaller community can build software that is understandable.

Software that remains self-hosted.

Software that respects its users.

Software that avoids unnecessary dependencies.

Software where one person can still understand how an important part works.

There is tremendous value in that.

And participation does not only mean writing thousands of lines of PHP.

Someone can test.

Someone can translate.

Someone can document.

Someone can review an interface.

Someone can report an unexpected use case.

Someone can improve accessibility.

Someone can design.

Someone can challenge an idea before it becomes a mistake.

Someone can simply say:

I operate a Geeklog site, and this is what I will need in three years.

That contribution may influence an API that survives for ten years.

We do not need to know exactly what 2030 looks like

Nobody does.

Some of today's fashionable technologies will disappear.

Some will become boring infrastructure.

Something important will appear that none of us is discussing yet.

That is normal.

The goal is not to predict the future perfectly.

The goal is to keep Geeklog ready for it.

I would summarize that direction like this:

Structure. Expose. Connect. Discover. Recommend. Automate. Act.

Not as a rigid roadmap.

As a progression.

First, let Geeklog understand its own information.

Then let its plugins share it.

Then make it easier to discover.

Then help visitors decide.

Then automate what deserves to be automated.

And finally allow new interfaces — including AI assistants — to act on top of it.

The next chapter can start with something very small

Perhaps Geeklog 2030 begins with a Store API.

Perhaps with a Services plugin.

Perhaps with Booking.

Perhaps with a common entity format.

Perhaps someone joins the discussion and proposes something none of us has considered.

That is the exciting part.

The future does not arrive as a release number.

It begins when a few people decide that something is worth building.

Geeklog has already travelled a long road.

We have inherited years of code, ideas, discussions, mistakes, solutions and experience from the people who built it before us.

Now we have the opportunity to add another chapter.

Not because the web needs another CMS.

But because there may still be room for a CMS that values simplicity, ownership, interoperability and thoughtful engineering.

A CMS that publishes.

A CMS that connects.

A CMS that can increasingly understand what it contains.

And perhaps one day, a CMS that can help its visitors move naturally from a question to an answer, and from an answer to an action.

So here is the question I would like to leave with the Geeklog community:

If we were building Geeklog not only for today, but for the web that is coming, what would you want to help create?

You do not need to build the whole future.

Choose one small piece.

That is how the flame starts.