I have read your proposal, and it seems that you intend to make cuts to the existing Dubbo modules. This is certainly a good idea, but they are tightly coupled, and I don't think this will be an easy task. Perhaps it would be better if we completely refactor a new lightweight RPC core module?
RAGIRI Naga sunoj <[email protected]> 于2026年3月30日周一 16:44写道： > Dear Dubbo Developers and Mentors, > > My name is Sunoj Ragiri, and I am a Computer Science student writing to > formally submit my proposal for GSoC 2026: *Apache Dubbo — Lightweight > Refactoring*. > > After conducting an in-depth study of the Dubbo 3.3 codebase, I have > identified a critical "core tension" where the framework's organic growth > into 99+ Maven modules has led to significant dependency bloat. Currently, > even a simple RPC consumer pulls in approximately 15 MB of shaded JARs and > over 100 transitive artifacts, including 6 metrics modules and Prometheus > integrations as hard compile-scope dependencies. > *Project Overview* > > My project aims to transform Dubbo into a truly lightweight, cloud-native > framework through a systematic refactoring of the dependency graph. Key > objectives include: > > - > > *Decoupling Observability*: Moving metrics and tracing from > compile-scope to optional dependencies using a new MetricsBridge SPI in > dubbo-common. > - > > *Lazy Initialization*: Deferring non-critical startup work, such as > TypeDefinitionBuilder and MetricsReporterFactory, from eager bootstrap > to first-use loading. > - > > *dubbo-minimal Profile*: Creating a new distribution module that > delivers core RPC functionality in under 5 MB with fewer than 30 > dependencies. > - > > *Performance Benchmarking*: Providing quantitative proof of improvements > in JAR size, startup time, and memory footprint. > > *Technical Strategy* > > I plan to leverage Dubbo’s existing ExtensionLoader and the > @Activate(onClass > = "...") annotation. This allows us to move coupling from compile-time hard > dependencies to runtime SPI discovery, ensuring that observability features > only activate if the relevant JARs are present on the classpath. > *Timeline & Availability* > > I have outlined a detailed 13-week execution plan, starting with a > comprehensive dependency graph analysis and ending with the final > dubbo-minimal artifact and architecture documentation. I am available to > contribute approximately 29 hours per week throughout the coding period. > > You can review my full proposal here: > > https://drive.google.com/file/d/1_SKEgxDNwmFYgwt7JJbMaOSeuKm14hPR/view?usp=sharing > > I would greatly appreciate any feedback or guidance from the community > regarding this proposal. > > Best regards, > > Sunoj Ragiri GitHub: sun-9545sunoj <https://github.com/sun-9545sunoj> >
