The Changelog: Software Development, Open Source - The History of GNOME, Mono, and Xamarin (Interview)

Episode Date: November 21, 2017

We talked with Miguel de Icaza last week at Microsoft Connect(); in New York City. Miguel gave us the backstory on how he's been competing with Microsoft for most of his developer career, and he shares the history of GNOME, Mono, and Xamarin — and what led him to now work at Microsoft.

Bandwidth for Changelog is provided by Fastly. Learn more at fastly.com. And we're hosted on Linode servers. Head to linode.com slash changelog. This episode is brought to you by DigitalOcean, who just launched Spaces, a beautifully simple object storage service that's designed for those who want a simple way

to store and serve a vast amount of data, such as hosting website assets, storing user-generated content like images and large media files, archiving backups in the cloud and storing logs. Just like you're using S3, you can use DigitalOcean Spaces and in fact you can use S3 and DigitalOcean Spaces at the same time so you don't have a single point of failure. This is a standalone service, no droplet is needed, and pricing is extremely competitive. To make it easy to try for both new and existing digital ocean customers, you can get started today with a free two-month trial of Spaces by going to do.co.changelog.

And by CircleCI. CircleCI is how leading engineering teams deliver value faster by automating the software development process using continuous integration and continuous delivery, you are free to focus on what matters most, which is building value for your customers. CircleCI is everything great teams need. Support for any language that builds on Linux, configurable resources, advanced caching options, custom environments, SSH access, security through full-level virtual machine isolation, interactive visual dashboard, first-class Docker support, and more. Get started with their free plan, which gives you unlimited

projects and 1,500 builds per month. Plenty to get started with. Head to circleci.com slash changelogpodcast. You're listening to the ChangeLog, a podcast featuring the hackers, leaders, and innovators of open source. I'm Adam Stachowiak, Editor-in-Chief of Changelog. On today's show, Jared and I are talking with Miguel de Acaza live and in person at Microsoft Connect in New York City. We talk with Miguel about how he's been competing with Microsoft for most of his developer career. Miguel is the creator of GNOME, a desktop environment for GNU and Linux. Also, Mono, a cross-platform open-source.NET framework, and Xamarin, a platform to build iOS, Android, Mac, and Windows apps, and C-Sharpen.NET, which was acquired by Microsoft in February 2016.

Enjoy the show. When I started with Linux, it was a very fringy thing. Like the 90s, what are we talking about here, time-wise? It was probably... I started using Unix, it was around the Windows 3 era. Okay. That was the last time I used Windows. And, you know, every time you made a mistake on Windows and you would crash, you had to reboot the machine. And I had a fancy IBM PlayStation.

Well, the university had a fancy PlayStation. Not PlayStation. PS2. It was called PS2. And it took too long to boot. And at the same time, the university got workstations, Alteryx, DeckEC stations, and DEC workstations. And the beautiful thing about that

is you crash your program and all you get is this label, segmentation fault, or core dumped. That's it. All right, well, let's try it again, right? So to me, it was magical.

The fact that you didn't have to reboot, like, oh, there was a bug, let's fix it. Right. Next. So I had already moved to Unix and at some point, Linux became an option where I could

run Unix on my PC. And I believe I had like a 40 megabyte hard drive. So I had to partition that to have a chunk on DOS, where most of my work was on. To do a boot. And the other piece was Linux. And the challenge, and really, at the time, there was another one, BSD. BSD was the big name. There had been a series of Dr. Dobbs articles about 386 BSD.

It was just around the time where NetBSD had essentially made into a real thing. This was before the forks and right about the time that they forked between NetBSD and FreeBSD. The problem was these BSDs didn't have dynamic libraries. So the nice thing about Linux is that they have dynamic libraries, shared libraries. Right. Which meant I could put it on my half a partition. Oh, you could fit it in the space that you had.

Yes, I couldn't put BSD on the little space that I could afford. Oh, I see. So I had to go with Linux. I can't remember what was my first disk. Maybe it was 8J loose, two floppy disks. It's interesting how what you would think would be kind of almost an inconsequential scenario, where it's just like, I just don't have the space.

That was the deciding factor. But it would actually kind of change the trajectory for you. I don't know if it was 40 megabytes or what was the thing. It was a 386 PC. I don't even know if it has a matcop processor. And Linux had a 387 emulator at some point. I mean, I don't remember these things anymore, but that's roughly where I started. It must have been 1991, 1992, perhaps, in that era.

It wasn't that general neighborhood. That got you into Linux. I mean, the question that we have, which maybe a lot of people ask you, is how does the original creator of GNOME come to work at Microsoft? It seems like that's a long story. Oh, it's a long story, yeah. Well, like I said, I was inspired

