Sebastian Schildt 2026 candidate

Vision

Having done a lot of my Eclipse work while being employed at a big corporation where I was also dealing with legal requirements of OSS and moving our internal processes around those topics forward, I learned the value of the framework Eclipse provides for such endeavours. Clear rules and processes around managing and running OSS projects and generally being a focus point of knowledge around licenses and regulations, help make your internal legal and compliance people sleep better, or rather, motivate them to let you sleep better....

At the same time, working on the KUKSA project, most of my and my team's interactions with Eclipse were the _doing code_ part, after all, we are "code first" and I believe the crucial part for Eclipse is providing a good developer experience and good tooling. If Eclipse feels like 70% paperwork and processes, the motivation of contributors that are not full time paid for their work dwindles fast. Mind you, as Eclipse we did a reasonable job so far. Compared to manually writing (and checking) CQs for dependencies this can now be 90% automated with Dash and the cool mechanization of the Eclipse IP team behind that. At the same time there will be more to do in future, we do not all have perfect SBOMs (my projects don't) and with regulations like the CRA there is surely more to be done. "Ignoring" those aspects is not an option as I think having a low resistance way of using Eclipse software in products by entities that must comply with those rules is one of our strengths.

I am confident Eclipse will be most successful, if we can uphold the Eclipse standards in terms of "trustworthiness" like legal and compliance without hurting developer experience (much). Having moved to a university position, it became even more important to me, to make Eclipse contributions something to be /desired/ and /attainable/ by students, or any proficient or aspiring hacker really. We do this by having cool & relevant projects (check) and making the contribution as low resistance as possible without compromising the "Eclipse Quality".

About the candidate

I have been active in Eclipse first as a contributor and then committer, since around 2017. Currently I also serve as one of the project leads of Eclipse KUKSA. So, I did see, use and experienced all the evolving Eclipse processes around hands-on working on projects firsthand (RIP IPzilla). My project’s tech stacks have always been a bit different from the classic Eclipse projects, as they were always about automotive starting with C++ when it was still uncommon in Eclipse and becoming the ( or one of the ) first Rust projects in Eclipse. Automotive wise I am also involved in other ecosystem parts such as VSS; IEEE-1722 and from the KUKSA project we always have good ties to Linux Foundation AGL activities.

However, when electing me, you would _not_ get an Automotive OEM/Tier representative, as I have recently switched careers, becoming a professor of Embedded Development at Heilbronn University starting from March 2026, which will not change my automotive experience but of course will add more of an academic perspective.

Affiliation