Hello, everyone. That's too early for that. I suppose we're all developers here, and I work from SUSE, and I'm here today to talk to you about the SUSE Developer Program.

It's a newly started initiative from SUSE, and I hope you find it interesting and you can collaborate and help us and be part of the community. So, just to give you a little bit of an introduction, why are developers important for SUSE?

Well, if you think about how many developers there are in the world, you may think that we have enough. There was a study conducted, and it looks like we are 25 million in the world, which sounds quite a lot, and still we are not enough.

The reason why we are not enough is because the amount of complexity that each one of us is facing every day is growing and growing and growing. Applications and tools, ecosystems in general, are becoming much more complex.

We keep adding abstraction layers to facilitate interoperability, and sometimes just because it's fun to have abstractions. And also, with the adoption of the real DevOps lifecycle,

we are doing a lot of automation, and automation requires integration, and it requires work and development. So, we're not just getting less to do. We're actually getting more stuff to do. And still, interestingly enough, in recent years, everything is about the cloud.

Everything runs in the cloud, and there are new technologies out there that are even for developers running into the cloud. I don't know if you're familiar with that, but there is a fairly new tool called Eclipse Che.

For those who are familiar with the Eclipse IDE, Eclipse Che is the exact same, but it runs into the cloud. It's quite amazing, and it's a brand new feeling and experience that you can have. So, SUSE, because of all this, decided to invest into the developers

and create a program around developers. Currently, there are three people full-time assigned to this. One is me, just in the middle picture. The other two, one is Firenzeckli, he's based in Finland. And the other one is Tim Hernich, he's based in Germany.

And we're basically the developer relationship team. Developer relations, as such, is a team that has been quite an important team in many different companies in our industry for quite some time now.

In fact, if you look around and you're really interested in developers' programs, and what's... Andreas was talking about NVIDIA before, NVIDIA is a developer program, Microsoft is a developer program,

Cisco is a developer program. And they all try to basically help developers to have a better development experience on their tools, or with their tools, or for their tools. So, what is our idea?

Well, first of all, developers like technology. So, the first thing that we are addressing is a superior developer experience. Being that programming language specific, like imagine Python or Go these days,

is the new language that many are adopting, or a very well-established language like Java and all the ecosystems around Java and what is required by developers. It's not just about programming languages, it's also about methodologies.

Before, people were writing an application running on a single machine, then we start seeing client-server type of methodologies, then multi-tier, then cloud, now we're talking about containers, microservices. Each one of those have different needs,

and we need to help those developers with their needs. And then there is yet another abstraction in all this. Use cases, or what we call verticals. So, you can imagine developers work in different industry segments. So, there are the developers that work in the IoT business,

or the guys that work in the automotive, or people that have to do with the big data, machine learning. There are tons of it out there. And obviously, developers that are facing the needs of a data scientist,

for example, has a very different need from a developer that's an IoT developer working on some embedded system. What is our main goal with regards to technology is to offer what we call day one experience.

So, making sure that developers that are using our tools, our infrastructure, our frameworks, can have a pleasant experience to start with from day one. Which means an easy way to find the tools,

being those packages, being those containers. Many developers do not necessarily even care about the distinction, whether it's a container, or a package, or how do I get installed on a distribution. They just care about using those. And obviously, making sure that those tools are properly tested,

properly validated, and again, paramount important is documentation. Not everyone wants to dig into the code to see how something works. Many developers that we are addressing are not necessarily even developers coming from a computer scientist's perspective

or background. A data scientist may not be a computer scientist at all. And how do we build this perception that we spoke at the beginning like about that we care about developers?

How do we reach out to developers? Well, an idea that we have and that we're just basically bootstrapping these days is the developer portal. It's literally a web portal where developers can reach out to us but also see what we are doing for them.

In that regard, that web portal will contain trainings material, videos, recordings, hopefully even videos that are recorded here or other conferences around technologies or about anything that has to do with open source tools, infrastructure, frameworks.

Another thing that we are considering is to have podcasts, YouTube videos, where people again can listen to the experts, matter experts in certain areas

and learn about technologies. Something else again is the developer evangelists. So we need help. And there's nothing better than having people using our distribution like open source

talking about it, talking about technology, how you can improve it, how we're doing about it. Tools that we have for open source like the build system, the build service and how others that are part of our industry but not part of our community,

how can they easily integrate their applications with our tools? So talk about those, reach out to people and help others use what we develop. Another interesting aspect about the developer program is the ecosystem alignment.