by the vision of Richard Stallman very early on, before Linux, on these Unix machines, because he was giving away an optimizing compiler. And in Mexico, you could get Turbo C, but that was a chip compiler, or Microsoft C. At the time, it was also a chip compiler. And if you really wanted to get your code running fast, you need to pony up for the expensive ones.

I can't remember what they're called. I think it was a Portland C compiler or something like that. There were a couple of commercial compilers, very high end. And they were very expensive. At least in Mexican pesos, it sounded like the cost of a mansion. No way, yeah. And a friend of mine came to me with a big printout and said, here, here's how you,

the university had just gotten into the internet, and they said, here's how you make your Unix machine useful. And look for this GNU stuff. There's a lot of good stuff in there. So you go through the list, there was a list of FTP sites, and it would say, this has X11, GNU, this, utils. So you would connect to a random FTP site and those around.

So you're like reading off of a print off and typing in the FTP addresses. Yeah, yeah. That's how it works. So the way, there was no Google. There was a printout,

you know, a 200 page printout and you would pick the FTP site. It was called the FTP list or something. And it was essentially kind of an index.

The host name and what kinds of things they had, like two or three line description of each one. That's interesting. There they were, the GNU, and what kinds of things they had, like two or three line description of each one. That's interesting. There they were, the GNU people, giving away an optimizing compiler. Which other companies are making big bucks off of.

And I was like, why? Why are you doing this? And then at the time, we started reading also some of the news, and the Usenet at the time, or Mail English. I think it was called GNU MESC Discuss. And here was this compiler that was beating Sun's optimizing compiler. So I started writing the GNU manifesto and so on. So ever since I decided I'm going to help the GNU project,

maybe I can write code. At the time, I couldn't write code, or I wasn't proficient enough in Unix to do that. But I said, I'm going to go and help these guys. And I didn't have money because you can contribute in two ways. Give money or write code. Well, the money is out of the question. And the code, I don't know Unix that well yet.

So maybe one day. Anyways, that's how it started. And I think my first, I can't remember if it was, either I joined the Wine Project, and I was working with the Wine Project, writing the, you know, the Innie Reader. I don't remember that format. I don't remember the format. I remember using Wine. Yeah.

So my first contribution was writing that thing. And then it wasn't really GNU, but it was my thing. So I think I've been competing with Microsoft since 1991 or so because come to think of it I did the main and commander

in 1992 and that was already kind of my second thing and it was more serious so yeah maybe around 1991 and I've been competing

with Microsoft ever since started there right with the Windows emulation right we're going to bring those apps to open sources. We're going to run them on our system.

And then I worked for a while with the people doing open source Java. And that was an interesting, lots of interesting lessons on the dynamics of the community there. And then the Linux kernel, I worked for a while on the Linux kernel. I had this vision that workstations were going to be the future, that the Spark architecture was serious hardware,

as opposed to the toy PCs with their toy hard drives and their toy CPUs and their toy memories. So I worked on that for a while. You know, one day a friend of mine is like, you realize that a PC with SCSI in a Pentium is, you know, 10 times cheaper and is only half as slow. I'm like, oh. And I started to rethink.

Oh, maybe workstations are not the future. I had those experiences. But yeah, I've been competing with Microsoft through all kinds of things. I worked in the Linux kernel. Then I worked on drivers for the Spark and DSGI. And I worked with Ingo Molnar before he was world-renowned, famous on the RAID drivers for Linux. And then kind of the next challenge was, well, the kernel's in good hands.

What about the UI? The UI was just terrible. So let's work on the UI. And worked on GNOME for many years and in the GNOME office piece also for a while. Then Mono was, we built this Outlook clone called Evolution. Okay. And we went through a lot of pain building it.

And we said, there's got to be a better way. And Microsoft came out with.NET. It's like, oh, this is pretty good. So I kind of been working on.NET by this time. It's like 2000 or 2001. I can't remember the year now. But we started building.NET for the sake of building better Linux desktop apps. That was the goal. That was the reason.

That was the reason, yeah. It was evolution. Our app was called Evolution. Because the.NET tools were far superior to what you had? Yeah. So the history of GNOME is around the time there was this fairly influential paper or pitch that was made by a professor called John Osterhout. And he designed and implemented this language called Tickle. Tickle TK.

Tickle TK. Yeah, Tickle TK. And he had a very powerful pitch at USENIX one year where he said, higher-level languages achieve more productivity and fewer bugs than lower-level languages. It's something that resonated with me a lot. We wanted to raise the programming level and reduce errors and simplify our development and be more effective. If you're going to compete head-on with Microsoft, you've got to do that.

