About

I am Giorgio Alfredo Pagano, a Drupal developer at SparkFabrik. My ground is digital services for Italian public bodies, where the hard part is recognising the person: SPID, single sign-on, identity federation. On drupal.org I sign as sjpagan, and one of the seven modules I look after runs on eight sites today.

What exactly do I work on?

I write software for the web, and for eleven years I have done it mostly with Drupal.

There is a reason for that. Drupal is one of the few content management systems that treats content structure as a contract: content types, fields, roles and publishing workflows are explicit data, kept under version control instead of buried in a template. A public body that has to serve the same data through a portal, an app and an API, and prove on demand that they match, ends up leaning on that explicitness. What looked like a technical detail is what keeps the project standing.

My daily work is content modelling, configuration management, decoupled architectures, migration pipelines and custom module development.

What have I published?

Seven modules on drupal.org, published as sjpagan, and two of them carry most of the weight because they came out of problems I hit myself.

Native Observability (opens in a new tab) brings request tracing inside Drupal: correlation IDs, execution spans, performance metrics, forensic route analysis, and export towards OpenTelemetry, Prometheus and Grafana. It started from a concrete question: why do I have to wire an external APM into every environment just to find out which hook is slowing a page down? As of 20 September 2026: published on 12 February 2026, stable release 2.0.0 dated 17 September 2026, compatible with Drupal 10 and 11, PHP 8.2 or newer, eight sites report using it, and it is covered by the Drupal security advisory policy.

DOC to HTML (opens in a new tab) I have maintained since 2017. It takes a document uploaded through the node form, runs it through LibreOffice, and lands clean HTML in a text field after a pass in CKEditor. Anyone who has worked with a public editorial team knows why it exists: the copy shows up as .docx, and it is going to keep showing up as .docx. As of 20 September 2026: published on 20 January 2017, stable release 2.0.1 dated 2 May 2026, compatible with Drupal 10.1 and 11, PHP 8.1 or newer, three sites reported, covered by the security advisory policy.

The other five are smaller. Style Management, Views Field Percentage, Vsauce Sticky Popup and AI Disclosure each grew out of one specific problem and stayed public because someone else needed the same fifteen lines. Views custom link has a different story: luxx91 (opens in a new tab) created it in January 2019 and I joined later as co-maintainer; fifteen sites use it today, and it is looking for someone to take it over.

A module being covered by the security advisory policy means something precise: if somebody finds a hole in it, there is a formal process to report it and I have committed to answering. That is what separates publishing a module from pushing code to a repository.

What did building for the public sector teach me?

I have worked on platforms for Italian public administration, and it is the context where I learned the most, because it is the place where mistakes are visible.

A public service has an audience that can only use that one site: someone who needs a certificate or has to follow a case has that service and nothing else. That changes the priorities. Accessibility is no longer a compliance checkbox. It decides whether the service exists for everyone or only for some. Digital identity stops being a login screen and becomes the moment the State recognises a person.

The part that involved me most closely is identity federation: SPID, single sign-on, and the integration of systems that authenticated their own way for twenty years and now have to talk to each other. Nobody puts that work in a portfolio, and it forgives very little. An authentication flow has no margin worth the name: it either recognises the right person or you are writing an incident report.

What do 3D printing and FPV drones have to do with it?

More than it looks. Both of them taught me something I now use at work, which is why they are on this page.

I print in 3D on a Prusa. It comes from the RepRap tradition of open hardware: you repair it, upgrade it and modify it instead of replacing it, and you often print its spare parts with the printer itself. It is the same idea that makes me publish modules on drupal.org instead of keeping them in a drawer.

3D printing taught me something software hides well: a wrong tolerance is not negotiable. A part designed two tenths of a millimetre too large stays outside. It does not fit slightly less; it stays outside. And you find out by printing it, waiting two hours and trying to fit it, rather than by rereading the model. Since I started designing parts that have to fit real parts, I have traded mental verification for the habit of measuring before declaring.

I fly FPV drones. FPV stands for first person view: instead of watching the drone from the ground and flying it by sight, you wear goggles that receive the live video from a camera on board. You fly from the drone's point of view. The difference is more than comfort: you are inside the object rather than outside it, and your sense of space and speed changes completely.

That is where it gets instructive for anyone who writes software: latency is a budget, not an adjective. Between what happens in front of the camera and what you see in the goggles there is a delay, and that delay gets spent: in encoding, in transmission, along the radio chain. At that speed the gap between eighty and a hundred and fifty milliseconds decides whether you fly or hit a tree. When I later design a system where a person waits for an answer, that way of thinking stays: never "it is fast", always how much and measured where.

What the two have in common is a feedback loop that refuses to flatter you. The part fits or it stays outside; the drone flies or it drops. You find out the same afternoon. Software is the opposite: a mistake can sit there for months looking like a working system.

How I work

Three habits that hold even when nobody else is going to read the output.

The specification comes before the code. Every change worth the name starts from a document saying why it is being made, what it changes and how you check that it is done. Its value is less in coordination than in discovering, while writing it, that the problem was a different one.

Decisions on the record. Architectural choices end up in a dated register, with the alternatives considered and the expected consequences. The point is not the documentation: it is being able to come back six months later and tell whether a decision was wrong or the conditions had changed. And, now and then, having to write that the data contradicted what was decided.

Measuring instead of assuming. It holds for performance, for costs, and for new tools. A plausible intuition and a recorded number carry different weight, and almost always the number says something the intuition had missed.

How do you check what is written here?

Every claim above can be checked against a source that I do not control, which is the point of writing it this way.

• The profile with the modules, the releases and the dates: drupal.org/u/sjpagan (opens in a new tab)
• The code that lives outside drupal.org: github.com/sjpagan (opens in a new tab)
• The two modules, with adoption figures kept by drupal.org itself: Native Observability (opens in a new tab) and DOC to HTML (opens in a new tab)

The figures on this page were recorded on 20 September 2026. The ones on drupal.org change by themselves: if you find a difference, drupal.org is right.