Open source is no different from that perspective. We want to know how we\u2019re doing and somewhat predict how this might change over time by recognizing trends. It\u2019s interesting to point out that the metrics aren\u2019t used by management to evaluate my team or even individuals. We use the metrics to evaluate ourselves. (In fact, I believe that evaluating engineers with metrics is a game you can\u2019t win \u2013 engineers are smart little buggers that always find a way to game the system).<\/p>\n
One metric totally made my day. When browsing the graphs<\/a> of the corefx repo, GitHub displays the following<\/a>:<\/p>\n Indeed we\u2019ve more than 1,000<\/strong> forks! Of course, this a total vanity metric and not indicative of the true number of engagements we have. But we\u2019re still totally humbled by the massive amount of interest we see from the community. And we\u2019re also a tiny bit proud.<\/p>\n But the total number of pull requests is pretty high. In total, we\u2019re approaching 250 pull requests since last November<\/strong> (which includes both, contributors from community as well as Microsoft):<\/p>\n (In case you wonder, I also have a hypothesis<\/a> what the plateau means).<\/p>\n We\u2019re also thrilled to learn that we\u2019re already outnumbered by the community: the number of community contributions is higher than the number of contributions from us. That\u2019s the reason why open source scales so well \u2013 the community acts as a strong multiplication force.<\/p>\n One of the reasons why we decided to open source .NET Core<\/a> was the ability to build and leverage a stronger ecosystem. Specifically, this is what I wrote last year:<\/p>\n To us, open sourcing the stack also means we\u2019re able to engage with customers in real-time. Of course, not every customer wants interact with us that closely. But the ones who do make the stack better for all of us because they provide us with early & steady feedback.<\/p><\/blockquote>\n Of course, the real-time aspect cuts both ways. It\u2019s great if we hear from you in real-time. But how are we responding? If you ever filed a bug on Connect, you may not have had the impression that real-time is a concept that the people outside of the Skype organization have heard of. No offense to my fellow Microsofties; I\u2019m guilty too. It\u2019s incredibly difficult to respond in a timely manner if the worlds of the product team and their active customers are separated by several years.<\/p>\n In order to understand how responsive we are, we collect these two metrics:<\/p>\n Here are the two graphs:<\/p>\n So far these look pretty good, and are in the realm of real-time collaboration. But there is also some room for improvement: getting a first response shouldn\u2019t take more than a week. We\u2019ll try to improve in this area.<\/p>\n Part of the reason I share these metrics is to underline that we\u2019re fully committed to an open development process.<\/p>\n But establishing an open development process is more than just sharing metrics and writing blog posts. It\u2019s about rethinking the engineering process for an open source world. In a Channel 9 interview we said<\/a> that we want to be mindful of the new opportunities that open source brings and not simply expose our existing engineering and processes. The reason isn\u2019t so much that we fear giving anything away; it\u2019s about realizing that our existing processes were geared for multi-year release cycles, so not all of them make sense for open source and agile delivery. In order to get there, we generally want to start with less process and only add if it\u2019s necessary.<\/p>\n This requires adapting existing processes and adding some new processes. Let me give you a quick update of which processes we currently have and what tweaks we made.<\/p>\n To me, this is by far the most valuable part of collaborative software engineering. Realizing how many mistakes you can prevent by just letting somebody else see your code is a very liberating experience. It\u2019s also the easiest way to spread knowledge across the team. If you haven\u2019t done code reviews, you should start immediately. Once you did them, you\u2019ll ever go back, I promise.<\/p>\n If you look at our GitHub pull requests<\/a>, you\u2019ll find that they aren\u2019t just from the community \u2013 we also leverage pull requests for performing our code reviews. In fact, for parts of the .NET Core that are already on GitHub, there are no internal code reviews \u2013 all code reviews fully happen on GitHub, in public.<\/p>\n This has many advantages:<\/p>\n My team spends a lot of time on API design. This includes making sure an API is very usable, leverages established patterns, can be meaningfully versioned, and is compatible with the previous version.<\/p>\n The way we\u2019ve approached API design is as follows:<\/p>\n We\u2019ve found this process to be invaluable because the guidelines themselves are also evolving. For example, when we add new language features and patterns it\u2019s important to come up with a set of good practices that eventually get codified into guidelines. However, it\u2019s rare that the correct guidelines are known at day one; in most cases guidelines are formed based on experience. It\u2019s super helpful to have a somewhat smaller group that is involved in a large number of API reviews because this focuses the attention and allows those folks to discover similarities and patterns.<\/p>\n With open source, we thought hard about how we can incorporate API reviews into an open development process. We\u2019ve published a proposal on GitHub<\/a> and based on your feedback put into production<\/a>. The current API review process is now documented on our wiki<\/a>.<\/p>\n But having a documented process is just one piece of the puzzle. As many of you pointed out, it\u2019s a huge burden if the reviews are black boxes. After all, the point of having an open development process is to empower the community to be successful with contributing features. This requires infusing the community with the tribal knowledge we have. To do this, we started to record the reviews and upload them to Channel 9<\/a>. We also upload detailed notes<\/a> and link them to the corresponding parts in the video.<\/p>\n Of course, a complex topic like API design isn\u2019t something that one can learn by simply watching a review. However, watching these reviews will give you a good handle on what aspects we\u2019re looking for and how we approach the problem space.<\/p>\n We\u2019ve also started to document some less documented areas, such as breaking changes<\/a> and performance considerations for the BCL<\/a>. Neither page claims to be complete but we\u2019re curious to get your feedback.<\/p>\n Another change we recently did was requiring contributors to sign a contributor license agreement (CLA)<\/a>. You can find a copy of the CLA on the .NET Foundation<\/a>. The basic idea is making sure that all code contributed to projects in the .NET Foundation can be distributed under their respective licenses.<\/p>\n This is how CLAs are exposed to you:<\/p>\n Moving forward, we\u2019ll only accept pull requests that are labelled as either cla-not-required<\/strong> or cla-signed<\/strong>.<\/p>\n It\u2019s worth pointing out that we intend to have a single CLA for the entire .NET Foundation. So once you signed a CLA for any project in the .NET Foundation, you\u2019re done. This means, for example, if you signed a CLA as part of a pull request for corefx<\/a>, you won\u2019t have to sign another CLA for roslyn<\/a>.<\/p>\n We\u2019ve always had an automated build system. The triggers varies between teams, but the most common approach is a daily build in conjunction with a gate that performs some validation before any changes go in. For an open source world, having an internal build system isn\u2019t helping much.<\/p>\n The most common practice on GitHub is to use a continuous integration (CI) system that builds on every push, including pull requests. This way, reviewers on the pull requests don\u2019t have to guess whether the change will pass the build or not \u2013 the registered CI system simply updates the PR accordingly.<\/p>\n GitHub itself doesn\u2019t provide a CI system, it relies on 3rd parties to provide one. Originally, we used AppVeyor<\/a>. It\u2019s free for open source projects and I use it on all my personal projects now. If you haven\u2019t, I highly recommend checking them out. Unfortunately, AppVeyor currently only supports building on Windows. In order to enable our cross-platform work we wanted a system that we can run other systems, especially Linux. So we went ahead and now host our own Jenkins servers to perform the CI service.<\/p>\n Our team is still learning and we believe it\u2019s best to be transparent about it. As David Kean said in our initial open source interview<\/a>:<\/p>\n Don\u2019t be afraid to call us on it. If we do something wrong, overstep our boundaries, or do something that you thing we should have done better, call us out on it.<\/p><\/blockquote>\n The earlier you can tell us, the better. So why not share our thinking and learning before we make decisions based on it? Here are a few examples.<\/p>\n Are there any other topics you\u2019d interested in? Let us know!<\/p>\n At the time of the Connect()<\/a> event, we only had a fraction of the libraries available on GitHub:<\/p>\n Those four libraries totaled about 145k lines of code. Since then, we\u2019ve added many more libraries which more than tripled<\/strong> the code size to now more than half a million lines of code<\/strong>:<\/p>\n And we\u2019re not even done yet. In fact, we\u2019ve only tackled about 25% of what is to come for .NET Core. A full list is available in an\u00a0Excel spread sheet<\/a>.<\/p>\n Since November, we\u2019ve made several improvements towards an open development model. Code reviews are in the open and so are API reviews<\/a>. And \u2013 best of all \u2013 we\u2019ve a very active community which already outnumbers the contributions from our team. We couldn\u2019t have hoped for more.<\/p>\n Nonetheless, we\u2019re still at the beginning of our open source journey. We\u2019re heads-down with bringing more .NET Core libraries onto GitHub. On top of that, the runtime team is busy getting the CoreCLR repository ready. You can expect an update on this topic quite soon.<\/p>\n As always, we\u2019d love hearing what you guys think! Let us know via the comments, by posting to .NET Foundation Forums<\/a> or by tweeting @dotnet<\/a>.<\/p>\n![\"\"](\"https:\/\/devblogs.microsoft.com\/dotnet\/wp-content\/uploads\/sites\/10\/2015\/01\/6558.Pic1_.png\")
<\/a><\/p>\n![\"\"](\"https:\/\/devblogs.microsoft.com\/dotnet\/wp-content\/uploads\/sites\/10\/2015\/01\/3755.Pic2_.png\")
<\/a><\/p>\n![\"\"](\"https:\/\/devblogs.microsoft.com\/dotnet\/wp-content\/uploads\/sites\/10\/2015\/01\/3833.Pic3_.png\")
<\/a><\/p>\nReal-time communication<\/h2>\n
\n
![\"\"](\"https:\/\/devblogs.microsoft.com\/dotnet\/wp-content\/uploads\/sites\/10\/2015\/01\/1538.Pic4_.png\")
<\/a><\/p>\n![\"\"](\"https:\/\/devblogs.microsoft.com\/dotnet\/wp-content\/uploads\/sites\/10\/2015\/01\/4532.Pic5_.png\")
<\/a><\/p>\nOpen development process<\/h2>\n
Code reviews<\/h2>\n
\n
API reviews<\/h2>\n
\n
Contributor license agreements (CLAs)<\/h2>\n
\n
Automated CI system<\/h2>\n
We\u2019re still learning<\/h2>\n
\n
Library availability<\/h2>\n
\n
\n
![\"\"](\"https:\/\/devblogs.microsoft.com\/dotnet\/wp-content\/uploads\/sites\/10\/2015\/01\/6332.Untitled.png\")
<\/a><\/p>\nSummary<\/h2>\n