That's what you were doing. Head-on. But Tickle was, it's a language with some kinks. It was good for the time. And around that time, Richard Stallman says, if we recompile Tickle to Scheme, you're 10 times faster. There was a paper going around that Jewsnicks do that said, if you recompile everything to Scheme, you're 10 times faster. There was a paper going around that used Nix2 that said, if you recompile everything to Scheme,

Scheme automatically makes it fast. And, you know, minds were blown. Then it turns out many years later that the measurements were all busted and they benchmarked the wrong thing. But anyways, it was enough at the time to say two things. Let's use a high-level language and two, let's use Scheme. And the GNU project had their own Scheme interpreter called Guile.

And man, so when we started at GNU, we said, all right, we're going to build a desktop and we're going to build a core foundation, the high performance or performance sensitive code in C and the higher levels in a scripting language. And we started building some of the apps in Scheme using Guile. But it took forever to start up, right?

Launching Guile would be like four or five seconds just to get the prompt. So it was way too slow. So it kind of became a thing in GNOME that we would make our core APIs used in many languages. So Scheme was one. And sadly, the GNU project went into this way of developing where they work and work and work and never release. So, you know, it's not like Git where you can check out, right? Right. They would go dark and then you would get updates every few eons.

Like, are they coming back? Are they fading? Yeah, exactly. Are they gone forever? So that was painful. So then we did Python and we did Perl. You know, all these things were essentially how can we use a higher level language? It was even Objective-C. We even have Objective-C bindings for GNOME.

And I think one of the first IRC clients was written in Objective-C for GNOME, if you can believe that. That's very strange. So that was kind of the genesis of our thinking of we need to support more than one language. And what.NET made very interesting at the time was with scripting languages, they're incredibly powerful. Remember, this is the year 2000, no, 1997. So yes, they're powerful, but they're incredibly slow.

I mean, these machines have, if you're lucky, you have eight megs of memory, if you're lucky, right? At least most students, I mean, I wasn't lucky enough. So eight megabytes was plentiful. And then I was a sysadmin, so I managed to snatch a machine with 16 megabytes, right? But, you know, scripting languages were just not very good. And Java at this point was proprietary. There were two versions, a proprietary version that was semi-licensed.

And there's a long story not worth getting into it. And then an open source effort. But because there was one that was freely available, but proprietary, the open source one never caught on. There was just no need for it. It was proprietary, but free as in no cost. Yeah, proprietary, but cost-free, right? So the open source one struggled for many years

to get traction. So along comes that then we said, well, this is what we need. It has the characteristics of a high level language, but the performance of a low level language. That's what the doctor ordered. And unlike Java, it very quickly took off because there was no free.NET.

So either we built it or we didn't have it, right? So the community rallied around this thing. And very quickly we built a community of people that essentially replicated.NET. And that was a Mono project. So, you know, I've competed with Microsoft all these years. And, you know, there's ups and downs with Mono, right? Mono kind of struggled to find a niche, right? And the desktop, it was useful, but then people feared that it was like. Happened, right? Yes. There was a fear that Microsoft would do something.

So it really set it back. So we said, all right, let's let's aim Mono at the server. So we did Mono for the server. But then the customers were Windows people. I was like, I don't really know if I want to try Linux. So this is the era where Linux still hasn't really broken through. Right. But at this point, I think it's around 2006 and seven.

Yes, Linux is starting to get used, but it's not it's still not dominant. Right. It's still you still use Solaris for your serious deployment. Was there any was there a line of communication at all back in the earlier mono days with Microsoft? Was it all just like they- There were communications with a lot of engineers. A lot of engineers, program managers, mostly in personal capacity, it's never in official capacity. And then IBM, Sam Ruby from IBM, who later became a big Ruby person, oddly Sam Ruby, had invited us at the time, my previous company, to join the ECMA meetings because we had this implementation

of.NET that we had built from specs. And they said, well, who better to join the ECMA somebody actually has implemented the specs to, you know, iron out the details. So we did have contact through a lot of Microsoft people through the committee. I see. It was a common meeting ground around the spec. Yes. And this was around 2002, 2000. Wow.

These dates look so far away now. So, yeah, there was really no communication with Microsoft. So like I said, Moto kind of struggled with this, the community rejection for a few years. Things got worse when there was an agreement between my employer Novell at the time and Microsoft. So everybody's like,

there was a big conspiracy theory. So it was in a not place. It was an open source project. It was a great open source project with a difficult home, right? It was a difficult, we were in the middle of all these things. And then the iPhone happened. The iPhone happened. And so here's what is interesting.

