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
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.
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.
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.
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.
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
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.
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.
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
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.
The onboarding process is included in the documentation. It is extensive and understandable. It includes code samples and a live testing environment.
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.
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.
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?
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.