All right, good afternoon. My name is Darin Adler. I'm the manager of the Safari and WebKit engineering team at Apple. And I'm gonna talk to you a little bit about the WebKit open source project, something that just went online Monday this week, late Monday night. So we're basically taking a whole new approach to open source with the WebKit, different from what we've been doing in the past. And we want to tell you all about what we're doing different. And this is our first chance in person to answer people's questions about it. So I hope we can answer some of your questions. So let's start with a little information about history.

The first moment in WebKit history is when we began the Safari project. So way back in 2001, we began Safari project. At the time, it was an internal project, secret at Apple, and we chose the KHTML open source library as the basis for our project. Then a little bit later, in 2003, we made our first public release of Safari. That was the Safari beta. We announced what we were doing, And we made our first release of the open source components, WebCore and JavaScript Core.

So then later that year was the release of Safari 1.0, our first production release, non-beta. And it was also the very first time we released the WebKit framework, which was an API for doing the same kind of web engine stuff from inside Safari, but doing it in any application. In October, we--the release of Mac OS X 10.3 Panther was the very first time that Safari and also the WebKit were included with an OS release.

Then February of the next year, we released Safari 1.2. And there were lots of new features in Safari 1.2. The one I've decided to mention here is XMLHttpRequest. It has been the basis for some really important development. You'll hear people talking about that a lot tomorrow when you go to the sessions about the WebKit and Safari.

In June of 2004 was last year's developers conference. And at WWDC, we released a preview of two new versions of Safari, 1.3 for Panther and 2.0 for Tiger. And there were some new stuff that was unveiled then included the Canvas element, editing in WebKit, and also the dashboard using our technology for the very first time.

And the dashboard's particularly exciting because it's so different from a web browser yet using the WebKit technology. Then in April, way, way back in April 2005-- can hardly remember it-- Mac OS X 10.4 Tiger was released, which included Safari 2.0, and we also released Safari 1.3 at the same time as part of Mac OS X 10.3.9 with very similar features from the point of view of a software website developer. And here we are today with the WebKit Open Source project, which I'll tell you a little bit more about. So let's think back to before this project. How did we do development? And when I say "we," I'm talking about the engineering team building Webkin and Safari. Well... We had two frameworks. One was called WebCore and the other is JavaScript Core. And they were based on the KHTML and KJS projects from KDE. And we would publish the sources to each of these. And typically we'd publish them-- well, we always would publish them whenever we made a source code release, because we wanted to do that to make sure we complied with the license. But we also would publish them from time to time when there was some request or some major change that people wanted to see. We also had a mailing list that people could use to discuss the project, ask questions about it, or make contributions.

And the problem though when it comes to outside contributions is we really didn't do anything to make it easy to build the thing or test it yourself. It was really just the source code and some people did some really big things with it. At least one company built a product out of it. But it wasn't really easy. It was really something that took some doing.

So what we decided to do was something that we think is really big. Here is a picture of what we had before. There was the WebKit framework built out of the... The WebKit framework was built on top of WebCore, which included the KHTML rendering engine as well as the KWQ library that bound it to the Mac OS. That, in turn, was built on top of the JavaScript framework, which had both KJS, the JavaScript engine, plus some other open source components to make the whole thing run. And that's what was open. But as of today, we have opened the entire WebKit. Now this is huge, because before what you had were some pieces that really by themselves didn't do anything unless you added a lot more.

At this point, with the WebKit open, you can see everything that matters inside the engine. All the relevant code is there. There's a lot of things you would have had a hard time figuring out without the WebKit source. And everything that is not open that you need to build this is now in a thin layer that we call the WebKit system interface. And a binary for that is included. So this allows you to actually build the WebKit very easily and run a copy of Safari against your new WebKit or your own application. So, yeah.

Being more open like this means a lot of things. Here are some of the things it means for Apple. And this is just a tiny assortment of some of the things it means for us. One is that we think there'll be a lot better testing. We do as much testing as we can, but a whole lot more people have things that matter to them that they can test. And we've experienced this with other open source projects, the things people care about the most, they come in and test and try out. And we expect that regressions and mistakes we make will be caught a lot earlier. And in particular, we'd have this experience before that right when we released Safari, there'd be sort of a frenzy of testing energy. We'd find all sorts of things that we would have loved to know just a few weeks earlier or a month earlier so that we could have had our release be better quality. So we expect much better testing. In addition, there's a possibility for more eyes on the code. As the changes happen, people are going to be able to see the changes. And they're going to be able to check if we're correct, check if we made security mistakes. People already do this, but we think they can do it in a much bigger way. And we also think that there's a possibility for richer participation, people who want to get involved. There's any number of different ways to get involved, very few of which were possible before, all of which are possible now. Now, there aren't just benefits for us. There are some benefits for developers and our community as well. For one thing, you now have access to the source code. You can see each engine change as it's checked in. You can try out a build long before the general public has that build on their machines, before the average Apple customer has it.