Mono was sort of rejected by the harder line, free software, open source community people on this fear. But meanwhile, there were very pragmatic people outside of the Linux world, like people in the Mac world, that had no problem with it. One of those people were Joaquim Ante from a company called Unity. It was called Over the Edge Entertainment at the time. So Unity had a game engine written, and they had a great game engine, and they used Python to script their games.

And of course, it was too slow. So the games were very slow. So they ripped out Python, and they put the MonoVM in place and they got all their performance back. So it became, it was the same struggle that we went through. And this was around, I want to say 2006 or so,

roughly around this time. So there were a pragmatic group of people that had a genuine need for Mono. And there were many more, but Unity was a key one. And when the iPhone happens, Unity comes to us at this time, and say, hey, listen,

help us put Mono on the iPhone. So we put Mono on the iPhone. And then Apple changed the way that you had to run on the iPhone, which was a very challenging problem for us because Mono was a JIT compiler. Which was against the rules. Well, it wasn't at this point, but yes, it became against the rules.

It wasn't really against the rules. It's a kernel feature. So for security purposes, iOS and consoles like the PlayStation and the Xbox prevent you from JIT compiling. You know, it doesn't make the system completely secure, but it eliminates a vast series of attacks, right? completely secure, but it eliminates a vast series of attacks. And the fear is when you have a million of machines that are identical, running the same software, you can create a bot army. You hack one, you hack all.

So it was a security measure for these systems. And so we first put Mono in there, very happy, the JIT compiler runs. And then Apple disables this. And Unity comes back to us and says, hey, we have this product on iOS. We need.NET to be statically compiled. Can you do that? We're like, oh, that's kind of impossible. Well, let's think about it. And one of our guys, our team and one of our guys, Zoltan Varga, they went and made a static

compiler for.NET. And it was amazing. We gave it to Unity. And at this point, Unity is probably four or five employees. 45? No, four or five. Four or five, okay. Four or five guys.

I can sure hear that. Working at somebody's garage. Oh. And they shipped our product for iOS, built games for iOS using this thing, right? This 3D tech. They were the kings of the space. And within a year,

my Unity went from four or five employees at GDC, right? They had this booth on a, you know, a nine by nine or five by five space. And the next year they had one of the largest booths and there were 80 employees. Wow. So this is like early days of the App Store. Very early days of the App Store. 08, 09, that time period.

Yeah, I don't know when the App Store launched. But yeah, it was when the App Store launched. So it was a very popular product. And we said, huh, well, we did more for these guys. Maybe there's interest in.NET, not for games, but for apps. Yeah. And the alternative was using Objective-C. So we built with the same technology that we gave Unity,

we used it to build our own product. And it turns out that outside of the open source world, there really was no, nobody had issues with.NET technology, right? They all embraced it very quickly. So it was a very successful product. And that is the origin of what became Xamarin. And at that point,

we really stopped worrying about the fear of what could Microsoft do. And we kind of plotted around destiny. We said, well, people love.NET. They love the iPhone. And then we did the Android version. And people love Android. There's a big carrot, right?

Before there was no carrot, right? With the servers. Well, Linux, I don't know. But now you have this big carrot. You can write code very effectively for these two platforms on C Sharp. And it's better than anything else. So it took off. Yeah, you had a winner in your hands.

And then so I would say that at that point, we sort of stopped competing with Microsoft, because there was really no, I mean, we're building a product in the market that didn't really exist. It was no longer a, we'll bring Microsoft tech to Linux, it was we're bringing Microsoft tech to iOS and Android and nobody really in that space. People were there to make money. They were not there to, you know, fix the fundamental flaws in society. Idealistic reasons. There were capitalistic reasons to be in the other half.

Yeah, I mean, people were there to make money. And so it was a more pragmatic crowd. So, yeah. And I guess I stopped competing with Microsoft at that point, and it was more like a very good compliment to what Microsoft was doing. This episode is brought to you by GitLab and their Global Developer Survey for 2018. They're doing the survey to inform the larger population of developers all across the world about the needs of modern developers, their current satisfaction with management, tooling, workflows, trends at work, and more, perception discrepancies between developers and management,

and most importantly, what high-functioning development organizations are doing differently. Their 2016 survey uncovered that developers have a lot more say in choosing the tools they use, and often they were using tools their managers weren't even aware of and this survey we're asking you to take was vetted by 10 internal GitLab engineers to ensure it's high quality and highly relevant to developers. Topics in the survey include developer satisfaction, open source technology, workflow and collaboration, CI, CD practices, and developer tooling and their preferences. If you have insights to share, we'd love for you to inform the global developer community and please consider taking the survey.

