Martin Wimpress, Slim.AI Senior Director of Developer Community Relations, spoke with us about his prior experiences and personal projects. Before his time at Slim.AI, Martin worked at Canonical as the Director of Engineering for Ubuntu Desktop. Martin gained experience in community development and developer advocacy, which became his passion. Now at Slim, Martin focuses on building the community around open source and advocating for developers.
In Martin’s free time, he elaborated on this fascination by leading personal projects such as creating derivatives of Ubuntu, podcasts, conferences and live-streaming. He hopes to educate and create communities in all realms he is passionate about.
Open-source software gives you this vast toolkit — like Lego bricks with no instructions — that I can put together to make stuff and then engage with people all over the world in different disciplines. The value of open source, to me, is collaboration.
Tell us about your background. How did you get into developer experience? What positions have you held at different companies? What is your current role at Slim?
I originally started out as a software engineer, that is what I studied at university. Then I transitioned into what we call “infrastructure” today — then it was “systems administration.” I specialized as an enterprise architect and then a security officer. I got quite far from technology while in security, so I was looking for a way to be more hands-on and involved with technology.
I joined a start-up company, Flight Data Services, in the early 2000s and took on a role basically doing all things IT, taking on the operations-and-development side of things, such as building an operations and developer team. I was managing both of those. Part of that was creating an open-source platform and bringing people to not just the product, which was a SaaS platform, but also to the open-source engine behind it. That was my first experience in a commercial role doing community building and business development, which was a part of that job I really enjoyed and appealed to me. Although, I don't think I recognized it as community building at the time. I saw it more as business development.
I wanted to be doing more work around devices, and less to do with servers and infrastructure so that is why I joined Canonical to work on the desktop team. In order to get my position at Canonical, I was a community contributor and built communities in and around the Ubuntu ecosystem. Again, that was something that I enjoyed very much. Once I joined Canonical, it presented a number of opportunities to work with the community in order to empower, educate, and assist them. I very quickly switched roles to one that was dedicated to advocacy. That was the first time that I was professionally recognized as a developer advocate, which I did for four years. Developer advocacy was the high point and what I enjoyed most during my time at Canonical.
I took on other responsibilities at Canonical and little of my time was focused on advocacy, which is why I chose to join Slim: I wanted to specialize full-time in developer advocacy and community building so I was specifically looking for that role, and the culture and ethics at Slim were significantly attractive factors as I was looking for an organization that has a very strong culture and values.
Tell us about your personal projects. What are you working on? How did they begin?
I created a derivative of Ubuntu, called Ubuntu MATE, which is a Linux based desktop operating system. I have been leading that project since 2014. I really made it for my friends and family that use Linux. It preserves a way of using Linux that they are familiar with. That was my motivation and I will continue to lead that project in a way that creates a retrospective computing platform for those people who don’t want to learn new paradigms and want something predictable that doesn’t change beneath them. There is a whole community around Ubuntu MATE in terms of developers and users. Over time, I have handed off much of the responsibility of running the project to the community. I am currently a figurehead, make architectural decisions and handle the fundamental technical implementation. This is a way for me to keep my hand in at a low level with Linux stuff, which I enjoy. This is a hobby for me.
I do some podcasts with my friends, Ubuntu Podcast. This is a weekly, half-hour podcast that is 13 or 14 years old. I have been doing it for six years. It’s a family-friendly, magazine-style podcast about what is going on in Ubuntu. I started doing that even before joining Canonical and will continue doing that with my friends. We have some spin-offs: We created a conference in the UK called OggCamp which is a free culture conference. This conference was initially created to present live podcasts, but now has evolved into a tech conference in its own right, it even has exhibitors. We usually do that annually, but in recent times we have not been able.
There is another event called FOSS Talk Live which again revolves around the open-source podcasting scene in the UK. I have been a presenter and organizer for that. We did the first virtual one of those a couple of weeks ago. I organized that event because it was virtual and I had the skills to do it.
I do some educational live-streaming for people who want to understand more about Linux development. I also aspire to make educational videos about how to get stuff done with Linux, but I never quite find the time to get to that one.
What do you value most about open source in terms of your personal projects?
A lot of people with backgrounds in Linux, like myself, answer the question about open-source in terms of freedom and how those various licenses affect you. That is never what has appealed to me. Open source has always meant that I have been able to collaborate with people to make things. I like making things with software and sometimes with hardware. Open-source software gives me this vast toolkit — it’s like Lego bricks with no instructions that I can use to put together to make stuff. And then engage with people all over the world — all these experts in different disciplines to actually make useful things. The value of open source to me is collaboration.
Reflecting on your career as a whole and while at Slim, what are some key struggles you have faced?
The biggest key struggle, not specific to developers but you see it more so with developers, is that they are universally time-poor. There is more work that needs to be done than there are people to get it done in the time required.Developers are keen to create tools but they are often idiosyncratic and they tend to solve a problem for themselves, but not necessarily broadly for everyone else.
We have had this explosion in complexity of the container ecosystem. Not because it is necessarily complicated, but because there is so much choice now. It is kind of impenetrable to know where to start if you are entering into this. If I look at things now, it is a struggle to actually keep pace with the changing landscape — to know who the movers-and-shakers are and what new technologies you need to move with. If you just look at AWS in isolation, that was two or three products when it first appeared 13 years ago, and now there are hundreds of components, services, and capabilities. It is a complicated platform in its own right and that is just the AWS infrastructure. There are a whole bunch of choices and decisions to be made. I think staying on top of all of the different options — along with the breadth available, the rate at which it is becoming available, and the speed at which it is developing — is what is most challenging now.
Slim’s mission is to make containers easier to work with and easier to manage. We focus on automating container best practices so developers don’t have to add that to their to-do list. Our tools give developers the ability to know what is inside of their container, therefore the process of authoring, optimizing, and debugging is more fluent. We hope to work to educate developers about container best practices and connect with developer communities that are working regularly with containers to help them understand why best practices matter.
Are you hopeful that this issue of developers and the rate of complexity will recover?
I do see hope now because there is a movement spearheaded by developers and it is broadly recognized as developer experience or DevX. I think developers recognize that there is a need to be efficient and have tools that solve problems in a meaningful way. We had the DevX Conference last month, for example, which is geared around developers educating developers on better workflows, better approaches, the right tools for the job, the right way to solve particular problems, and sharing knowledge and insight. I see that movement as key to improving the understanding of the landscape. Where to start, how to start, where to find advice; I am encouraged by it.
Thank you, Martin.