You also get access to us. You get access to the developers on my team and also the outside contributors who are developing. And so that means, let's say you want to contribute a bug fix. You're going to have those reviewed by the people who know the code best. You can also have influence on what the WebKit people do. Some people are going to show up and just have a conversation, and those conversations can have a big impact on direction.

And finally, this way of opening it, this way of opening up source means that you're really invited to participate, to get in there and fix things that bother you rather than just having to live with them, and just be a part of a community that together is going to determine the future of this software.

So now that things are more open-- sorry. What I want to say is, when I say things are more open, let me get down to some of the details of what's new as of this Monday. First of all, we have a brand new developer website, and it's at webkit.opendarwin.org. And I should take this minute to say that this whole open source project would not have been possible without the help of the guys at opendarwin.org that already had experience with this sort of stuff and helped us in tons of different ways. And so this website is your gateway to information about the project. A lot of the things I'm saying here today are set on the website. It also tells you everything you need about all the other resources. And so the website is kind of the crucial bit. Besides the website, we've now got a public CVS repository. So there's both anonymous CVS for most people, and then also read/write CVS for people who have commit access. And this public CVS repository is how you can see the changes right as they happen. If I fix a bug, a few minutes later, anyone who wants to can pull down that bug fix.

There's also a developer mailing list, and the information is all on the website, so you don't have to worry about these URLs or mailing list addresses, but there are actually three mailing lists, and all at opendarwin.org, and this is the list-- this here, WebKitDev, is the one for discussing WebKit development, just kind of the general place.

In addition, there's an IRC channel for developers. And you can hop on there any time of day, and there'll be someone there discussing WebKit. I mean, I cannot tell you the huge number of people that are hanging out on that channel and all the things they know about WebKit that I'm just amazed by. And this has literally been open only for less than 48 hours at this point. It's almost intimidating how many people are on there. I mean, there were like 150 last time I was on. And it's pretty exciting. And I think that's really a great place to go to kind of get the pulse of the project. Some of the people there are just lurking. Some of the people there are actively working on the project already. And our own developers who work on WebKit will be there to talk to you.

And then finally, there's a public bug database. Now, this means--this is a place where you can report bugs, and it's different from Apple's internal bug database in that you can see the whole thing. You can see every bug. You can see the state of the bug. And it's one of the things that really helps people who want to help fix bugs go look there to see problems, and people who want to report bugs will report them there. But more about that later. So all five of these things are new as of Monday. They're all online, and check them out.

So we made a bunch of other changes, too. It wasn't just that we created these five things. First of all, we made it very easy to build WebKit, WebCore, and JavaScriptCore. You can... People have done it who really don't know much about programming. If you know a lot about programming tools, it'll be even easier. And as I mentioned earlier, the changes you can now see as we check them in. So before we had open source, you could see our code, but you didn't see the changes until...for quite a while. And we went the extra mile, and we included the complete CVS history from the very beginning of the project. So not only can you see our current changes as they're checked in, but you can go back and say, "What happened on this day in history, "2003, 2002, whatever?" And there are various reasons you might be interested to see that evolution.

We're doing a lot of things to encourage contributions. This is new. The website talks about how you can get changes integrated. And the very first change that was integrated was a fix for a small memory leak that we got within, boy, within hours of being online. And already we've gotten all sorts of interesting changes. This is different. We're really encouraging this in a big way. And not only do we have this mailing list and IRC channel, but it's really a place we're hanging out. People have already been there and know that we're there, reviewing patches, talking to people, all that sort of thing.

So when I said you get to be there on the channel and meet some of the developers, I really want to take the next step and show you face to face a couple of the people that you'll see there. So these are also the guys who did most of the work to make the whole open source project possible. So come on up on stage. First, Dave Hyatt, who is one of our Safari and Webkin engineers.