The entire survey includes around 25 required questions and a handful of completely optional questions for you to share a short answer with more details. The survey takes around 15 minutes on average to complete and you can find it at about.gitlab.com slash developer dash survey. Once again, about.gitlab.com slash developer dash survey, or check the show notes for a link. And by TopTow. TopTow is the best place to work as a freelancer or hire the top 3% of freelance talent out there for developers, designers, and finance experts. In this segment, I talk with Josh Chapmanman a freelance finance

consultant at toptow about the work he does and how toptow helps him legitimize being a freelancer take a listen yeah in my arena within toptow i specialize in everything from market research to business plan creation to pitch decks to financial modeling, valuation, and then that leads very naturally into fundraising strategy, capital raising strategy, investor outreach, closing a deal, deal negotiation, how to value the company, how to negotiate that. And all those skill sets that I have continued to hone over on the TopTal side are ones that I actually deploy every single day in my own company. Freelancing can sometimes be seen as not legitimate or subpar work. Now, I would argue that when you work with a company like TopTal, they put so much vetting into not only the companies that you work with, but also

the talent that you work with, which I'm on the talent side, that it adds a level of legitimacy that isn't seen across other platforms. And that for me, as the talent side, is incredibly fruitful and awesome to be a part of, right? I enjoy the clients. I enjoy the other talent that I get to talk to. I enjoy the TopTal team. And that creates an overall positive experience, not only for TopTal, but for me as the talent and for the client as the company on the other side. And that is really not seen or is the experience across other platforms in the freelance market. So if you're looking to freelance or you're looking to gain access to a network of top industry experts in development, design, or finance, head to TopTal.com. That's T-O-P-T-A-L.com

and tell them Adam from the Change Law sent you. For those wanting a more personal introduction, email me, adam at changelog.com. So what was your personal demeanor towards the company? Because when you say you're always competing, but was it antagonistic or was it in good spirit of competition? I think it went through a few phases. For example, very early on, very early on when I was, you know, I was a very big open source advocate. And I did all kinds of advocacy

in Mexico and third world countries. And I had my pitch nailed to why you should use open source instead of- Can you remember some of it? Yeah, of course. I'll make the pitch in a second, but- Pitch it.

I want to hear it. You know, the pitch at the time was very simple. Listen, we're sending all kinds of money outside of the country for running proprietary software. Let's not do that. Let's invest that money in the country. Let's use open source. Let's build that stuff, right?

And I used to say, listen, how much is that? You've seen a barrel of oil, right? So how many barrels of oil does a country need to ship outside to get a single license of a piece of proprietary software, right? It's a powerful image. And the idea works great up until the point that you realize that people, they're not going to send the money. They're going to spend it on something else,

or they're just not going to spend it. So the idea that you would reinvest in the country didn't really pan out. People were not going to spend it on something else or they're just not going to spend it. So the idea that you would reinvest in the country didn't really pan out. People were not going to reinvest. If you don't have to spend the money, don't spend the money. Keep the money. We'll spend on education.

We'll help our people. We'll do these things. And that didn't necessarily. But anyways, that was my pitch at the time. Right. And, you know, there would be places where we would have a panel, why you should use Windows versus Linux. You should use Linux because... So I did advocacy, very serious advocacy for many years. This is 2006, 2004, a long time ago,

very, very long time ago. Very, very long time ago. So did you find... 2001. That was easy, right? You get Windows 95, you get Windows 2000, and you got Linux, right? And then just recently, I mean, it was really pretty recently,

almost two years ago, which seems recently in the long span that Microsoft acquired Xamarin. Once you were no longer competing with Microsoft, did the edge wear off, or was it? Well, I think that there were two things. There was the early competition in my, I would say, almost, not team, because I'm older than that,

but the Windows 95 era. The 95 era is very clear. They have a great UI, but the Windows 95 era, right? 95 era, it's very clear. They have a great UI, but we have multitasking and we don't crash. And we have, you can use one Linux machine to be a server for everything. One PC can do it all. It was amazing, right? So that was one kind of one era of unfocused, the one that I described. And then there was the uglier era when open source kind of becomes a brand.

And I don't know if you remember this, but there were the Halloween papers, which were internal Microsoft documents that says, how do you compete with something like Linux? I don't remember that. They were kind of a big scandal because they got annotated. I don't think it was, in retrospect,

I don't think there were ever very serious documents, but somebody in a massive organization wrote papers saying, hey, well, this is how you do it. You write dozens of these things continuously, right? There's a lot of internal memos, recounts. But it became seen from the open source perspective. It was seen as like, oh, my God, this is the evil empire. Yeah, kind of like that.

And it was seen that way. And that didn't foment a environment, you know, a great environment. Yeah. You know, there was this notion, the price was, you know, Microsoft is toast, Windows is not going to exist, Linux is going to, you know,

