Hacker News Reader

Completely agree. Be 100 percent of what some small set of users needs and you will have a small happy user base which may lead to some new contributors. Do 95 percent of what a lot of people need and you will have zero users that are completely satisfied and they will all use something else.

Then look for use cases that are 95 percent complete and work on that last 5 percent. Then you've got a second set of happy users.

Taking this same approach with an intern at work. He's there for 9-10 weeks. We have an ancient piece of software that requires ancient hardware to run. I told him to make a replacement good enough for one specific guy to use full time. If we can eliminate one users dependence on the old junk it will still save hardware costs, and after the intern is gone, I'll be able to do incremental improvements for the other users until it gets done. Without that one user, there will be zero incentive to maintain it after my intern is gone.

What minimal use-cases does servo handle well today?

At the very least it needs a better plan than "don't let it die".

An exception to what you're saying is Blender by the way, the early (open source) history is a bit sketchy beyond the €100,000 they raised to get the rights (in 2002, well before Kickstarter "crowdfunding"), but I always had the impression what they did right was focus on funding for full-time devs right from the start.

Blender in general is a great open source success story probably not told often enough, probably because 3D is something most of us never really do. It's probably worth examining what they did right in some more detail.

I've always felt like a big part of Blender was having an interface that's awesome for power-users, but that's unusable without training. Then have a foundation that offers said training (some free, some paid), and from that money pay development, outreach and showcases (Blender Open Movies).

It's a somewhat unique (and likely unintentional) model that worked because the competition was very expensive, but it has also prevents Blender from being more than a niche product.

I used some Blender back in the day, over 10 years ago. At the time, I didn't find it too hard to learn and use, but I don't know how much it changed since. Of course it takes time, but I'm not sure if it's harder than similar 3D modelling tools? I also tried some 3D max and Lightroom in those days and they weren't exactly easy to use either. I mean, these are tools aimed at 3D artists (professional or amateur) and very much expert tools never designed to be used by "the average Joe".

That changed with Blender 2.80, which was an incredibly successful achievement. I'd say the interface is one of the most beautiful and pleasant I've ever used for a pro tool. It really ticks every usability box and it looks damn good too. That's not by chance that after 2.80 Blender has been getting more and more momentum. The amount of features that are packed into each point release would constitute a major release in other paid suites. So, yeah, the Blender future is bright and I wish more opensource software managed to replicate their success. I know Krita is following in their footsteps, and also successfully.

Perhaps a Patreon-style funding for Servo could work? Something similar to what the guy behind Serenity OS managed.

UI that's incomprehensible even to the people of closely related professions is more or less the norm for 3D-modelling software. Blender is not even the worst, there are lots of pretty expensive commercial editors out there that are worse (take a look at ZBrush for example).

The problem is that embedding servo is not that easy. This is the only info I found on it:

https://github.com/paulrouget/servo-embedding-example

And it is a 4-year old example.

This, from the same author, is also abandoned: https://github.com/paulrouget/servo-embedding-api

https://github.com/servo/servo/issues/18479

I don't think that embedding is their focus at all, although it does sound like a killer feature to keep the project alive.

Embedding really could help - there is really not much choice now for reasonably modern embedded engine.

Most of the website forks are AFAIK not very maintained, chromium/blink is hard to build and massive and Gecko basically has no embedding interface whatsoever.

So a reasonably complete modern web engine that is reasonably easy to compile and has a stable embedding API could be very welcome.

I still have nightmares from when I had to integrate CEF with a game engine.

> So a reasonably complete modern web engine that is reasonably easy to compile and has a stable embedding API could be very welcome.

Depends on what you mean by "reasonably modern". Sciter could be just what you need: https://sciter.com

> Take embedding as an example. If Servo became a great choice for embedding (similar to WebViews, Electron or maybe as an "engine" to Electron), where there is usually a single set of CSS and Javascript that it's expected to run (basically a bundled app), the downsides of Servo not supporting all Web APIs, or not handling all edge cases, is reduced. Basically, if it runs your code, that's enough.

Could also become a way to do proof of concept new DOM ideas if the API allows for custom tags, JS features, etc.

I would love to see a company backing Servo that isn't Mozilla considering all the downfalls of Mozilla with funding their amazing projects. Their biggest legacy is Rust atm and they're missing out lots of opportunities: paid for IDE with RAD capabilities, certificates for Rust, and many more that could more than fund: Mozilla Firefox, Servo, and Rust itself.

> I would love to see a company backing Servo that isn't Mozilla considering all the downfalls of Mozilla with funding their amazing projects. Their biggest legacy is Rust atm and they're missing out lots of opportunities: paid for IDE with RAD capabilities, certificates for Rust, and many more that could more than fund: Mozilla Firefox, Servo, and Rust itself.

At the moment I can't really say if Mozilla management

- considers themselves paid by Google to run Firefox into the ground and give it an honest attempt

- or if they are just clueless

- or if I am clueless.

Sad to say all the three above seems realistic at the monent.

I would of loved to see from Mozilla in order to fund Firefox:

An email service, having an @firefox.com email would of been great, maybe they should of bought FastMail long ago, I would of loved to see a fully paid for mail service.

A search engine you pay for.

Maybe a small subscription fee for MDN to keep it maintained and its maintainers paid.

FWIW this is exactly the reasoning behind shifting Servo to VR (where it lived until the VR program was also cancelled), with the idea it could target somewhat bespoke environments where developers could design around any missing functionality.

It's very possible that if they picked a niche besides VR that it could have worked, or could work still, but it doesn't feel like good odds...

We still really need a good cross-platform VR browser. Firefox Reality is still the only decent browser for some headsets.

Another niche would be a browser that can embed nicely in Unity apps. I need one right now and there's no decent open source option other than a poorly maintained and fiddly servo distribution/port (I can't remember which). A bit of polish there would go a long way.

This is true, and could keep it going while it builds momentum.

I was thinking the same thing about an embedded browser.

Embedding in places where speed is needed but accommodations could be made where things are incomplete could work too, i.e. in games or rendering UX for video or music programs.

I guess it goes back to 'scratching an itch' when it comes to hobby contributions to open source. It's easy to contribute to something that solves one's own problems - and if the maintainer abandons it, someone else can fork and maintain it to fulfill their need.

But for projects set up by corporations, geared towards large scale problems, it would be difficult to keep them alive by random drive-by contributions from individual contributors.

Maybe what might save Servo is a company seeing a business opportunity by using it, like what happened with Firefox OS, or perhaps being adopted as something like a research project at a University department.

It doesn't need to target Embedded alone, it could simply be an intentional subset of the web standards, with omissions like the browser history API, among many others.

We need Javascript, but we need to control it better.

I think it should be used to make a pure-Rust Tor Browser, since Rust memory safety is essential to preserve anonymity and there are already expectations that full web functionality isn't be available.

Excellent take!