And who's super famous because of his great blog, Surf and Safari, and all of his web expertise. And then Maciej Stachowiak. So Maciej is another engineer on our team. And he really-- he did more work than anyone else to make this open source project possible. So anyway, let me hand it over to these two guys. Do you guys have your microphone yet? On the podium. Oh, OK. Right over here. And they'll show you what it takes to download and build the WebKit.

All right, so what we can show you here is the instructions on the website for building. And then Maciej here can actually try it. And we'll see if it works. I have to warn you, we haven't practiced this a lot. So much like real open source projects, we're sort of making this up as we go along. So bear with us. Just a second. Can we get back to the demo one machine? Is that text readable for you? Yeah, it's great. OK. So developer tools we already have here. I'm going to launch the terminal so I can do these other steps.

Terminal. I'm just going to cut and paste these instructions from the site because I'm lazy. You can do this too. Real typing is not required. So what we have here is an anonymous CVS server so that even without write access you can pull the code. And it's basically you just log into the anonymous CVS site and the password is anonymous.

checking out. So you just get one module that knows how to update all the others. And here we go. It's all checking out. It would take less than a minute to pull a whole rendering engine, which is pretty small for code that does so much. There's not that many exciting things I can say about the files flying by, so there they are. This is one of our test suites. This is mostly test cases here. This is one of our test suites. We're big on testing. We'll talk about the regression test more later, but we have just a huge suite that we're building up of all sorts of tests, both ones based on the spec and then one based on reduced cases from real websites to try to keep things going forward and not regress as much. You guys are having the same bug I have at home. Makes each directory go slower. I don't know what it is. Yeah. It's a lot of people checking out the code. Yeah, it might take three minutes instead of one.

This is all layout tests now. And now we're up to the test suite for WebCore itself. The last one was the JavaScript test. Oh yeah, you can make the terminal font bigger. Gives you plenty of time to do that while waiting for the staff. Window settings. Oh, fonts, that's better. Just bigger. Just bigger and smaller. Sweet.

Go back here. All right, it's all checked out. That's it. So now I'm going to try to figure out how to build this thing. Oh, look, there's a handy link here for building the code. And much like checking out, it's very simple. It's just one line. I'm going to set the Xcode preference first. Oh, right. First I have to-- see, I'm not so good at reading. He started with step two. Don't skip step one. Remember to actually read the instructions, unlike us. Yeah, building has a first time step. You only have to do this once in Xcode. It's important to set a common building Building panel and preferences. Place build projects in customized directory. And I don't know what this user's username is. Let's see. Users Apple. All right.

Users, Apple, slash build. These need to go into a common directory so that all the different projects can find each other, 'cause it's built out of multiple frameworks that all need to link together. So there's that, and... You probably should make it. Okay. Details. It might not matter, but, you know. But I'll fire up the build now. and Hey, Dave. Let it get going. Make him talk into the mic. Stick the mic in his face. OK. I'm firing off the build now, and we'll let it go for a while, and give the floor back to Darren. OK, let me know when that thing's done, because we'll be able to go back to you. So back to the slides, please.

So there are a lot of different ways to contribute. And I wanted to just talk a little bit about some of the ways you could do it, just so you can start imagining what's possible if you'd like to contribute. So let's first talk about testing. The main thing you want to do to test is get the latest stuff.

That's what's special about the open source project. You can test the latest. You don't have to test our last release. So you're going to need to download the source and build it and try it. And after today, you're going to know what it takes to do that. You do have to go into Xcode preferences, but that's probably the hardest thing in the whole process. And then we'd really like you to report the bugs that you find.

And there's all kinds of tips on the website that tell you what you need to do to do a good job reporting bugs. And bugs are just like gold to us. They help drive other volunteers to know what to do. They help our team know what to do.

But you can even go further. We have a whole test framework. And if there's a particular bug that you want to make sure never gets reintroduced again, you can create a test for that bug. And then we promise we won't let anyone check in any code that breaks that test. And it's pretty straightforward to make tests as well, so we're hoping some people will do that.

Now some other people are not going to want to test. They're going to want to write code. It's a lot of fun. It's part of why I do this. I just love programming. And there's all kinds of different types of coding tasks you can do to help us out. One is just fix bugs. You can go on there, find a bug, figure out how to fix it. We'll show you a little bit how to do that today.