it's going to take over the whole world, right? Right. So there were a lot of very nervous people. And in particular, the whole world, right? So there were a lot of very nervous people, and in particular the previous CEO was fairly antagonistic toward Linux for many years, or took an antagonistic position towards Linux and the GPL. But I think, A, it's a little bit like that diagram of,

I don't know, it's one of these analyst firms that use the hype graph, right? Where you have exceeded expectations. And then it comes back down. And it comes back down. And then once you understand, it's like, oh, everything is terrible. And then you kind of understand. The trough of sorrow. Yeah, the trough of despair or something like that, right? So what happened is that over the years, the hype of what was open source, eventually people understood what it was.

And both us and the industry, right? Both us, the advocates and the industry, and we understood what it was and what it could do and what it couldn't do and where it worked well and where it didn't work well, right? Even Red Hat went through this process, right? So I think that the thinking internally at Microsoft started to change,

and Microsoft started to open source a lot of things. Bit by bit, right? Somebody was asking yesterday, what are the things that Microsoft open sourced? And they were kind of thinking towards 2010. It's like, no, no, there's stuff that went back to 2006, 2005, they did little bits, right? They did little pieces. It's like, no, no, there's stuff that went back to 2006, 2005. They did little bits, right?

They did little pieces. Testing the waters. Testing the waters. Those might have even been somewhat grassroots efforts inside of the company back then. I think they were grassroots efforts. There were people inside the company that believe in the model, and they push for the model, and they make a case. And I think that at the time, making a case was very tough, right? The environment was not necessarily supportive.

Now it's very straightforward to open source a piece of tech at Microsoft. There's a pipeline, a review process, very straightforward business needs. You fill in a form, your manager approves it, off you go, right? Basically, yeah. You need to make a case that you're not doing something. I can't

just go and fill in a form to open source Windows, right? But if I write some code, I can certainly do that. On that note, there was one point in your career you mentioned. I think it was when you were being interviewed, I think earlier on in your career, towards Microsoft, and you had, on this advocacy of

open source, you mentioned that they should open source IE. And this is way back in IE's lifetime. And you were kind of using Netscape as a case study of like, hey, this is what they're doing. Can you kind of pontificate? Netscape actually happened later. They were not open sourced at that point. Yeah, there wasn't, I had an interview with Microsoft.

I was working on Linux on the Spark, supporting Linux to the Spark. So a friend of mine, Randy Chapman, said, hey, we're working on porting IE to the Spark. And they're interviewing here. You want to come? And I came and I interviewed with the people. I don't know who interviewed me anymore. But I made my pitch. You should make IE open source.

That was my pitch. Make this open source. There's all the benefits. And I think they just said, all right, whatever, dude. So we heard a story that. But remember, this is 1997. Right. And Mozilla doesn't go open source until 1999.

Right. At this point, Mozilla doesn't go open source until 1999. Right. At this point, Mozilla is still proprietary. We've got alternate, I guess, influences on this side too. We've got Brendan Eich on record talking deeply about the funding of the browsers and the funding of the web through, and I'm only paraphrasing this big story he knows very intimately, but just the browser wars and ads and how everything has been paid for, essentially. Long story short, but I'm trying to figure out if you've got some sort of idea of how IE or even Microsoft might be different as a company

and maybe even how we may be different had they done what you said. Because they didn't. That's so difficult. That's one of those hypotheticals that are very tough to answer i mean remember at this point i was a very strong advocate this is my my hardcore years of advocacy and uh and coming to microsoft what's kind of i'll go to microsoft if i can change the company from the inside right kind of thing um so and i wish i wonder if hr still has notes on. I wonder if we can dig those up.

That'd be awesome. But essentially the, you know, that was my pitch. We've got to make this open source, right? And, you know, I think that the people that I was talking to, you know, they're probably engineering managers, like whatever. It's crazy. Go and do a link list on the board, right? I don't know what we did.

Go and do a link list. Solve this programming puzzle. Before we do one of those, go do this link list on the board. So when you say interviewing, you mean to work there? You're interviewing to work there. Yes, that's right. And you're trying to tell them to open source. So you're giving them high-level strategic advice during your interview to work there.

Well, he said if he's going to go there, he's going to change. Well, I realize that. But when you first said interview, I was just thinking it was like an interview like this. Right, right. That makes it even funnier. You were, in that sense, very hardcore advocacy. Fast forward to today. Are the things that you, inside of the industry and software,

