 4.8 million lines of code, this statistic is obtained from the OLLO website, and most of the code is based on C++, C, and Objectc. The NCC code is more related to WebKit2, API bindings, and the Objectc is more related to Apple-Cocoa bindings. The project itself now contains around 300 committed and 130 reviewers. This can vary much our own time, so for example right now there are around 100 active contributors to WebKit after the blink has been forked, but there's still a good number of people around. And as of November of last year it contained around around 40% of browsers market share, and the actual numbers are now after the blink fork. Safari itself is around 8.5% of market share, and the whole Chrome ecosystem owns around 40%. This is a statistic where it took from a stats counter, I mean, I guess, it's a website that makes these kind of calculations. And speaking about lines of code, as you can see from this time frame, also took from OLLO, since the project started it has acquired a lot of lines of code, and on 2005 when WebKit was open-sorted it started really to have different kinds of contributions. The current code not only contains the WebKit engine itself, but a bunch of different build system files, different ports, and platform-specific code. And you can see when the blink project was forked, there is a slight diminution on the number of lines of code, and that was due because the WebKit folks has removed everything that was related to Chrome import. And on this next graph you can see the number of commits per month. And again, when you see after the blink has been forked, the amount of commits has decreased a lot, but it's still a very huge amount of commits. So, for example, you can see from the last 30 days it has around 1500 commits. And the same applies for the number of contributors before that there were around 300 or three active contributors, and now this number has decreased to around 86. Speaking about the number of active contributors, the same behavior appears on the graph, as I spoke earlier. And you can see that there are the top 10 contributors, Apple, Google, Nokia, Research Emotion, Igalea, Intel, Samsung, the universe of Zagat, Adobe, and Torchmobile are the hugest contributors to the project. There are other companies contributing to WebKit, but I would say that these are the top 10 that most contribute to WebKit. This information was obtained from a website called biturgea.com. And in the beginning of this year, they made some very good statistics about the project. I mean, from number of contributors to top 10 companies and everything else. I will show the link later on the presentation. So, now speaking about blink, what is blink? It's basically a fork of WebKit as of April 2013. And it contains only a single port, which is called Chromium. It's important to say here that Chromium is not a standalone port. By that I mean, you cannot run blink just by compiling blink itself. Blink requires a content layer implementation associated with that. In comparison to WebKit, you have, for example, the mini browser, which is a very rudimentary browser implementation that is contained on WebKit source code. So, it pretty much contains everything that you need to obtain a browser window on the screen. So, blink also contains a custom JavaScript engine. It's called V8. WebKit uses JavaScript core. And one interesting aspect of this is that when the project was forked, the both projects, they removed every API, for example, WebKit removed every API that was related to V8 bindings to their web core. And the same has been applied to blink. So, it has removed everything that was binding to JavaScript core. Blink is based on multiple, sorry, I would say it would be more like political. I mean, Apple hosts the whole JavaScript core implementation and Google hosts the V8 one. And by the time WebKit was a single community, it was becoming harder and harder to sustain both implementations because Google guys wanted to have more inner implementation code from V8 inside WebCore. On the other hand, the Apple guys didn't want to make that kind of binding too much strict because they want to support JavaScript core as well. So, it's more like a political decision than that. So, blink is based on a multiprocessor architecture. Basically, you have the browser process and one to end renderer processes. This was best explained on my colleague's presentation earlier today. And basically, it differs from the WebKit to API multiprocessor architecture. This is also another reason why the projects were quite different. But this is not really the subject for this talk now. But of course, if we can discuss this later, blink contains different goals when compared to WebKit. Basically, Google wants greater freedom in implementing WebCore features. By that, I mean, they want to make experimental features more becoming available to the public quite faster than on WebKit side. So, for example, all the experimental features that were available on WebKit when the blink fork happened, one of the priority things that the developers did was modifying all the runtime features to become, sorry. In the past, they were enabled on compile time. There was a flag there. You could enable or disable on compile time. But on blink, you can enable that on runtime. There is a page called Chrome.2. I can show you. If you go to Chrome, there is this page where all the experimental features can be enabled on disable on runtime. So, this is very interesting because such thing is not available on the WebKit port. You have to compile the whole project to make that. It also wants to avoid vendor prefixes. This is important because if you are a Web developer, you want to get rid of using polyfills on your JavaScript code to support, let's say, all the available browser vendors. And, on the other hand, it's very challenging because all these CSS properties that has vendor prefixes, they have this for a reason. For example, usually the standard for that property is not yet finished. It's still ongoing development. And that's why every browser doesn't want to get responsibility on saying that, okay, so this property is fully implemented in my engine. So, that's why they use the vendor prefixes. But the Google guys want to get rid of that. They want to force every browser to implement the features straight from what the standard says. There's also a lighter code base. Most of the code that was reminiscent from the WebKit was removed. I mean, they have cleaned a lot of different build system files. So, for example, on WebKit, you had CMake, QMake, AutoTools, and a bunch of other build system files that were, you know, huge to maintain. And the Blink has removed all of that, a lot of platform-specific code as well, and port-specific code. So, all the QT bindings, all the EFL bindings, and so on were removed. Blink only contains the Skiya bindings. And this Skiya itself is hosted on the Chromium project as a sub-directory. Also, from the insights that I obtained from the Blink conference that happened last month, I would say that for the future, the intention is to remove all code that is not related to strictly layout and rendering code out of Blink and move that to the Chromium project. Right now, for example, Blink is hosted inside the Chromium repository as a sub-directory. If you check the Chromium source code, you can see, for example, here on source, then you have third-party and WebKit. It's still named as WebKit because there are a lot of third-party-dependent code that depends on that specific name to be used. But this is where the Blink code resides at this moment. So, yeah, speaking about lens of code, I'm taking this graph from March 2013, where the cleanup starts. And as of April, the Blink project was forked. So they started to clean up the code before, the public announcement. And since then, the number of lens of code has been stabilized at around 2.5 million lens of code. We can't say, for example, that new code is not being added. But in the contrary, there is still a lot of code that is being removed, reminiscent from WebKit, but also new code. So one thing leverages the other. So here in this graph, we see the different hierarchical status inside both projects. The first level of hierarchy is the general contributor. So if you are a developer that wants to contribute to WebKit and Blink, you are entitled that. But this can also mean people with some special powers. So let's say, on WebKit, for example, if you want to get automatically CC it on a bugzilla bug, or if you want to run the early warning system for your patch, you can get this contributor status. And on Blink, also, you have the special status for people that wants to have access to the try job system. I will talk about this early warning system and try jobs later. So you guys can understand it better. Now, the next level is the committer level. The special feature here is that this person has the ability to commit patches. So after your patch gets reviewed by someone, you can commit it by yourself. You have the authority to do that. And later on, we have the reviewer on WebKit site and the owner on the Blink site. Basically, they do the same, but the difference is that on WebKit site, the reviewer is more scoped to a feature, so let's say an area of knowledge. So if you know about CSS or graphics or multimedia, you will be specialized on one of these subjects. You will be a reviewer for that. In the other hand, on the Blink site, it's more specific to a directory. So let's take, for example, this source and core directory. If you see, every directory on Blink has a file called owners. And if you open that, you will see a lot of emails that are related to people that contain ownership on the directory. So if you want to get your patch reviewed or acknowledged by someone, you have to check out for one of these people listed here. So in this graph, I try to resume a general path for submitting patches inside WebKit. The first thing you have to do is either create a new bug or select an existing bug on inside WebKit bugzilla. This is important because everything is tracked in WebKit. Every feature that you want to implement or bug fix you want to do is tracked on bugzilla. So after doing this, you will have an open bug associated with you and you can start creating and building your patch. After you have a patch done, you can upload it to bugzilla. And when this happens, the early warning system takes action. What it does basically is a set of bots that will pick up the patch, apply it on top of the repository, build it and test it. Each bot will be associated with a specific platform. So let's say there will be the Mac bot, the Windows bot, Linux bot and this whole process happens automatically. So after these bots run, they will report to either by saying that okay, everything is fine or there is a problem in the build process or there is a problem in the testing process and whenever this happens, there will be a log associated with the error that happened. So the developer can see what went wrong. If everything goes well, then the next step would be requesting for a review flag. If you check on WebKit bugzilla, let me just open one here. I will open an existing bug just for exemplification. So let me just log in. One that has a patch. Okay, so you see here, this is what the early warning system is all about. So you can see a lot of different bots here and each of them will get the result. If it's green, it says everything went okay. If it's not green, something wrong happened. And if you check on details, you can see here there are two different kinds of flags, the review flag and the commit queue flag. And that's what we are talking about on the slides. So you ask after you get your patch all okay by the early warning system, you set up the review flag. This will notify every reviewer that is associated with your patch. There is a script inside WebKit that automatically searches for the corresponding people that will be the best option to review a patch. How this happens, it checks out the Git log and Git blame for people associated with that specific part of the code that you are working with. So if someone will review a patch and if everything is okay, he will assign our plus flag like this. After you get this done, you can request for commit queue flag, which is basically the same. You have the option, for example, after you have your patch reviewed to manually commit your patch, if you have SVN logging and everything set up, otherwise you can just use commit queue which is also another bot that will pick up your patch again, apply it on top of head, build it, test it once more, and if everything is okay, he ultimately lands your patch. So in the end, you can see here, let's see here, you can see this commit was made by commit queue and it automatically fills the change log lines like patch by someone, review it by someone else. This is all being done automatically by the bots. WebKit and Blink, they don't really associate patches with the outer name space. They most usually, if you want to know who really made the patch, you have to look on the change log. So in this case, you have to search for these specific lines and they will be always present on every WebKit patch. If you see here, there is always some reviewed by, so there is always someone that will review a patch. If the patch was applied by yourself, so it was a manual commit, there is no patch by, but if it was done by commit queue, then you can be sure you always will find the patch by line. This is done automatically, there is a script that picks up the committer name and put that. So in order to become, sorry, the main repository of WebKit is based on SVN, but most developers, they just use the Git SVN tool to implement, to develop. I mean, SVN is used because WebKit is a very old project and by the time, Git wasn't even an option. So they still sustain SVN, but most of the development is made on Git. So in order to become a committer, you have to have at least around 25 reviewed patches. And by revealed patches, I mean, there are some patches on WebKit that doesn't really require reveal. If you do a patch, for example, there are the layout tests inside WebKit, and if you just want to update some test results, you don't actually require reveal from someone. You can just commit that by yourself. So you also have to have good judgment understanding of the project policies. By that, I mean, basically, you can't do whatever you want on the project, like commit a random file or anything. You have to have good collaboration skills. By that, I mean, you have to be communicative on the RSC channels, on the mailing lists, on bugzilla comments, and you have to be open to help someone that is doing some work related with what you have done in the past already. And the nomination itself requires at least three reviewers to acknowledge your nomination. There is one guy that will nominate and two others that will acknowledge. And this whole process happens inside a private mailing list that is only visible to reviewers. Some people might ask, why is that, let's say, closed to the public? But you have to remember that WebKit and Blink projects are mostly driven by companies. And sometimes there are, let's say, opinions, different opinions about someone that might be harmful if they talk outside of it. So they try to keep it closed. And in order to become a reviewer, a reviewer contains more complex responsibilities. So one of the things that, although it's not a perfect measure, but they have to have around 100 reviewed patches. So this means the guy has to be very serious understanding of the source code. By that, I mean, for example, the best examples of reviewers are people that implemented the whole new feature inside WebKit or that has sustained the development of a certain feature for a long time or has fixed a serious crash on the system and so. And the person has also had to informally review it already, other people's patches. So, for example, you are not yet a formal reviewer, but if you have already gave some suggestions to someone on the Bugzilla comments or helped someone else to fix bug in his patch, his or her patch. So this all is taken into account when the review nomination happens. You have to ensure that the reviewed patches follow project policies. So WebKit is a project that contains very strict policies for submitting patches. I haven't spoken previously, but for example, if we want to submit a patch, you have to run script inside WebKit that we'll check for if the change log is properly being written, if the coding style respects what WebKit follows and everything else. So this is a very strict system and you have to guarantee that the other people's patches follow that. And of course, you have to have exceptional judgment on source code changes. You can simply accept any patch from someone else because it's related to you or if you just, let's say, trust that person's judgment. You have to personally reveal line by line and guarantee that that feature is what the person has intended to implement. This is an important aspect of WebKit. It's a very happy community and we have this place on the web called webkitmemons.tumblr.com, which contains a bunch of different memons associated with the daily work on WebKit. And this is very important notice. I think this is general for every open source community. If you put a patch for a review but don't ping anyone or IC channel or mailing list or doesn't CC anyone on the bugzilla, it will have a bad time. By that bad time, I mean, you can wait for hours, days, weeks, even months for someone to review your patch because nobody will just stop by and, oh, okay, this patch needs to be revealed. As you may know, WebKit is a very large and complex project and the reviewers are always busy doing something. So unless you ping them and not find them, hey, I have this patch, please reveal. It can take a lot of time to get your patch landed. So speaking about Blink, Blink contains a very similar aspect for submitting patches when compared to WebKit. The main difference here is that it uses two different websites for managing things. One is the Chromium issues, which is the most close to what bugzilla does. The difference is Chromium issues is scoped only to tracking bug comments, issue comments. It doesn't really track the patch flow. So the first thing you have to do is either create or select and bug inside Chromium issues and then you can start developing the patch. After having your patch done, you upload it to code reveal and the association to the Chromium issue is done on the changelog. You can see here on Blink, for example, on this patch there will be always this line, bug equals a number, which associates with the Chromium issue number. So this is how they keep track of everything. After uploading your patch, it will be run by the TryBots, which are much more like the early warning system on WebKit. There will be specific bots for specific platforms and they will all pick up your patch, apply it on top of head, build it, test it and if everything goes well, they will be green. So this is on WebKit and let me open something here. So if you see here, this is the code reveal and when you submit the patch, you have the TryBots here also with the same system. If everything goes well, it's green, otherwise it's red. After that, your patch is ready for reveal and you can ask someone to reveal a patch and if the person acknowledges your patch, it will just write down looks good to me inside the patch. Let me see if I can find some here. So for example, this patch has pasted all the TryBots and some owner has just put it looks good to me. This is read by some bot that will say, okay, so this patch is ready for commit. You can see that the line for the commit, the rectangle got green, which says, okay, it's ready to go. So after this point, you can either manually commit your patch or use the commit keyword bot to do that for you. If you want to make your patch committed, you can just check out this box here. I will not do this here, otherwise it will create some problem for the guy. Some interesting aspects here is that after the patch is landed, it notifies the Chromium issues. So there will be a special comment there made by the commit keyword saying, okay, so these issues is ready to be closed because the commit has been made and the commit keyword bot. For example, if it takes time for you between uploading your patch to the code review and obtaining the review status, there might be changes of the code that can make the application of your patch on the repository impossible. So let's say you made modification on a certain file and someone else has already modified that. So what commit keyword does is try three times to make this appliance on the repository. If it fails, then it will warn you and you will have to submit a new patch with that fixed. So the process for gaining status in Blink, especially for committers status, it's pretty much similar to what WebKit does and can be sped up if you are already a WebKit committer. So for example, you haven't committed any patch on Blink, but you have already, let's say 30 or 40 patches committed on WebKit, they will take that into account and can nominate you. The nomination process is very similar as well. There is a closed list, committers list inside Chromium and someone will nominate you and two other people will have to back up, will back your support. And the same applies for owner. The process for ownership is pretty much similar to what WebKit does, but two important aspects here had to be taken into account. The person has to be a Chromium project member for at least six months. And for example, if you want to take ownership on a specific directory, you have to make, already have made modifications on that directory, like sending a patch to a specific file inside of it, at least from the 19 earlier days. So they really take that into account. And of course, have bandwidth to contribute to the project. I mean, reveal someone else's patches, giving back support for the patches, for the features you were previously implementing. So if something wrong happens, you have to give support for that and everything else. So speaking about the Linux kernel development, from what I have seen, again, saying I'm not an expert on Linux kernel development, so please help me if I'm speaking something wrong here. We have the vanilla releases that are made personally by Linux. And we have two other more releases which are the stable and the experimental ones. And these releases happens on a two to three months basis. Compared to WebKit, WebKit and Blink itself, they don't have a specific release date or versions. If you want to check the latest version of WebKit, you just need to clone the repository and the last release from the SVN will be the release. These two projects, they are more associated with the target browser. So for example, WebKit has Safari as the target browser, mostly because Apple is the main contributor to WebKit. And Blink has the Chromium browser as the target. So both of these projects, for example, Safari contains the nightly builds. So every night, there is a new build with the head of the repository associated. But from time to time, Safari releases new versions with new features as well. The same applies for Chromium. There are milestones. For example, I believe now that Chrome is on the milestone 31 and 32 will be released very soon. And all these milestones are related to new features that are implemented also on the web engine side. The patch lifetime can be relatively quick for minor fixes. So for example, if you have a very simple bug fix, one line bug fix on the kernel, this whole process can be very quick. Or it can take ages or years for large and controversial changes on the kernel. And again, compared to WebKit and Blink, they usually have faster tries in times, mostly because the bots help very much checking if your change will break something in a specific platform, for example. So the process for submitting a patch starts with the design step. This is often done individually, so it doesn't really involve community. So if you work for a company that, let's say, doesn't want to get public what they are doing, they will be submitting patches to the kernel, but they won't be saying, okay, we are implementing this specific feature. Then you get the early reveal. So usually what people do is get the patches uploaded to some mailing list, related mailing list, and after that it will get revealed from people. And if some subsystem maintainer will take attention to your patch, it will, and agrees with the patch, it will apply it under his or her own repository. And after this step, the subsystem maintainer itself will also guarantee there will be another round of reveals on your patch. And if everything goes right, and the patch is accepted by Linus, it goes into mainline. This is usually the information that I have obtaining from checking out how the whole process happens inside kernel. And finally, there is the release step, which is basically the developer should take responsibility for the code. So if something breaks after his changes, or if some specific driver stops functioning, the developer has the responsibility to either roll back the patch or upload some new patch to fix that issue. And now we have, we make some comparisons. So for example, on the design step, WebKit and Bleak usually promote some more openness in the development process. So for example, if you are a company or some individual that wants to implement a new feature, the first thing you can do is send an email to the WebKit developers mailing this saying, I intend to implement this or that feature, like CSS shader, or I want to remove this because it's deprecated. Usually people publish their intentions before sending new patches, and when they publish their intentions, they will get feedback from the community. So for example, there will be someone saying, okay, cool, nice that you have doing that. I can help you if you want to. Or, oh, hey, I already tried to do that in the past and it didn't work. So it's faster to gather this kind of feedback from the community. And on the early reveal step, one thing that really is important on the WebKit is that everything is tracked inside Bugzilla and the same applies for Blink, which has the code reveal and the Chromium issues. Both are very good tools to track history and to separate issues from the logical scope. So for example, if you have a fix for something, if you want to know everything that happened to that, you can just check out the Bugzilla comments to see what people have done in that subject. Also, we have the addition of the WebKit's early warning system and tri-bots. This pretty much simplifies the work for the developer to test it on different platforms. So you don't actually need to compile your code manually on ARM architecture or Intel architecture or on a specific device. You can just submit your patch and the tri-bots will try to get that for you. So on the wider reveal and merging to mainline, the comparison I could do is that a reviewer or owner acknowledgement is usually enough. I mean, usually there is only one person that will be involved plus the developer on the process of getting the patch into mainline. Speaking about Linux kernel, you as the developer has to first submit it to some maintainer that could be a driver maintainer or a sub maintainer. And then this maintainer will send it to another, to another, to another until it gets to a subsystem maintainer, which finally will send that to Linux. And this whole hierarchy demands some time for patches to go up on the hierarchy. And this can be quite faster inside WebKit and Blink development. Also speaking about integration, as I said earlier, every patch that is sent to the bugzilla, okay, every patch that is sent to the bugzilla automatically is tested against the repository. So it tries to apply first and build everything on different platforms. So this process happens faster on these projects. Like testing is also on the fly. When the bots build and compile your code, they will also run some tests. There are diversity of tests. There are layout tests and some unit tests inside WebKit and Blink that are run. So speaking about the hierarchy model, as I said earlier, it's way more simpler inside WebKit. Usually, for example, on the kernel, if you have some patch that touches two or more different places that are maintained by two or more different maintainers also have to get some sort of packet by flag inside your changelog of your patch. This is not really the case for WebKit and Blink. And one thing that I found really interesting on this project is that getting patches inside depends on finding the right maintainer. So you can get pretty lost if you don't know the right person to talk to. And this also happens inside WebKit and Blink. So as the final thoughts, I would say that all these three projects, they are open source, they are strict in terms of the development process. I mean, WebKit has a way of doing things, Blink has a way of doing things and so for Linux. And the hierarchy levels are based on meritocracy, which is a very good thing. And what is awesome about WebKit and Blink projects are the automated patch-striage in-system, which is something that I would really love to see inside Linux kernel development. I mean, if there would be such a place where I could just upload my patch and have it run by different platforms and testing, automatically it would be, I think it would be a good thing for the community. And also it has a bug tracking system and also history. And I really don't know if there is such a similar thing inside the Linux kernel community. I know that the mailing lists are very much active in that sense, but it would be really cool if we could have some specific place to find the tracking history for some feature implementation or bug fix. So yeah, now it's a proper time for questioning. I know, I have talked a lot about these two projects and please ask anything. Yep, so your question was if I am, let's say, an individual that wants to gather the hierarchy level status on this project, yes, it's pretty doable. Although, yes, yes. To be quite honest, you won't see as much individual contributors to WebKit and Blink projects as you might see on the Linux kernel. You will see a lot of people that are linked to some company or let, yeah, I mean, you won't find individual contributors, people with let's say at Gmail or at something individual there. You will see a lot of simsum.com, Intel.com, Apple.com emails associated to keep track, yes. So your question was is it really, is it possible to avoid all this mechanism to submit a patch? So speaking about WebKit, mainly almost everything that is related to WebKit is hosted by Apple. They host, for example, the bugzilla, they host the WebKit site and some bots from the early warning system are also hosted by Apple. But for example, if you are talking about specific bots, so let's say here, the Qt bot. It was hosted by Deja, which is the main company behind Qt. They were hosting it until three weeks ago. The bot is not available anymore, but so if you have a platform-specific implementation, you will be, let's say, responsible for hosting that bot to run all the tests. But everything else is paid by Apple. And Apple is doing that because it has a lot of interest in keeping the community running and facilitating everything for the developers. And the same applies for Blink. I mean, most of the infrastructure is hosted by Google, but specific try-bots are also run by independent companies. Google invests a lot of money in that because it wants to do so. It's important for them. And for the developers, it really fasts the development time for getting the patch submitted until getting it to mainline. It's verified. Someone else? Okay, so speaking, since uploading the patch to getting it on mainline, yes, yes, anyone is free to open a Bugzilla account. It's free. You can go there and register. And the public RSC channels are open. You can go to freenote.org. And there is a WebKit channel inside there. And there is also a Blink channel. It's a very open community. You can just go there, drop by. The mailing lists, the public mailing lists are open like they are hosted on mail. So, for example, there is this WebKit. The mailing lists, the Blink tab mailing lists, they are open. The mailing lists that are not open are the committers and the reviewers on, which, as I explained earlier, they use for nominations. But besides that, everything else is open and free for anyone to register. So, coming back to the first question, you would be what to work on. So, is there like a sort of list of unassigned bugs or something like that? There is no such checklist available. But I could say, as Adi Nielsen on his earlier talk, the main focus now for both projects would be on performance. Because, you know, HTML5 specification was finished last year. So, there are still some features to be implemented, of course. But now that it's finished, the focus of everyone is getting the code running faster on the mobile devices, on smart TVs, on tablets, desktops, anywhere else. So, for example, there is a huge focus on accelerated compositing inside both WebKit and Blink, some CSS optimizations as well, especially on the 3D transforms. So, there is still a lot of work to be done. And you can check from the commit numbers per month. So, WebKit has more than a thousand commits per month nowadays. Same applies for Blink. So, there is a lot happening at the moment. I wouldn't have specific numbers on that. But I would say that's a very common practice, especially on the Blink side. One of the interesting things that was happening in WebKit before the forking is that it was very usual for you to see on the history of commits rollbacks made by Google developers. So, they usually send the patches, but something was wrong. So, they roll back the patch and then upload another patch again. This is a very common practice. It's not rare to see a rollback patch, but I wouldn't have the proper numbers for that. Anyone else? Well, there are, of course, a lot of different things to be detailed in this presentation, but feel free to contact me after this. I have this, you can find the slides on slideshare. And, of course, you can contact me on the conference. Thank you very much.