You may have an interest in some other platform besides OS 10, and we welcome people who are interested in porting to other platforms. Talk a little bit about that to you. And finally, this is the Web Engine, and you're welcome to add what we think of as Web Engine features. These aren't really browser features.

They're not features from the point of view of the end user. They're really more like bug fixes, getting us to be more like other browsers, or completing implementation of technologies that are under the hood, and to the end user isn't a feature at all. But we'd love for you to add those things to our engine.

In addition, there's so many other ways to pitch in besides testing and coding. And I just put a list of a few I could think of right away. But one of the best things you could do, one of the most valuable things in the project, is just show up on the mailing list. Show up on IRC. In no time, you'll be an expert and start answering some of the questions that other newcomers have. This is one of the most valuable things any open source project could have. And we'd love for people to do that.

Another thing you can do is take a bug that just says this website doesn't work and reduce it down to a minimal test case. That's another incredibly valuable thing. A minimal test case is easy for someone who knows the code to write a bug fix for. You can also go through our bug database. You'll find that there are bugs reported there that have already been fixed. You'll find duplicates. All of that helps out.

Also, and this is something people have already been doing, you can tell us what needs to be improved on the website and give us content to improve the website itself that we'll put up there. And the documentation about the code we think has a long way to go. And this is one area where if you go through something, you figure out a bug, you decide to help, we would love to improve the documentation so it covers what you learned. There's a lot more ways, but those are just a few I was able to think of.

One of the big things that this changes is that you have more options now when a bug is bugging you. Before, pretty much you had one option, report it to Apple. There's a feedback forum, and there's your second option. Or you can write angry email to Steve Jobs, my favorite way of reporting bugs. I just love it when Steve sends me. But there are a lot more options now that weren't there before. So one of them is you can discuss your bug with people or expert on WebKit. And that means you can send this to this mailing list where there are WebKit experts, both inside and outside of Apple. And this is just something that was absolutely out of the question before.

Another thing you can do is if you have the interest and you have the skills, you can actually fix the bug yourself and contribute a patch. And a lot of times, a bug that's affecting you is something you understand a lot better than anyone else. And so we're really hoping that in some cases, this is what people will do when a bug is bothering them. One of the reasons that open source is so great is that it really allows people to kind of scratch their own itch, fix what they don't like about the software they're using. And that's an option available now that just, you know, really was not practical before. Now, another thing you can do when a bug is bothering you is you can go over to the WebKit Bugzilla bug database and put a bug report in there. There's a lot of benefits to that. First of all, the other contributors to the WebKit-- Okay, it's done.

He said to tell you. Oh, man. That's horrible. Oh, shit. Did you build the whole thing, or is that just part of it? Yeah, that's it. That's the whole thing. That's all it takes to build the whole engine. Okay. I really should have slimmed down my talk a little bit. So let me just finish what I'm talking about. So if you make a report in the Bugzilla bug database, everyone can see the problem you described. Other open source contributors can get in there and fix it for you. and you'll also be able to see the process as people argue, "But that's not a bug at all. "That's how it's supposed to work," and all that kind of stuff, and you can defend yourself. But there are times when you're also gonna want to put the bug report in the Apple internal bug database. Let me tell you about a few times. It reveals something that you would prefer only you and Apple know about your product. If you're in that situation, feel free to put that in the internal bug database. It's not--the open source contributors aren't gonna see it, but we'll get that feedback and that information. Another reason to use the internal bug database is that products other than WebKit, let's say the mail application or the Safari web browser, bugs in--the WebKit bug database is not the place for those. So if you want a new menu item in the Safari menus, it really needs to go into Apple's internal bug database. And we'll have to--you know, I'm sure that'll confuse people at first. We're gonna have to move bugs out of Bugzilla into the internal one. And another thing is if--if-- we use the Apple internal bug database to plan things like software updates. And so if a bug is particularly-- has a particularly impact on one of your products, you may want to write a bug in the Apple bug database and mention the Bugzilla bug report so that we can--so we can consider that when we're considering software updates and that sort of thing.

So you now have all these options. I'm not even sure I covered them all. But when a bug bugs you, you can do any of these things. So Maciej and Dave are now going to show you what it takes to fix a bug. All right, so now that we have the tree built, let's try running it just to see if we can run Safari with the new WebKit. You have to run it from the WebKit tools directory.