are the things that you care about with that level of passion now that are different? Or is that like a young man's energy that slowly subsides? Well, I mean, I still care very passionately about the, you know, there's things that I care about in tech and things that I care about outside of tech. And I think that my advocacy and my heart breaks for all the disasters in the world, right? So, you know, if you follow my tweet for years or my blog, you'll see that there's a particular series of injustices that have, you know, Palestine has always been a very sad story. So, you know, I still care about those things.

Sure. And, you know, I think they got really the short end of the stick. But there's countless other problems in society that need to be solved. And, you know, we have a lot of really smart people. And we should be fixing those issues. So I think that the passion and the desire to go and fix those things is there. Having kids certainly doesn't leave a lot of time to, you time to sign up for doing talks and advocacy in places.

But there's one of my co-workers, Nia Veddin, she runs the Invisible Summerville organization. And they're doing all kinds of very interesting social changes in our community, right? They start there and they take it elsewhere. But I think that just having a family kind of takes a toll on your time for doing some of the more advocacy things that you want to do. On the tech world, I would say, before I go there, that one thing that was very interesting is that the new CEO is very different, Satya Nadella. And not only he embraced the change in Linux and open source, these things, but he is, as an individual, is deeply empathetic, right? He relates to other people and he tries

to get himself in other people's shoes and try to understand their perspective. So from the tech perspective, I like to think that we can do more in our software to be more empathetic. And I think that it shows beautifully, for example, with Apple products, because they're products that people love to use, right? They work for the user, not against the user. And it's a different mindset that the raw engineering perspective of, I'm going to build a piece of great software, going to be very fast, very efficient, very something, right? Very configurable, very programmable.

It's going to be the Swiss Army knife. And as it turns out, there's a time for the Swiss Army knife and there's a time for just a bottle opener. Right. Sometimes all you need is a bottle opener. Right. Right? Sometimes all you need is a bottle opener. A single purpose tool. Yeah. And so in tech,

I kind of care passionately about how can we make our tools better, simpler, more accessible, more easier to use? How do we make developers happier? Right? It's been kind of a motto for our company, for Xamarin, it was definitely. And we tried to bring that culture, which is how do you delight developers? How are developers struggling and what can you do to get out of their way?

And I have to say, I'm guilty as much as anybody else. We've built tools that are sometimes too complex. And how do we remove the complexity? How do we make our tools simpler? So I would say from that perspective, I changed from advocacy from licenses, which is, you know, it's a done deal. It's a battle that has been won, right? And I really try to look for inspiration on design, right? And what can we do for the user? And I'm saying design because now when I work with other teams,

companies, partners, people inside the company, we still have a mentality, all of us, where if we need to build a solution, we start coding right away. Okay, let me architect this, log in, I'm going to put this in the database, it's going to go here, I have a screen, I roughly know where things go. So you go through this process, and then your user experience is miserable, right? So I do like this, I do like the idea of, you know, let's first sit down and try to understand what problem we're trying to solve. Let's design,

let's design on paper, right? Let's think about it first. Yeah. And, you know, there was an employee of mine, well, not an employee of mine, a coworker of mine from many years ago, Anna Dirks, that started this at our previous company at Novell.

And she would prototype on paper. At the beginning, I was like, why are you doing high tech on paper? Right? We're software engineers. We don't do paper. But, you know, she was a big influence because she would meet with customers and she would show them, okay, here's a UI that I've drawn on paper. Here's a menu. What would you do next? I would click here.

Wow. All right, what would you do? And she would put Post-it notes. So now this is a button, what do you do here? And the nice thing is that it's super cheap to prototype on paper. Oh, yeah. Right? What does it cost? Like a couple of cents in a pen?

Yeah. Right? It's real time. There's no bugs. And then you get a mock-up. At the end of the day, you spend one work day. No crash. Yeah.

One work day, you get mock-ups. And then you refine them a little bit. Right? And then you get good design. And by the time you're implementing, you're not writing and rewriting and rewriting and customizing. And when somebody says, well, you should have this button, like, well, if you want me to wire that up, I got to change everything. It's like, you know, so, you know, as engineers, we have to embrace this world where we can think first about the user,

you know, show some empathy, right? That's what I like about Satchez and his whole pitch in his book, the Hit F5 Refresh, right? Is we got to do, you know, get into your user's shoes and try to do what they're going to do. And save yourself a lot of time, a lot of engineering

by knowing what you're going to do. So I care a lot about that. I don't know that I communicate that always as well as I could, even to my team. Hopefully this podcast will influence that a little bit. Just tell your team to listen to the ChangeLog. We can do that. Or you can talk to them directly, I guess.

It's your team. We're going to make things easy. When you talk about that, especially when you say Xamarin, the focus on the users are the developers and so let's design for them. It reminds me of Matt's with the Ruby programming language.