So we would like to basically make sure that we drive the adoption of what we consider the onboarding levers. Open source distribution is the most important ones for us, like being tumbleweed, leap, cubic.

And as I said, and I discussed this with some of you today, helping people that are new to the open source world to build their application,

to host their application, to create packages for their application, so that basically our ecosystem can only grow by doing that. Very briefly, I would like to talk to you about what we are doing from a technology perspective to address the first needs that we saw

or that we feel are important for developers. So the first one, as I said, is the Go ecosystem. There are more and more applications being written in Go, so some existing application being ported to Go,

and there are caveats around it. Above all, for people like us that would like to basically create packages to have first-class citizens in the distribution, Go has the caveats that all dependencies are pooled,

has sources and then built locally. Obviously we know what are the troubles with that, and for that reason we are basically building a service in our build service that can help with the module dependencies and create requires in spec files based on the dependencies.

So again, something that can help Go application developer understanding and getting closer to our environment. That effort is driven by Jeff Kowalczyk, which again is a SUSE employee based in the U.S.

The other one is tackling the Java ecosystem, and that is done by Friedrich, which I see here in the room, just sitting there. He's been working on basically making sure that we can have Maven

working in OBS, bootstrapped in OBS, took a lot of effort to make it working, and I suppose there's still a lot to be done. What is to do with the Java ecosystem is

it's really, really cool that a Java developer on his own machine has Maven and can basically have all these dependencies automatically sorted out by the infrastructure, but once again it becomes much more complicated when we want to do this in OBS,

for all the reasons that we all know, and they're all very good reasons, but we need to address those needs. The other one is Vagrant. Vagrant has been pretty much the de facto standard in upstream open source communities

for accessing VMs boxes on the fly. It's also integrated in many upstream projects, like in Jenkins pipeline, to basically test on different distribution-specific third-party applications. And so, when we looked at that, we thought that it would be really cool

if we could basically address this need and building it up in our own pipeline that we already have in the build system to make sure that every time, for example, a Tumbleweed image creates a snapshot, or a Tumbleweed image has a snapshot created,

we also get a new Vagrant image. And that's exactly what's happening these days. The box that is produced is also fully tested in the Jenkins pipeline, and then, if all tests pass, the newly box gets linked automatically to HashiCorp Vagrant Cloud,

so whoever uses Vagrant these days can do the magic. Vagrant init, Vagrant up, Vagrant SSH, and it gets a new Tumbleweed image in no time. It's pretty handy, it's pretty cool, and it makes the experience from a developer factory much easier, because now developers can test,

and can also, not necessarily just test, but also develop with our distributions in literally five minutes. And then there is, once again, another item that we are interested in. It's the WSL, it's the Windows Subsystem for Linux. Why we are interested in it is because it's really helping us to build that bridge,

that these days a lot of developers use Windows as a desktop machine, where they basically use their development tools, IDEs on Windows, and then in the past they had to use specific other tools or infrastructure

to deploy or try out their application on Linux. WSL is somehow bridging that gap and helping us, and we can basically show how cool it could be to run an application on Linux once again. So finally, a few takeaways.

Well, we are the new kingmakers in the industry. It has been recognized that decisions before were pushed from top to bottom, around IT, around processes, and how to do things.

That direction has changed. Now high-level management is listening to developers because they are the ones using the technology, they are the ones that are on the field using them, understanding them better, and so we are finally being listened to.

And one last thing, please reach out. We have our ideas about how to improve developer experience on our distributions, but I cannot know everything, so it's very important that you let us know, write me, ping me, I'm on Freenode, my email, you saw it before,

with ideas, with pain points. What would you like to see? What do you think is not working today? And we just want to make things better for you, all of you, and all of us. Thank you.

If you have any questions, I think a couple of minutes.

Mark, a quick question. How many of the developer tools are cross-platform, both from an architecture perspective but also from an OS perspective? So rather than limiting it, how can we make sure that what we work on,

the tools that we have available, can work across as wide an area as possible? I would say we're doing a pretty good job in that perspective already. Most of the tools should be in our platform agnostic, per se.

I think what we could do better at is to possibly work on the performance aspect of how tools behave on different platforms, and hopefully we can work with people like yourself to understand platforms better, to make things working better on specific platforms.

But as such, I think we already have the very good attitude to always make sure that tools are built for x86 or ARM platform, PowerPC, etc. Do you know if Vagrant is multi-platform? Is that x86 only?

Which one? Vagrant. It is. It is multi-platform. Yes. We have both for x86 and ARM. Thank you.