I think there's a script sub-directory in WebKit Tools. We haven't gotten a lot of sleep the past few nights. So there's Safari running. Do you remember the Acid2 test URL? This is just to prove that we're actually running the latest code. This is a new CSS and HTML conformance test that was recently created by Ian Hickson that Dave did a bunch of fixes for.

You can see it in action. There it is rendering correctly. Ooh. Now you too can have it on your machine. And now Dave's going to find a bug in Flexzilla and fix it live as you watch. And then I'll review his chains. We hope this works. I sure hope this works..

Make sure when he's talking, it's in the mic. --as a pretty basic HTML for compliance bug. The object element-- you can note that the object element doesn't support a handful of attributes, including align, V-align, H space, and V space. And a test case demonstrating the problem is actually attached to the bug. And I want to emphasize that the best way to get bugs fixed quickly is to make really good minimal reductions that include only a snippet of HTML that's to reproduce the problem, because that makes it really easy for us to see what's wrong, what's going wrong.

So this is an example of a test. The object elements represented is that big green block. And the text says that the object should be floating off to the right, to the far right of the window, and have some margins around it. So there should be some space between it and the text, about 20 pixels. And so it's not really rendering the way that we would expect it to. So what I'm going to do is fix the bug.

All right, I think Dave's going to need both hands to type this time. Since it's a safe assumption, this is where a bulk of the HTML, CSS, and DOM code is. And you'll see that there's a subdirectory in here, KHTML. This is our fork of the KHTML engine. So what we have here is an HTML subdirectory where all of the DOM elements are. And there's a nicely named HTML object and bull class here. - Bigger font. - So, yeah, how do I raise the font here? Just-- - Show fonts there. Command T. That didn't work at all. All right. Okay, I think you need to do some preferences. Go in preferences, guys.

There it is. Fonts and colors. The amount of sleep we've got in the last four days. Down, down. All right. Editor font. All right. I think we have it straight. That'll work. Now just say okay. You'll be fine. All right. All right, so what I'm doing here is I'm going to look for the code that parses attributes.

So this is the applet element, which is not the one we want. So I'll keep looking. Here's the embed element, also not the one we want. But out of curiosity, it occurs to me, well, the embed element, that's not the same as the object element. I wonder if this has the same bug. So I'm going to sort of look down here and look-- I see this is pretty interesting because I see v space, h space, align and v align are all handled by the embed element. So I'm going to just copy some of this code here.

and then keep looking. So here I am at HTML object element. So let's look at the list of attributes that it handles here. I see a few. I don't see the ones that I need, so clearly I need to handle those. So I'll just take the code. from the embed element, paste it in here, and you know, kind of hope that that works. Oh, that was going to be my mistake for the code review. You guys are too-- I'm getting code reviews from the audience. And this is the power of open source.

Mike, watch your mic. There's this other function that also handles some attributes. So I'm going to sort of do the pattern matching school of coding here, where I'm going to go back and say, oh, hey, did the embed element actually do something here? It looks like it did. So we can see that there's a little bit more code to handle here. So I'll just sort of copy that too. We'll just paste that in. Get rid of this one that we don't care about. And now we'll try building it. - Maybe later.

You don't want to change the tools directory. No, you can just do it using the script. You're going to be smart there, won't you? They're not kidding about the sleep thing, by the way, guys. We should also note that many of these scripts are about four days old, so we're learning them too.

It used to be a lot more complicated to build, but we just felt we had to have the smoothest possible way to make it easy for contributors to build and test it. Let me know when you're done building. Just kidding. So now we're going to run Safari with our scripts.

Give Macho the mic, though, so he can talk while he's doing it. All right. So normally this is supposed to be the responsibility of the contributor, but I'm just going to... You know, I'm gonna be generous here, 'cause you know, me and Dave, we go way back, so I can make a dip for him. - I'm just gonna be sleeping over here under the desk. It was a small change, I'll just... diff from the command line and read it here so I can review Dave's patch.

Now usually what you do at this point is you would attach the patch to the bug report. So that allows, then you send mail to the mailing list to let everyone know there's a patch on this bug report. So not only can one reviewer review it, but anyone else who's following can go check it out.

All right, so I'm looking at Dave's change here. This part looks okay. He removed the universal line, but these cases are falling through to the same thing over there. These other changes look good. You guys already spotted the missing break that he was going to plant there just for me. So thanks. OK, well, Dave, the code change looks good, but I have a couple of questions about it. The first one is, did you run our regression test suite to see if this breaks anything? I'm sure it's OK. Maybe we better test.