His design philosophy, I feel like his statement, I'm going to design for programmer happiness will be his legacy even more so than the language that came from that. Cause language has come and go, but like that I've seen that philosophy embraced and it resonates so well with all of us. It's like, yeah, we should do that. That's, that's, that's empathetic. That's empathetic. That's powerful. And so that idea, I love it being such a meme because as it spreads, we all benefit. And if the developers are more empowered, more able to do things, enlightened, designed for.

Delighted. Sorry, not enlightened, delighted. Sure. Then they're going to, hopefully that's a pay it forward type of a thing they're going to be more able to build things for other people in such a way I think we need to become more rounded individuals

software engineers should say where's the design help me not waste my time tell me what I'm building what are the expectations here perhaps I also care a lot about the expectations here. And why, yeah. Perhaps I also care a lot about the fact that sometimes we write code with no documentation.

Engineers are really, they have this thing where they're like cats in water. They don't want to write docs. Cats in water. They don't like it. Cats don't like to write documentation either. Cats are in Nebraska, but cats on the East Coast. They don't like water. They don't like it. Cats don't like to write documentation either. Well, I don't know how cats are in Nebraska, but cats on the East Coast. They don't like water.

They don't like water. That's how easy it is. They don't like to write documentation in the water. Engineers on the East Coast and documentation is like, oh, you know, they do it. Only if I have to. Yes. Only if my boss forces me to, and then I'll drag my feet, right? And engineers are very good at coming up with excuses, right?

It's like, I'll document it. I'm still changing things. I'll document it when it's fully ready. And then by the time it's ready, it's like, what happened? And then they go, well, do you want me to document or do you want me to work on the new feature? Right, I ran out of time. I mean, it's magical.

And it happens every time. It's magical. I guess my last question for me is surely you do a lot of conversations like these is there a question or a topic or a thing that you just you're just waiting for somebody to ask it to you so you can answer this thing

or talk about this particular thing but nobody ever does at my age every question is a good question. You don't have anything to get off your chest or anything that you just want to talk about? No, not really. I mean, I guess, no, not really. I don't have anything to get off my chest.

Fair enough. Let me close with one thing. So what has been fabulous is in this new Microsoft, just how much open source code is written by Microsoft and contributed to Microsoft to the point that, the other day I saw the stats and it's like, they're ginormous numbers. I think GitHub published them.

Microsoft I think is now the number one contributor by some metric. I don't know what it is. I don't know if the number matters anyways. It's so much go that... It's an indicator of change. It is an indicator of change, yes. And I am very happy that.NET went from being

the crown proprietary jewel of Microsoft to now be open source. And that Microsoft was willing to let go of this fabulous developer technology and their incredibly sophisticated compilers and runtimes and garbage collectors. I mean, and they went with a license that is beyond generous. It's just MIT is, it's a gift to the world. And it took years of work of many people inside and outside and advocacy and discussions. So there's thanks to be given to everyone that made that happen.

And.NET now it's everywhere. It runs from my watch to my phone to the servers to the Azure supercomputers. We have it running WebAssembly 2. I mean, it runs on everything. It's just- WebAssembly 2, huh? Yeah, we got WebAssembly 2 now. So it's everywhere.

And it's a fantastic effort. And I hope we can get more people building software there. I mean, our goal is always, you know, going back to this theme from 20 years ago, right? The goal is, or maybe less, 17 years ago, is we want you to write good software. We want to catch errors for you. We want your software to be of high quality.

How can we help you? And that's a mission, right? That's what the entire developer division of Microsoft does, right? That's a mission. And I think we're making a good dent in society that way. All right. Thank you for tuning into this special episode of The Change Law. We did this show in New York City, Times Square.

Thanks to Microsoft for inviting us up there. It was a blast being in New York. episode of the change law we did this show in new york city times square thanks to microsoft for inviting us up there it was a blast being in new york and getting to see the behind the scenes of microsoft connect what a well-run excellent conference for them and their developer community and all the announcements it has so much happening it's a new microsoft if you enjoyed this show share it with a friend rate rate us on Apple Podcast, and thank you to our sponsors, Circle CI, DigitalOcean, GitLab, and TopTile.

Also, thanks to Fastly, our bandwidth partner. Head to fastly.com to learn more. We host everything we do on Linode cloud servers. Head to linode.com slash changelog. Check them out. Support the show. The changelog is hosted by myself,

Adams to Kovac and Jared Santo. Editing is done by Jonathan Youngblood and the awesome music you hear on every single show is produced by break master cylinder. You can find more shows just like this at changelog.com or by subscribing to podcasts, overcast, wherever you get your podcasts thanks for listening