Eric Meyer: Hello, welcome to another edition of Igalia Chats. I'm Eric Meyer, I'm a developer advocate at Igalia.
Brian Kardell: And I'm Brian Kardell, and I'm also a developer advocate at Igalia. And today, we have a guest from Igalia. Do you want to introduce yourself?
Alejandro (Alex) Garcia: Yes. Hello, Eric and Brian. This is Alex. I work in Igalia. I'm a developer in the WebKit team, and I've been working in web and use development for a long time. Nowadays, what I do is that I basically not just developing, but I also try to coordinate a lot of the technical details in the development of the WebKit force inside Igalia.
Brian Kardell: So, it's strange that I was looking today, and we're approaching 80 episodes of Igalia Chats that we've recorded. We don't number our episodes, so I never really know how far we are, but we've never really had a show on WebKit, not because we haven't wanted to. We've made some efforts to do it in the past, but something always falls through, but I don't think a lot of people probably know about... A lot of people know that Google is the steward of Chrome, but then you have Edge and Brave. You have other contributors, but Igalia is a big, big contributor on WebKit, like 16% of all commits. That's huge by comparison to Google. But do you want to talk a little bit about the WebKit project, and Igalia's involvement, and maybe if there are other parties also involved, that you could give some credit to?
Alejandro (Alex) Garcia: Yeah, yeah, actually, I can. There are facts that you're explaining, that not many people know maybe about this project, but we have been working in WebKit, even before Google did the fork of the web engine. So, it has been a very long time. We even had the initial Web Engines Hackfest in Igalia, I think it was 2009, and people from Google came even. So, it was real interesting, and we have been the number two in the amount of commits that we are providing for the last years. But there are more people, like in the past, there were more before Google left, but nowadays, there are still more companies, like Sony, and other companies that are also contributing to WebKit, and providing work, or Microsoft, or other companies. But we have Red Hat, that it includes the engine in their distributions. I'm not completely sure about the current situation, and how they are including it, but in the past, they were active, and nowadays, they're also still helping with some things.
Brian Kardell: Yeah. It's a long time to be involved with a project for absolutely no reason. So, there must be a reason that we stay so involved. Maybe you could tell us about Igalia's involvement and-
Alejandro (Alex) Garcia: Yes, yes, I can. Since the beginning, like in the beginning, we were like a company that was focused in the GNOME desktop environment, and we were part of the developers that were creating the browser in that Linux distribution. And it was based on Firefox web engine, but at some point, they decided that they were not that interesting in allowing an API for embedders. So, at that point, Apple released WebKit, so that we decided that it was a good option to give it a try, and it worked. And then, we started contributing to it, and we were creating products around it. And because of this success in integration and the software product that was created, some companies decided that it was a good idea to integrate that specific engine in their products, including embedded devices, and other different kind of embedded options, like applications. And they were asking us for support, doing that integration. So, that's how it started. And then, it has evolved in a lot of different devices and things that we have done, along the years, from set-top boxes to cars, to planes, I don't know, all different medical devices, kitchen appliances, and I think it's a lot of different places that not everyone knows. And yet, an interesting point, just to summarize, in the history of the contributions that we have done, is that, initially, it was basically everything based on GTK. So, the people that wanted to use the engine, they were forced to include also the GTK library, and that was a big requirement for some of these companies that were creating a small embedded devices. So, yeah, I think it was in 2014, we started working on that early. We basically removed that dependency. It was the initial development for what we nowadays know is WPE, which is specifically created for engines, specifically created for embedded devices that has minimal requirements regarding the libraries that you need to include, are not typical in embedded devices, but are typical in a desktop like the GTK.
Eric Meyer: Okay. So. WPE, what is WPE for those who listening, who don't really know what it is?
Alejandro (Alex) Garcia: WPE is basically a WebKit port. I'm not sure if everyone knows what a WebKit port is, but it's basically a way to configure the web engine, so that you are able to run the engine in a system. And WPE is the WebKit web engine for embedded devices, which means that we try to integrate the whole WebKit in small devices, and making it run and perform, so that you can use it to create your own applications, or your own browsers.
Eric Meyer: Yeah, so WPE, one would presume that that stands for WebKit port embedded. Is that actually true? Okay.
Alejandro (Alex) Garcia: No, it's not. Nowadays, it's an acronym, but it is not an acronym anymore. So, it's basically WPE.
Eric Meyer: It is one of those acronyms that maybe stood for something, but now, it doesn't. There's a term for that, and I've forgotten what it is. So, it's WebKit, but it's WebKit, like pared down essentially. Certain things have been turned off or changed, so that it can be used on set-top boxes, or seatback displays, or in-dash displays, or that sort of thing, right?
Alejandro (Alex) Garcia: Yes, yes, yes, exactly. And actually, well, it is mostly adaptation and focus in Linux devices, because as you can imagine, Apple does not care about Linux. So, what we do is, basically, first, porting it to Linux, and then making sure that the devices that are able to run Linux, that are really small devices, are able to run the web engine and the features that the customer's going to use for their UIs, in a way that performs as expected.
Eric Meyer: I'm sorry. What kinds of things is it that people want to use for the UIs?
Alejandro (Alex) Garcia: I think, in my opinion, because it's my personal opinion, the reason that it fits very well with the web is because the web is very flexible in how you define the visual UI. So, that's why a toolkit is too much restricted, so you cannot do whatever you want. So, then, there are multiple things. I mean, you can use, for instance, UIs that run an SVG image that you can click, or UIs that have a form that you have to basically fill in to do something, or UIs that show a video, a movie, or a menu, where you can pick the movie, and then after that, show the movie. And everything has to be sometimes very visual, and then you can add effects, or not. And interesting part here, which is something that not many people understand, is that, well, the web runs well in your desktop, because your desktop is a big machine, with a big GPU, and a big CPU, but then when you move your webpage, or in this case, your UI, the smaller embedded device, then you don't have that hardware, you don't have that powerful device, so you have to restrict yourself to some things. And then there are other things that you can adapt, and then you can improve some other ways how the engine does something, so that you're able to run your UIs in this kind of devices.
Brian Kardell: I think there are a lot of other aspects of that too. There are a lot of expertise in web technologies, so it's very, very easy to find people who have experience in that, as opposed to maybe somebody who have experience with a UI toolkit that might work on a specific device, whatever. So, the more kind of lingua franca, we make HTML, JavaScript, and CSS to do the basic things, the more we have expertise readily available for that. And it's portable. And sometimes, you want even unified design system that covers both your website and the embedded device, or something. Yeah, I mean, it's pretty interesting. I had a lot of questions when I first got here, because I was like, okay, I mean, I know in the abstract that there's a web engine, and it's not the same as web browser. I knew this six years ago, or whatever, but I didn't understand, how do I use it? And in learning the process, one of the things that I learned that might be helpful toward Eric's question earlier as well, which is, I think of the WebKit project has sort of the main bit that is WebKit, is a Lego. We like Legos in engineering, but it's not the bottom Lego or the top Lego, it's kind of the middle Lego. And so, you have to put... It provides these APIs, but it doesn't provide necessarily implementations for all of them. And so, you have these APIs that are implemented, maybe in the middle, but the individual ports have to provide implementation for them, or also it could be down to your actual deployment. Your actual deployment might provide some implementation. So, that can be everything from... Well, I don't know, Alex, let's leave it to you to explain what kinds of things might be in there. Also, I don't know if maybe you want to compare it with Firefox or Chromium, because I never really understood how they're different, but Firefox is a browser project, and there's sort of not one of those for WebKit, except for maybe the mini browser, which is also a thing that I only learned about after coming here. Yeah.
Alejandro (Alex) Garcia: Yeah, yeah, exactly. Yeah, you're describing it really well, regarding the metaphor about the Legos. Yes. Basically, the main difference between what we do in WebKit, and what Chromium or Firefox are doing, is that they provide the whole browser. So, when they want to support Linux, Apple, or Windows, they provide also all the implementation for all the UI that they are creating. And the differences is that, in WebKit, the core part is something that we share, but every company that is interested in supporting some system is providing the other parts. For instance, we, in WPE, provide the Linux part, and we are also start starting to support Android too, and Apple is adding the support for all their devices, and Sony is adding the support for the PlayStations. So, that's kind of like the Lego part, the things that you need to integrate in the system. I guess, it's easy to see, for instance, with multimedia, that, in Apple, you have multimedia libraries, and the engine has to use those multimedia libraries. In Linux, you have a different kind of multimedia libraries, and equity has to use those multimedia libraries. And the other part, which is interesting, is that we are allowing also that the people integrate WebKit as a software part, like a Lego part, but in case of Chromium or Firefox, they're providing an application. So, what it means is that you compile application as you use it, even some people are just basically just using a compiled application in their system, in their desktop, or in their phones. But in our case, what we provide is the part that you integrate to create a different application, which can be a browser, but it can be also like a UI, or any other kind of applications. That's the main difference. And sometimes, it's tricky, even for technical people that are not in this lower level, to figure out why is that important. But when you try to integrate Chromium, and then change it so that you create your own browser even, and you start to realize that there is not a contract between Chromium, to modify some parts, and then when you try to integrate back all the changes that happen in Chromium, you need to solve a lot of different conflicts in your code, then you realize that, 'It would be great if you have a stable API that you can use. And every time I integrate a new version, I don't have any issue.' That is, basically, what the WebKit API is doing. You provide API, you use that API, and we have a contract, which is a public contract in software, where we say we are not going to modify that API for any different version. So, you can reliably use that API.
Brian Kardell: Which is a selling point that a lot of people like, and one of the reasons that it is chosen, right?
Alejandro (Alex) Garcia: Exactly, yeah.
Brian Kardell: I think another thing that I learned, I didn't know that learned as much as realized, is that embedded systems are different in some interesting ways. They're underpowered generally to begin with, because the goal is often to make them as featureful as possible, so that it's an interesting sales, interesting experience, but also as cheap as humanly possible to make. And so, I don't know what the situation is now, but at least when I started, I know that involved a lot of systems that were still 32-bit, that were being actively made. I don't know if people are still actively making 32-bit systems, but-
Alejandro (Alex) Garcia: They are using, it's still 32-bit. Yes.
Brian Kardell: So, I mean, we're shipping 32-bit systems, and the life span of a phone, which is really high-end, is... I don't know. I mean, a lot of people replace them every two years. I think five years is probably a long time to have a phone, but five years is not a long time to have your cable box, or your car. So, these systems, they hang around for a long time, in a lot of cases. So, stable API makes a lot of sense, and having a system that can work, that you know works on these things. But it also provides, I think, some interesting and unique challenges that we have a lot of, and always increasing expertise in, right?
Alejandro (Alex) Garcia: Yes, exactly, exactly. Because as you can imagine, as I said, Firefox and Chrome are also providing support for Linux. So, we are providing exactly the same kind of specific part. So, in that, we have common code in the end, not common that we are using the same code, but that it's doing basically the same thing in the system, but we have also focus in these kind of devices, which means that you have to provide good performance in a 32-bit device, and you care about it. So, you have to basically run the integrations to make sure that you don't regress in that situation, that the performance is the one that you expect. But even companies that are big, like Google, they are not going to provide, probably, integration with the systems that they don't care that much. So, if they are not creating an embedded device that is specific for 32-bit, or something like that, they're not going to pay attention to that kind of code. So, that's the kind of things that we try do to differentiate, not just the API, but also how we do the integration with the systems that we care. And, for instance, one of the main differences is that, for us, Linux is kind of the first-class citizen, and that is not the case for a lot of the browsers that are currently being used. They can provide support for Linux, but it's not like the first call for them. So, that also differentiates on how we deal with the issues that we have in those kind of systems.
Brian Kardell: It's a completely different funding model for a lot of other browsers. It's interesting, because we say browsers, but WPE isn't a browser.
Alejandro (Alex) Garcia: Exactly, yeah. It's not a browser.
Brian Kardell: And that's also interesting, because the things that you want to do, they have very different kind of security concerns. They're an interesting challenge that I think is more similar to other tools, like Electron, or something like that, where I do think we can probably use some more layer of standardization, or something. But yeah, I mean, I think it's really cool that things are designed in such a way that we can open ways to do really interesting things with these embedded devices. So, I worked just really briefly on a project at Igalia, that was for a kind of a food processor that has a touch screen, and interactive, and it had sort of virtual knobs, and they control the real temperature, and the motor, and all that kind of stuff. And those also then have hardware controls and things, but the controls on that is different. The constraints on that are different than the constraints on the media player on your car, are different than something that would actually control your car. And the web can be used to different extents, with different pluggable bits that you can control a lot about, with a thing like WPE. I think it's cool.
Alejandro (Alex) Garcia: Yeah, yeah, exactly. Yeah, that's really interesting. One thing that came to my mind while you were talking is also that, sometimes, we need to differentiate embedded browsers, with browsers that can be using embedded devices, because sometimes, I go to some conference, and people are starting to talk about embedding a browser, and they talk about things like Electron. And, for us, it's true that that could be a goal at some point, but it's not the real goal for us. For us, it's more like about embedded devices, embedding in embedded devices, which is kind of similar, but it's not the same thing, because when you want embedded applications, like Electron, it's very important for you to have a web engine that is able to run a lot of different systems, and they must include Windows, they must include Mac, they must include Linux. As I said before, for us, nowadays, the main development is in Linux. That wouldn't be an option for an engine that is used in an embedded system for an application, but it's really good for embedded devices. And the reason is, most of the embedded devices are using, nowadays, Linux or Android for running the system.
Eric Meyer: So, one of the devices you mentioned, it was a while back, but it snagged in my head, because it always does, is the Sony PlayStation. There's some part of my head that has heard enough times, that I know that the Sony PlayStation uses WebKit, and yet, every time I hear it, it's a little bit of a surprise. But that's still regarded an embedded device?
Alejandro (Alex) Garcia: Well, yeah, I guess it's a little bit more powerful. That's true. But it's still an embedded device, because it has a specific system, and you have to change the integration with the system. And it's not like a full UI, like a full desktop UI, where you can do whatever you want. Actually, even for Sony, it has changed, and it has evolved during this time. Initially, they have, I think in PlayStation 3, I don't know much, but I think in PlayStation 3, they had a specific browser that you can open and use it for browsing, and then they have kind of limiting the use of the browser to opening different things. So, maybe you cannot use just a full browser anymore, because I guess the gaming industry things that now you can use your phone, and then in the PlayStation you play, but still, they need to open, sometimes, web content. It makes sense, because if you have a store, and you want to open a web page, a review of a game, you need to open that.
Eric Meyer: Yeah, so you need a WebView.
Alejandro (Alex) Garcia: That requires a WebView. Yes.
Brian Kardell: So, we're talking about how these devices last a long time, and you want a stable API. But another thing that I wonder about is, we make this WPE, and you don't know what the future holds. It's always a tricky thing. You don't know what the future holds. You don't know if, maybe, next year, everybody will be like, 'Why are we still making 32-bit APIs? Why? It's not worth it anymore. It's not economically advantageous. We're not going to do that anymore.' Or, I don't know if touchscreens were always a part of the thing, or how common they were, but they're very common now. I don't know if we had accounted for them, when we made things originally. And I think XR is another example of this. Maybe AI, at some point, will be very relevant. Voice inputs, definitely. Voice output, definitely. There are all these things that, if I was writing code 15 years ago, I would not have been prepared for. And one of the nice things about the web is that the web is generally pretty good about that kind of stuff. So, we try to make things not bound to specific devices, not bound to specific inputs, so that it grows, but it grows slowly and somewhat flexibly. But what does it mean for a project like WebKit and WPE? Do we find ourselves coded in a corner sometimes? Do we find... Yeah, I don't know. That's a long time to maintain a project. I've never maintained a project that long, so I'm just curious.
Alejandro (Alex) Garcia: Yes, yes, that's exactly... I mean, first is that I agree with you, and probably you know better than me, that one of the strengths of the web is the evolution, and being able to evolve with the hardware, and the technology, and all the new challenges, which is amazing. I mean, it started in the '90s. We didn't even have the kind of GPUs that we have nowadays. It's crazy. And then, it's amazing that you are able to evolve, that it was... I mean, the initial lines of this, they were writing before, like in the past century, which is something that reflects how it has evolved, and that is very powerful, and it's a trend. But it's also, it is true what you're saying, that sometimes, it means also you need to do a lot of work to review what you have done, because you made decisions. I mean, I've been reviewing decisions that we made 15 of 20 years before, so it's kind of difficult sometimes to understand what this will mean. And one of the changes that happened, is an example of this, is that, initially, what we were using, rendering library, it was the common rendering library in Linux, which is called Cairo. And it was really well maintained. It was created, and it has a really amazing community, for a long time, for some years.
Brian Kardell: It was kind of the de facto standard, right?
Alejandro (Alex) Garcia: Yes, at least for GNOME and multiple systems. It was just... And everyone was using it, and now this is still used. But then, after some years, the development stopped, and the companies that were providing support for it, they were not spending that much money, and then you had less fewer releases, and the releases didn't include that many new features and improvements.
Brian Kardell: It's a little bit like that xkcd comic, where it's like the blocks, and then one block that holds it all up is some open source developer, working nights in his basement in Montana, or something like that.
Alejandro (Alex) Garcia: Well, we have, in Linux, some libraries like those. I have to say that Cairo, I don't think it's exactly that one. Maybe FreeType it is, but I don't know. But Cairo is not exactly that one, because at some point, there were not even anyone, and it was not that small. I mean, in the end, Cairo was really big, and at some point, we were participating in the development. And a lot of huge companies, like, for instance, Nokia was spending a lot of money, trying to support multiple hardware, because in a rendering library, it's important to support operations in native hardware, so that you render as fast as possible. And it created also different kind of prototypes, to rendering in GPU, it was kind of like the first library trying to do it. But yeah, it evolved in a way that, for instance, the GPU support was removed, because it was not even maintained at some point, and there were not releases, because no one was maintaining it. Then, someone from Red Hat came, and did some release, trying to fix some issues, even memory leaks that were there. So, at some point, after using it for more than 10 years, we started to check if we could use something different. And after a long time trying different options and studying the situation, we moved to Skia, which is basically the same rendering library that Chromium uses, and it's implemented by Google, which it's really great, the collaboration that we do with them.
Brian Kardell: I think Firefox also uses it.
Alejandro (Alex) Garcia: Yes, yes.
Brian Kardell: Yeah.
Alejandro (Alex) Garcia: Yes. And that is a good example of what you were saying, that you need to re-adapt the technology, because when the projects are that long, that they are created in the past century.
Eric Meyer: I prefer the previous millennium.
Brian Kardell: Oh, geez.
Alejandro (Alex) Garcia: Yeah.
Brian Kardell: But basically, WebKit is from the late '90s, more or less, because it was originally KHTML, right?
Alejandro (Alex) Garcia: Yes.
Brian Kardell: And KSVG. And then, I'm not sure what year. Do you know what year? Anybody? What year Apple-
Alejandro (Alex) Garcia: I think it's... Well, the initial code is 1999, or something like that, but Apple decided to use it later.
Brian Kardell: Yeah, what year? That's what I was looking for. I think David Hyatt announced something that they were going to try to do it on the WebKit list, or not on the WebKit list, because there wasn't a WebKit, but on some mailing list.
Eric Meyer: According to Wikipedia, since I just pulled it up, it was January of 2003.
Alejandro (Alex) Garcia: So, I just checked the repository from WebKit, and the initial commits are from 2001.
Brian Kardell: There you go.
Alejandro (Alex) Garcia: So, I guess, I mean, even when they announced it in 2005, they started to work on it in 2001. Actually, I see that one of the original committers is Ken Kosienda, which I know I saw some pieces of news about him being the one that implemented the keyboard in the iPhone. So, I guess it was kind of like that thing that was creating all this initial technology, that started the WebKit. And yeah, basically, if I understand what they did, they forked those two projects as the initial code, but after that, basically, they evolved it, and at some point, they even tried to contribute that, but it was accomplished at some point, and then decided to discard it. And then, of course, they contacted a lot of the developers from the Qt environment, to try to see if they can help. And one of those was our Nico and our Rob from Igalia nowadays, that they were like the initial KSVG contributors, and they were, at some point, collaborating with Apple, integrating this inside the engine. So, I mean, I think probably they're the ones that have been contributing to WebKit for longer inside Igalia, even previously to Igalia.
Brian Kardell: Oh, yeah, definitely. Yeah. And that's an interesting episode, that Nico was 15, or something like that, when he was getting started in this.
Alejandro (Alex) Garcia: Yeah, it was really dumb.
Brian Kardell: We'll link that in the show notes. It is a really interesting episode. Maybe what you thought we would like the project to be about, and interested in how we thought it would be, I don't know, consumed, used, probably was very different 15 years ago too, right? Or 10 years ago, or whatever. I don't know, how old is WPE?
Alejandro (Alex) Garcia: I mean, we originally started thinking about it in 2013, 2012, and the initial release or announcement, it was 2014.
Brian Kardell: Okay, so it's about 10 years. So, I don't know that we knew any of that stuff, about the goals, what we wanted to do, what we could do, what the future would look like. So, you mentioned Android. I don't think that, probably, at that point, we were imagining making a port for Android, right? It seemed way out of the things we were thinking. Can you talk about why we started exploring that in the first place?
Alejandro (Alex) Garcia: Yeah, yeah. At that point, as you said, there were things that we were not even considering, but the nice thing about the web engines, and so what, is that you basically can evolve in the directions that the interest of the market, or the interest of the pros, are defining every year. For instance, in that moment, or even before WPE, we still had X11 support, and that is something that, nowadays, we don't support anymore. And there are other technologies that we were also supporting, that they are not things that we are that interested anymore. And, for instance, there were even technology about GPU rendering that were not something common at that point, and they had evolved a lot. That's why also Cairo was an option at some point, because everyone was doing CPU rendering, but then, at some point, the GPU rendering was a thing in the 2D graphics, which is also interesting discussion about why they don't fit so much. So, that also put some pressure on us to use a library that could do something like that. And then, yeah, we are focused on Linux mainly, because that was kind of the main system that every hardware company, that they were creating boards that companies can use to create pros, they were focusing in Linux, they were creating solutions for Linux, but after some point, it was also very common. And nowadays, I honestly don't know the figures, but there are some boards that they have better Android support. Some of them, they have better Linux support. So, you have to make sometimes a decision, and depending on the company, they have to do it. And, as I said, in the past, we didn't pay that much attention. We created a prototype some years ago, but it was kind of like the prototype for the moment. But we have plans to... And we have evolved the Android port a lot in the last year, and we have plans to really making the Android port as a first-class citizen in the near future, and hopefully that brings also the option to use WPE in Android devices, because we see that more and more people are using it to create embedded devices.
Brian Kardell: That gets into your distinction a little bit, because the distinction that you made earlier about embedded applications versus embedded devices, so when you say Android, I immediately think like, 'Ooh, can I get it on my phone?' Well, I know the answer is sort of yes, but it's a mini browser, and it's for testing, and we don't publicize it or anything yet, maybe at some point, but there are interesting reasons I can imagine to do that. One of them is that, I know a lot of people, we have to make sure that our stuff works on Apple devices, and there are people around the world, the vast majority of them, actually, that don't have Apple, don't have iOS to test on. And so, that's like Epiphany is the browser for Linux. And so, I know plenty of people who have Linux that use Epiphany, it's not perfect, but they can make sure that it kind of works on macOS, but there's nothing similar to like, 'Will this work with WebKit, in a kind of mobile form factor, or something?' And so, I can imagine it being very useful for something like that, to just test out and explore, and maybe some other things too. But the thing that you're talking about, I believe, initially, is embedded still, right? It's just embedded devices, like the one in my car that uses Android player, or something like that. You want to develop some application, or maybe your own thing that also is just sort of based on Android, because Android is an open source, specifically, I guess we should say, right? Because it's its own thing. Yeah, it's really interesting, because I can see, maybe I'm wrong, but I think once we're running on Android for embedded devices, the idea of making something that's even useful as a WebView, or something that you could build, some more high-level thing on top of, to develop applications, more like Electron, or something. I can imagine it being a lot easier once we had that, at least for Linux and Android. But is that total bollocks?
Alejandro (Alex) Garcia: Well, your point is right, that I didn't do this differentiation, and not many people knows that. It's true that Android is kind of like a Linux flavor, a system that basically you can run without all the UI, and you can basically launch and boot a board with Android, but it doesn't mean that you're going to launch any UI. And then, you have the specific Google libraries for the UI, which then you can develop applications for those, that include this Java APIs and everything, where you have already a web widget, which is based on Chromium. That, we don't want, or at least, initially, we don't want to compete with that, because that is something that is specific for Google, and they are doing it, and they have their thing, and everyone probably wants to use that nowadays, at least we don't want to think about it. We are thinking more about using the Android-based system, without all these layers of Google SDK that they use for their phones. That is basically what we are trying to do, because on that regard, you can use our board with the Android drivers and kernel, and then maybe, of course, better than the Linux support, or maybe there are some hardware vendor that provides just the Android system. It's true that we are also providing the other part, which means that we are providing the Java API, so that you can integrate with an application, and maybe replace your Chromium application. But nowadays, it's just a prototype for development and trying. But yeah, it could be, I mean, you're pointing out good ideas about how that could evolve at some point to be useful, even for people that want to test a WebKit-based rendering engine inside Android devices. Yeah, I agree that we could have that call at some point. Yeah.
Eric Meyer: So, I'm curious, we're creating WPE for Android. I presume that Chrome for Android exists. So, what are the reasons to pick WPE over Chromium?
Brian Kardell: Yeah, I mean, again, I think this gets into the kind of three-way distinction of what are we talking about, when we're talking about these things.
Alejandro (Alex) Garcia: Yes, yes. The differentiation is that it will be like, if you pick the web UI widget that you're using in Android to integrate into your application, so you create an application when you're going to integrate some web content, and then you get that widget, that would be the idea. Can you create a browser with that, and then provide a browser for Android? Yeah, you are going to be able to do that. Are we going to do it? Who knows?
Brian Kardell: But then, just to clarify with Eric's question, I think there's a third thing that we were talking about there too, which is a W... I don't even know how to say this, but it is operating system based on the web. That is just the whole thing. It's not a general purpose operating system.
Alejandro (Alex) Garcia: The idea is that, if you want to create your specific application, with a UI based in web technologies, that with Chrome will mean that you need to remove parts of the Chrome UI and use it in kiosk mode, but maybe you have other things, so that doesn't like, the same thing that we were talking about, an embedded device. Chrome is good if you want to use the Chrome application, but if you want to embed it in a different application, and then create a UI based on that, then you are going to be restricted to, again, try to get different... Not to have a stable API, or a stable contract, where you can rely on, basically, you need to get the whole thing, and then getting it again and again, and then not modifying that much for your purposes, or you are going to end up doing a lot of work in just maintaining your patches on Chromium.
Brian Kardell: There's also Chrome OS, which is a whole another level of complexity here.
Alejandro (Alex) Garcia: Yeah, I'm not an expert on that environment of-
Brian Kardell: Yeah. And there's a project that's not owned by Chrome. I think it's basically one person that maintains it, that does a sort of competitor API. Oh yeah, Chromium Embedded Framework is what I was thinking of back there.
Alejandro (Alex) Garcia: Yeah, yeah.
Brian Kardell: But it's probably the more direct comparison, if you were talking about how do you... Well, Chrome must exist on Android, and it's like, well, but we're talking about Android open source, which doesn't even have a UI.
Alejandro (Alex) Garcia: Yes, in general, the people that we know that are using Android, and that they contact us to integrate a browser, they don't use the SDK, or the whole SDK. They create a specific application, and they use Android as a Unix system, let's call it like that. It's basically a Unix system that you used, and it has the typical Unix libraries, but they are specific for Android.
Brian Kardell: So, we're going to have to catch up, and have a whole bunch of variants here, where we have caffeine-free WebKit, and WebKit zero, and vanilla WebKit, and all these different flavors of WebKit.
Alejandro (Alex) Garcia: Yeah.
Brian Kardell: Yeah, I do sort of wish they had sort of more independent names that were less overloaded, because it is very difficult to talk about in some cases.
Alejandro (Alex) Garcia: That's true. I mean, maybe there is a business just on that, like providing good names. Maybe it's going to help people to understand, and then they are going to be able to design and think about new ideas, because in the end, what we're providing is a tool and part, that people can use to create new products and new ideas, and that is our goal, is to provide a technology that can bring new products, and people can use to be innovative and create things. I mean, that is the spirit of Igalia since the beginning, that we are tinkerers, and we like Linux, and we are open source, and we like to touch everything, and we like to provide tools, that people can go to a web page, download a board, and then install this piece of software, and then you can create a product with that, and then provide it to your friends, or create a company with it, and you're getting that freedom. That gave us a really, really interesting and good perspective about different ways of creating products from, I will say, companies that are not the big ones, where you can basically put a lot of resources, and just do whatever you want.
Brian Kardell: I don't think that it's generally, typically, in companies nature to invest in open source, and finding ideas, like WPE, that get other people working with open source, particularly maybe a smaller open source, that they have very direct relationship with. I wonder how much of the work that we do ends up doing upstream work, and effectively expanding the investment in web engines that benefit everybody?
Alejandro (Alex) Garcia: Yes, that is a great point, and a topic that we could talk extensively, because we have a lot of experience, and you know it, because we try multiple strategies to get funding for open source. That is basically our business. One case is that people that basically get the source code, and then you see it privately, and you never know about it. That happens, because sometimes, we know after some time that they are using it, or some people tell us, 'Oh, look, it's used here.' And it's like, 'Oh, we didn't know.' That happens. We have to live with that situation, and it's okay. The technology that we are providing, where we are trying to create, is this environment where that's an option, and it's okay. But it's true that if that will be the only thing that happens, then we wouldn't have a project like this one, because, in the end, we are developers, but we are also people that need to be paid for our job. So, in the end, there are other people that they use it initially, and then they come to you, and they ask you, 'We have these issues integrating it.' And usually, it's because they don't have the experience to know how to use open source. I mean, that's a very common use case, because it's kind of like, you are basically using the stable version. 'Oh, I am developing, so I'm going to use the stable version, and I'm going to integrate this, and I'm going to create my product, and everything is going to work fine, because my prototype is working fine.' And then, suddenly, a prototype is not like a product. And then maybe you're creating a successful product, but then you have to evolve the product, or you are having issues, and you want to create the next version. And then, suddenly, you realize that, 'Oh, maybe I didn't do the initial steps correctly, and now I have this big trouble of creating the next version of the product, but I have very old version with a huge patch, that I don't know exactly how I had to do with that. So, let's try to ask for help from these Igalia folks.' Or, maybe you're having a big issue that you don't know how to solve. It's like, 'Yeah, I have this device, and this JavaScript that I don't know why it's not working, and it has a bug.' And it can happen, because, yeah, you're creating something specific, but maybe Apple or us are not paying that much attention, as you know better than me. The web platform, it has very extensive APIs that can be used in a very different ways, sometimes it can even surprise you after that many years how it can be used. And then, there is the best scenario, which is actually what we try to do with those kind of customers, the highlight, if they have the financial foundation, we tried everyone to use the open source the best way, which is basically that you try to participate in it, because in the end, if you are able to work in tip of the tree, and then creating your products with the tip of the tree, and then using the stable releases to release your products in every version, and then sending every patch and every change that you have upstream, then that is going to reduce your cost in the future. And then, you're going to be able to invest in your product, and not in the maintenance. I mean, we have a word for this, which is the technical debt. If you are creating a lot of technical debt during the development, you're going to pay it sooner than later. And then, suddenly, you're going to have a release of what is going to be basically impossible to maintain your software. So, those people are the ones that we try to get as customers, and we try to help. And, I mean, we try to help everyone in the end, because, yeah, everyone comes here, and we are kind people, and then we are trying to solve bugs all over the place, and trying to be kind with everyone. But in the end, those are the ones that are maintaining the technology. And sometimes, the only reason that they are doing it in a different way is because they don't have the experience or the knowledge to do it the right way, because it's not sometimes about the budget, because you can hire just some hours, and then with those hours, you can really do the work the proper way, which is just because you are integrating in the team, and you know exactly what to do, and you need the small modifications and small fixes, and those can be done in a way that they are not going to create a technical depth that is going to grow like mold, and at some point, it's going to cause a problem for your company in the future. So, that's my understanding of the whole thing. And sometimes, we do a lot of education around this, and I think it's interesting, because this is a complex topic, and everything around software and how open source works is a complex topic. I mean, one of the key advantages of open source is that you can create a prototype very easily, and without talking to anyone. And that's a key advantage. But some people are misguided by that, and think that that means that they can create a product. And that's a different thing. I mean, a prototype is not a product. And then, the proper planning and strategical vision of how to use the open source is a different thing than creating a prototype. And if you fail that, then you're going to end up with issues. But that's our role in the community. And then, we also try to do other things, as you know, trying to create different strategies for people, trying to provide support for implementing some feature. But that is a more general thing, and sometimes it works, sometimes it doesn't. Everyone wants support for whatever API in WebKit, and they can pay for it. But that is kind of a different perspective, that it works for some things, but not for everything. One of the main things that we did in the last year, which is moving from Cairo to Skia, it was paid, but by customers like Comcast and Philips. They are like active users, and really good contributors of the WebKit community, and they have the perspective and the interest to improve the software, and we are able to collaborate with that, to integrate and enable technology in ways that are helping everyone in the community, like improving this Lego piece that is going to be able to help other people to create innovative products, that they hopefully could use everywhere in the world.
Brian Kardell: Okay. I think we have to call it for time, but is there any last words that you want to throw?
Alejandro (Alex) Garcia: Keep an eye on what we are going to develop in the next years, because we have really amazing plans for the technology, that is going to evolve in good ways. And around Android, we have really great plans, and around even performance and rendering. So, I think we're in a good position nowadays, and even with AI and all these new developments, we have a role to play, to help multiple companies to really use the web content in ways that can be very useful, in general, for us, like for the whole world.
Eric Meyer: Very cool. Alex, thanks for joining us, really appreciate it.
Alejandro (Alex) Garcia: Thanks to you. It has been fun.
Eric Meyer
Brian Kardell
Alejandro García