That was not the right answer. That was the right answer for me, though. I'm always like, I didn't run them. - Let's just run the regression test suite. It's going to have to build this tool that's used to dump the render tree. And here it is going. through our test suite, and this takes just a minute to run them all.

By the way, this is a great thing to do if you check out the tree, just to run through the set of automated tests we already have. This is a very useful form of testing, because if anything fails, we really want to know. And by the way, that's a lot of failed there. Shit, we're getting a lot of failures. Oh, yeah, right. We didn't -- We didn't follow the instructions on the website. That's right. We didn't follow the instructions. Oh, we haven't installed -- There's a special font that you need to be able to run the tests -- Let's go do it. Let's go do it. Come on. You don't have to wait for it to finish. This is fun.

Regression testing. Download the Ahem font. You skipped step one again. Damn. We have a problem with this. We like to go straight to the-- Oh, look at all those. So all these tests fail because we didn't have the special font. This is a font that actually has glyphs that are squares with particular proportions. So you can actually make totally repeatable cross browser tests, which should work regardless of the individual details of the font layout system because the glyphs are all perfect squares. So I'm going to-- let's see, where is my downloads window? Just going to use FontBook to install this guy.

All right, now I have this crazy font that is useless for real life, but awesome for testing, created by Ian Hickson, the Web Standards Project, and What Working Group, and other cool stuff like that. So now let's try the test again. And we don't see as many of those failed flying by now. Hopefully this will work. If you watch, you can catch it getting a little slower when it hits the ACID-2 test. Kind of a big test, but it's in here. So that way I can't ever break it.

Oh, you can break it, I'm sure. laughter So yeah, we have test coverage for all sorts of things. Some areas are more complete than others. You may have seen there's like a full CSS1 test suite that flew by there. We don't yet have a complete DOM test suite, but that's something we're looking to add and that we'll be doing out in the open. Table text, text, text, text.

And there it is. OK, they all passed. You got it right this time. OK, so I got another question about this patch. I noticed when you were looking in that object_impl file that it had three things implemented in it. It had object, embed, and applet. And embed already had support for those attributes, and you added them to object. But doesn't applet need to support those attributes too? Only if you use two. Yeah, I guess it does. You're right. Why don't you fix that too? What gives, dude? OK. So interestingly enough, if you go back to Bugzilla-- Yeah, I think there's actually a related bug on this.

to 46, the one that was filed about five minutes before 3247, oh look, H space and V space attributes are ignored on the applet element. So someone had already noticed-- who could that have been who noticed this? Oh, look, me-- that these attributes were not properly supported. So we can go make the same fix. So we'll go bring these along. And we'll head up to applet.

So we can see-- this is kind of interesting. So it did support Align, but it was missing some of the others. So we'll just get it all there now. So now we've got v space, h space, v align, and align all added. And now we want to look at Applet's code that actually parses them. And we see again, it had a line, but it was missing the other ones that we needed. So we'll just-- now we know we've got it in both the embed and the objects, so we'll just go grab it again.

including the break this time. Now let me just say, if I was reviewing this, I would go, "Hey, shouldn't we have a common bass class, guys?" And aside from needing to fix our tabs up in our editor, this is in pretty good shape. And there we go. So we'll try building it again.

And there you go. So now we can run the WebKit test again. Which should succeed? We hope. Yeah, if you guys are actually going to commit, we sure better run them. Yeah, unfortunately we can't commit from this machine because it's an anonymous checkout. Oh, man. I'd like to show you that part so we could be committing live on stage. But we'll have to mail ourselves the patch or something.

And also, we should add new test cases for these. It's actually difficult to add a test case for an applet. Oh. Silly Java. It'll take to run. Can't you just-- no, I guess not. Make one that fails to load or something? If an applet fails to load, it isn't given All right, there it is. It passed. So there's a bug fixed. As you can see, all this is really quick. It doesn't take forever to build the engine. I mean, an HTML rendering engine is a pretty complicated piece of code. But because we started with the small, simple KHTML engine and the KJS JavaScript interpreter, we've got a really small code base that has a very high degree of performance and correctness and support for web standards. And you can just pitch in, look at the code, and contribute. Like Darren said, we had people in less than 24 hours getting into the code and sending us patches to fix bugs, and submitting bug reports for problems that they found testing with the latest web kit. So you should too. All right, thanks guys.

