Svelte Community Architecture

Site: https://svelte.dev

Discord: https://svelte.dev/chat

Git: https://github.com/sveltejs/svelte

Introduction

History/Purpose/Goals

Svelte is a javascript compiler that turns Svelte syntax into frontend javascript. It aims to be substantially smaller and more efficient than other frontend libraries like React or Vue, achieving this through removing a virtual DOM. It has consistently been named the most loved framework in the Stack Overflow developer survey.

First Commit/Most Recent Commit

The first published version of Svelte was released on the 29th of November 2016. Establishing a first full commit date is difficult because the project derives from RactiveJS, and the split date is unclear. The most recent merge was on the 24th of February.

Leadership and Team Structure

Lead Developer

Rich Harris, the original author of Svelte, is the Benevolent Dictator for Life. He started the project while working at the Guardian but now works on the project full-time at Vercel. The project maintainers meet monthly to discuss project direction, but this meeting is closed to the public.

Core Team

The core team has remained highly stable over the history of the project. Rich Harris, the project’s founder, remains its most significant contributor. Some other core contributors, like Alan Faubert, Tan Li Hau, Ben McCann, and Simon Holthausen, have also participated in the project for an extended period.

Unique Knowledge

Rich Harris has unique knowledge. He started the project and remains highly engaged in the direction and development. The project would be unstable if the top 20% of contributors died. It would likely require intervention from a sponsoring company (likely Vercel) to dedicate development resources for the project to continue.

Commit Access

Anyone can file a pull request to have it merged into the project. It must undergo checks from Vercel and be approved by a Svelte maintainer. There are 27 maintainers. All pull requests, including from maintainers, must be approved by at least one other maintainer before being accepted into the core codebase.

Quality Control and Bug Repair

The 27 maintainers take responsibility for the quality control of the project. Anyone can fix bugs by issuing a pull request tied to an issue. However, the maintainers are more likely to be directly involved in the fix for significant bugs.

Front End/Back End

As a compiler, Svelte only consists of a backend. Thus, everyone is a backend developer. The public-facing websites are run under the same structure as the repository itself.

Stability

Calloway Coefficient of Fail

The project has a Calloway score of 40.

+10: Does not build with GNU Make

+10: No mailing list

+10: No per-file licensing

+10: Fork of RactiveJS

Major Bugs

The code is generally well-designed and well-written. There have not been any significant bugs during the development process. They are still in a feature add phase, focused primarily on the SvelteKit framework.

Participation Trends

Based on data in Cauldron, participation is highly volatile, with massive swings in contributions week-by-weekThis is attributable to multiple factors. First, most of the contributors are participating on a volunteer basis. Secondly, multiple projects in the Svelte ecosystem are under development right now. There was a noticeable drop in participation shortly before the SvelteKit framework transitioned from beta to stable, followed by a recent uptick in contributions to the core library. This suggests that most of the energy during this period focused on getting SvelteKit to a stable state rather than updating the core compiler.

BDFL Git-by-a-Bus

If Rich could no longer contribute to the project, it would suffer. The maintainers, and possibly a core sponsor like Vercel, would have to work on returning the project to a stable development pattern. Svelte is used by many companies like 1Password, Alaska Airlines, IBM, Block, and Rakuten, so stability is essential. Thus, there would be much will to get the project back on track, but it would also be much work.

Core 20% Git-by-a-Bus

If the core 20% of the team could not contribute, it would suffer. The top 27 contributors have a large amount of control and domain knowledge. However, there would be a strong incentive from companies to get the project back on track. Vercel, or another sponsor, would likely have to take the project over.

Onboarding and Support

Onboarding Process

There is official onboarding for both Svelte and SvelteKit. There is a simple “Introduction to Svelte” guided onboarding activity and documentation. All guided introductions include start code, line-by-line instructions (with a “Show Me” button), and the result (iFrame, JS output, CSS output). The community also makes many REPLs with more advanced techniques or detailed instructions than the core documentation.

Documentation

The onboarding process is included in the documentation. It is extensive and understandable. It includes code samples and a live testing environment.

Contributing

The project welcomes new contributors. The CONTRIBUTING.md document says that “Contributions are very welcome. If you think you need help planning your contribution, please ping us on Discord at svelte.dev/chat and let us know you are looking for a bit of help.” The Discord community is vibrant and supportive, so someone would likely get assistance there.

Code of Conduct/CLA

There is a CLA, but it is crude: “By contributing to Svelte, you agree that your contributions will be licensed under its MIT license.” (https://github.com/sveltejs/svelte/blob/master/CONTRIBUTING.md) Notably, it licenses the code committed under an irrevocable license rather than having copyright ownership transferred. Notably, the project is under the Open Collective and does not have an independent nonprofit, so copyright transfer is not logistically feasible. While it should not matter, there is some degree of risk due to this structure.

There is a code of conduct (https://github.com/sveltejs/community/blob/main/CODE_OF_CONDUCT.md) based on the Contributor Covenant and the Mozilla Code of Conduct Enforcement Ladder.

Summing Up

Decision-Making Structure

The decision-making structure is consensus-building. They look extensively for user feedback and try to guide based on community sentiment, but ultimately decisions, including project direction, are made in private meetings.

Federation

This project is a federation. It is more structured than a group and less than a stadium. It is highly welcoming to new contributors and lacks formal corporate control, but there are still maintainers who take responsibility for its success.

Should Someone Contribute?

This is a fantastic project for contributions from novices and pros. The community is very welcoming, and many small changes are needed to the project. The Discord server has lots of helpful information for people who want to get involved. Similarly, there is a lot of intensive and unique work in the project that few projects provide, given how rare javascript compilers are. Given how complex some components of the project are, novices may want to avoid some of the compiler internals. Furthermore, additional features may be better served as a library on top of the framework rather than in the compiler itself.

Cauldron Analysis

We used Cauldron to look at commit and author trends. We cross-referenced the list of maintainers with the list of active submitters and found a somewhat substantial overlap. This suggests that many people contribute, but significant contributors account for much of the work. The commit trends are less stable than our stadium report (ASP.NET Core) but are within reason for a federation.