Funding for architectural review work

[gterzian]

Summary

I would like to ask for funding from our project funds, in a similar vein to Josh's setup, but with a different focus. While one of Josh's stated goals is to focus on helping newcomers to the project, I would want to focus on helping committers improve their architectural awareness.

I am already getting funding from NLnet under a shared grant (omitting co-recipients for privacy), but that covers only a pre-agreed set of work items.

On many days I find that I spend time on things unrelated to the grant. This is often because I spot something related to the architectural integrity of some part of Servo I happen to be familiar with. It is this work that I would like to ask reimbursement for.

In practical terms, the above means that if I were to spend and entire month only working under the umbrella of the NLNet grant, the cost under this request for that month would be zero. I do expect to spend some time every month on work outside of the scope of the NLNet grant.

I'm not sure how many hours I could be doing this a month; I think it could vary quite a bit from month to month. I propose a cap of 18 hours @ 150 USD per hour.

Type

Reimbursement for time/resources

Cost

upt to 2700 USD a month

Periodicity

Recurring monthly payment

Benefits

Help ensure architectural integrity of code both within components and system-wide. Coach the next generation of committers on architectural matters.

Risks

A growing community of contributors needs the support of reviewers with architectural experience, otherwise there is a risk the project becomes harder to maintain over time.

Alternatives

I could focus my time on items funded under the current NLnet grant only.

This would align work with funding, but carries a risk for the health of the project since it would remove a source of architectural review for areas of the project not covered by that grant.

Administrator

No response

Experience

For nearly a decade, I have been involved in the implementation of:

• Web messaging
• Fetch
• HTTP caching
• Structured cloning and transferring
• The background hang monitor
• Streams
• Event-loops and task queues
• Web workers

My work solved major architectural problems, enabled the implementation of additional standards by others, and so far has stood the test of time.

I provide two examples below.

---

Example 1: Message Ports

Implementing message ports was an early goal of Servo but several attempts had failed to resolve the architectural problem of cross-process transfer of message queues (see this discussion). My implementation in 2019 solved the problem, and is currently still shipped in Servo.

In 2025, the five year old implementation provided the foundation for an advanced feature of streams: transferability.

---

Example 2: Sreams

In 2020 I did some initial work using Spidermonkey's implementation of readablestream, and integrating it not just in script but also in the fetch architecture.

In 2025, under the umbrella of a previous NLNet grant, the by then deprecated Spidermonkey implementation was replaced in favor of our own implementation in Rust, which integrated with the existing fetch infra from the previous work without problem.

Myself and a co-grantee, as well as other contributors, also ended-up implementing almost the entirety of the Streams spec, which in the same year enabled others to implement both compression and text encoding; features based on two other standards that extend streams.

The contributor of the compression work noted the below:

The stream work provides a great foundation for implementing this API. The TextEncoderStream and TextDecoderStream implementation also serve as good references for me. It turned out to be easier than I expected. (Source: servo/servo#39658 (comment))

Other comments

Some example review work from the past month that are good example of stuff I think could be in the scope of the requested funding:

• Reviewing a change in the image cache which I identified as impacting previous work in adding a caching mechanism for ImageKeys
• Triaging a new failure in clean-shutdown, and reviewing the fix.
• Spotting, triaging, and reviewing various inconsistencies in the evolving fetch implementation and its integration with script.

[glyn]

This architectural review work looks valuable. I think it should include documenting, e.g. in the Servo book, those aspects of the architecture which are touched on by review work and which are not already covered adequately. The resultant docs would be very useful for newcomers, other committers, and posterity.

[jschwe]

In practical terms, the above means that if I were to spend and entire month only working under the umbrella of the NLNet grant, the cost under this request for that month would be zero. I do expect to spend some time every month on work outside of the scope of the NLNet grant.

I think to keep transparency, it would be good to include a monthly check-in like josh, but with an NLNet section, and a different section for the architectural work under this project.

Since we are quite close to using all our monthly budget, I'm a bit ambivalent here - but leaning towards supporting your proposal, but perhaps with a clause that if the financial situation worsens (which hopefully won't happen) the project could be dropped.

[mrego]

A quick review about the numbers on Servo's money.

• Open Collective money: 70,500 USD
• We're getting: 7,110 USD/month
• We're spending: 5,275 USD/month

With this proposal, we'll be spending: 7,975 USD/month. With current donations we'll be using 865 USD from the savings each month.

[mrego]

Per discussion on the TSC we're going to approve this but with a reduced amount, 12h/month to stay within the money we're getting as donations.

As we have a 3 month trial period we'll revisit the this when the time comes, and if the donations situation has improved we can decide to increase it to the original request.