All right, so let's go back to the slides here. So that's the real thing. I mean, really all we left out was checking code into the repository, and we just forgot to bring our private keys. That's the only reason we didn't do that on stage. Yeah, no way. So they'll definitely-- in fact, if you log on in the next couple days, I'm sure you'll see this fix landed.

So I just want to wrap up with a couple comments. One is that we'd like to do some things that are beyond Mac OS X. Now, we're all paid to work on Mac OS X, so you might wonder why are we even talking about this. Well, when it comes to something like a web engine, it's more valuable the more it's shared. And already some people have taken advantage of our existing stuff, WebCore, and done some things that go beyond Mac OS X. So I wanted to talk about some of the things we might hope for in the future and some possibilities that go beyond Mac OS X.

So one thing is we would like to see and think there is now possible greater convergence with KDE, with the original project that we started with. For one thing, the fact that CVS Access is now available, we think makes it easier to move changes to KDE. And one of the KDE hackers who's here in the room, George Stakos, told me the same thing. And he'll be up on stage in a minute, too. Thanks, George.

And George told me that already one of the patches that was contributed to our tree, they also integrated into KDE, which is a hell of a lot easier than how it was before. And we also think that some of our volunteers will want to move changes from KDE, and that's not even a theory. That's also already started happening in the first 36 hours. I can't believe it. Oh, my God. And there are also some interesting projects that we think there's an opportunity that they may be interested in integrating with our source code base. There's a port to the GTK Plus platform. I've heard there's a port to WX Windows platform.

And OmniGroup has a bunch of improvements they've made to the web core that's in OmniWeb. And we would love to see changes from those projects integrated and be happy to see them living in our tree if they get to that point. And I also think there's a chance for some new kinds of projects, again, that are outside the scope of just what you need for OS X. And I just started thinking of ones that I thought would be really great. And one is something that runs on Windows would be huge for testing. Because there are all kinds of people out there. We'll tell them about a problem with a website. And they'll say, well, all I have is a Windows machine. How can I test with your browser? And if there's a way to test with the engine, that goes most of the way there. So I think that would be really great. And also, we have this layer in there, Quack, that we think has a lot of potential, not just as a way to adapt to OS X, but sort of as a porting layer. to make it possible to easily put KHTML on different platforms. And we'd like to refine Quack as a porting layer. And... Everything listed on this slide and a whole lot of other things are mentioned on our website on the project pages. So there are pages for all different aspects of the WebKit with our ideas and thoughts, and they're a really handy place to look if you're interested in getting involved or want to see what our plans are. A lot of those-- nothing in those pages is gonna tell you when we're gonna do something, but what all those pages are gonna tell you is what we're interested in in our idea of the roadmap.

So I'd like to conclude the presentation part of this with an invitation to you, and not just the people in this room, but anyone who would like to get involved. This is a lot of fun. It has already been super fun just this last day and a half just talking to people. That IRC channel is a really cool place. And so you're invited. If you want to come show up just to take a peek and look around, that's great. If you want to come to participate, that's great too. Please bring your own bug reports. That's what we need from you. And just let us know if you're interested. We'll be there on the IRC channel, and we'll be there on the mailing list. So with that, let's take some of your questions. Oh, I'm sorry. I want to mention one other thing, which is this is the website, the WebKit Open Source Project. You saw it on stage. That's the URL. That's the only thing you have to remember.

You don't need any of the other URLs or email addresses or anything. If you have questions about WebKit from the point of view of using the WebKit and want to see some of the sample code and all that stuff, the Developers Conference website has all sorts of-- has that for you.

And if you're interested in learning more about the WebKit from the point of view of someone using the WebKit, there's some great sessions that are relevant. Tomorrow, we've got an introduction to WebKit development in the morning. Later in the morning, we've got some advanced WebKit development information. In the afternoon, we have some information from the point of view of a web designer about Safari and effectively about WebKit as well.

And there's a dashboard widget session. I think that's a lab that you might want to check out too. And so all of these are really handy for learning more about the WebKit. And if you have other kinds of questions, miscellaneous stuff, stuff you don't find out from our open source website or mailing list, please contact Mark Malone, who is our-- who's the Safari and WebKit point of contact. us.