Tuesday, August 30, 2022 - 06:00
  • Share this article:

At a Glance:

  • Involved in open source since: 2015
  • Works for: Self-employed
  • Eclipse Foundation contributor since: 2015
  • Involved in: Eclipse Californium CoAP Framework, Eclipse tinydtls, Eclipse Wakaama
  • Committer to: All of the above
  • Eclipse Foundation committer since: 2015

Can you tell us a little bit about your background as a developer and with open source?

I started in school about 40 years ago actually, where I was just writing some basic programs. It was, in fact, the BASIC  programming language on the Commodore 64. 

As for open source, I probably first started using open source software with the first C compiler back in the early 1990s. My first contributions didn’t come until I was working for Bosch in 2015. So, by that point, I already had a lot of experience with open source software. 

And can you elaborate a bit on your involvement with the Eclipse Foundation?

My involvement with the foundation initially came out of my work with Bosch, with the Eclipse Wakaama project, in 2015. They asked me to get involved there. It was a gradual process: I started by asking questions, before making contributions. It was a very open and productive way to get involved, and after a few months, they asked me if I wanted to become a committer. 

From there, I got involved in a few other projects as well, including Eclipse Californium in 2017, and Eclipse tinydtls this year. Most of my work these days is with Californium and tinydtls – they’re probably where I’m most active. I do sometimes help out with some of Californium’s upstream projects, like Eclipse Hono and Eclipse Leshan, especially if there’s an update from Californium which needs work. 

What have you liked the most about being a committer?

For me, it’s been the fact that I’ve been able to see and participate in these projects over the long term. It’s been very nice to see how well things work and change over time, what could be achieved, and how it could be made sustainable. So, for me, that’s one of the coolest elements of working in open source: someone else can carry on work I started, or the other way around. 

What about the challenges – what have the biggest challenges been?

Well, sometimes being a committer requires you to go beyond the coding, or looking at the code, or helping people with their code. You do sometimes have to get into legal stuff, which is not my domain. 

It also sometimes happens that you get involved with long-term projects that don’t ultimately go anywhere. I did some work trying  to publish an enterprise client, and it was a long road. It didn’t end up happening, for reasons that, I think, had nothing to do with the client itself. And that’s fine, but you’d obviously prefer to know that sort of thing ahead of time, which you won’t always. 

It's also the case that you often end up doing several different things in parallel, which can be challenging. Sometimes you get overloaded, and it ends up being too much. 

Any advice for someone considering becoming a committer?

Well, having been a committer for over five years, I’ve realized that there are a lot of levels of involvement. The very first level is just showing your interest. A lot of people take open source work, say “hey, cool, works for me,” and don’t even give any feedback. So, really, the first level of engagement is just writing a nice message saying it’s great work, or maybe even that it’s not-so-great work. 

On top of that, you can report errors or ask for enhancements; whatever shows that you’re interested. Then, yes, of course we’re happy to have contributions, and I highly recommend becoming a committer eventually. 

But becoming a committer is something that your employer needs to support. Working on problems related to specifications, to processes, to interoperability just takes up too much of your time to do it in your free time or on weekends. 

What’s next for you? What are you currently working on?

Right now, I’m looking to work more on the end-user experience. So, Californium and tinydtls are more basic libraries that you can use to build something that’s more directly useful. I’m looking to close this gap. So, I published the SME client. 

Another thing I’m working on is a more complete cloud service. I’m not sure if this will be a part of Californium or not, but these are a couple of things I want to achieve by the end of the year.