Bugzilla has played a major role in the Firefox development process for over 15 years. With upcoming changes to how code changes to Firefox are submitted and reviewed, I think it is time to revisit the central role of Bugzilla and bugs in the Firefox development process. I know this is a contentious thing to say. Please, gather your breath, and calmly read on as I explain why I believe this.
The current Firefox change process defaults to requiring a Bugzilla bug for everything. It is rare (and from my experience frowned upon) when a commit to Firefox doesn't reference a bug number. We've essentially made Bugzilla and a bug prerequisites for changing anything in the Firefox version control repository. For the remainder of this post, I'm going to say that we require a bug for any change, even though that statement isn't technically accurate. Also, when I say Bugzilla, I mean bugzilla.mozilla.org, not the generic project.
Before I go on, let's boil the Firefox change process down to basics.
At the heart of any change to the Firefox source repository is a diff. The diff (a representation of the differences between a set of files) is the smallest piece of data necessary to represent a change to the Firefox code. I argue that anything more than the vanilla diff is overhead and could contribute to process debt. Now, there is some essential overhead. Version control tools supplement diffs with metadata, such as the author, commit message, and date. Mozilla has also instituted a near-mandatory code review policy, where changes need to be signed off by a set of trusted individuals. I view both of these additions to the vanilla diff as essential for Firefox development and non-negotiable. Therefore, the bare minimum requirements for changing Firefox code are a diff plus metadata (a commit/patch) and (almost always) a review/sign-off. That's it. Notably absent from this list is a Bugzilla bug. I argue that a bug is not strictly required to change Firefox. Instead, we've instituted a near-universal policy that we should have bugs. We've chosen to add overhead and process debt - interaction with Bugzilla - to our Firefox change process.
Now, this choice to require all changes be associated with bugs has its merits. Bugs provide excellent anchor points for historical context and for additional information after the change has been committed and is forever set in stone in the repository (commits are immutable in Mercurial and Git and you can't easily attach metadata to the commit after the fact). Bugs are great to track relationships between different problems or units of work. Bugs can even be used to track progress towards a large feature. Bugzilla components also provide a decent mechanism to follow related activity. There's also a lot of tooling and familiar process standing on top of the Bugzilla platform. There's a lot to love here and I don't want diminish the importance of all these things.
When I look to the future, I see a world where the current, central role of Bugzilla and bugs as part of the Firefox change process begin to wane. I see a world where the benefits to maintaining our current Bugzilla-centric workflow start to erode and the cost of maintaining it becomes higher and harder to justify. You actually don't have to look too far into the future: that world is already here and I've already started to feel the pains of it.
A few days ago, I blogged about GitHub and its code first approach to change. That post was spun off from an early draft of this post (as were the posts about Firefox contribution debt and utilizing GitHub for Firefox development). I wanted to introduce the concept of code first because it is central to my justification for changing how we do things. In summary, code first capitalizes on the fact that any change to software involves code and therefore puts code front and center in the change process. (In hindsight, I probably should have used the term code centric, because that's how I want people to think about things.) So how does code first relate to Bugzilla and Firefox development?
Historically, code review has occurred in Bugzilla: upload a patch to Bugzilla, ask for review, and someone will look at it. And, since practically every change to Firefox requires review, you need a bug in Bugzilla to contain that review. Thus, one way to view a bug is as a vehicle for code review. Not every bug is just a code review, of course. But a good number of them are.
The only constant is change. And the way Mozilla conducts code review for changes to Firefox (and other projects) is changing. We now have MozReview, a code review tool that is not Bugzilla. If we start accepting GitHub pull requests, we may perform reviews exclusively on GitHub, another tool that is not Bugzilla.
(Before I go on, I want to quickly point out that MozReview is nowhere close to its final form. Parts of MozReview are pretty bad right now. The maintainers all know this and we have plans to fix it. We'll be in Toronto all of next week working on it. If you don't think you'll ever use it because parts are bad today, I ask you to withhold judgement for a few more months.)
In case you were wondering, the question on whether Bugzilla should always be used for code review for Firefox has been answered and that answer is no. People, including maintainers of Bugzilla, realized that better-than-Splinter/Bugzilla code review tools exist and that continuing to invest time to develop Bugzilla/Splinter into a best-in-class code review tool would be better spent integrating Bugzilla with an existing tool. This is why we now have a Review Board based code review tool - MozReview - integrated with Bugzilla. If you care about code quality and more powerful workflows, you should be rejoicing at this because the implementation of code review in Bugzilla does not maximize optimal outcomes.
The world we're moving to is one where code review occurs outside of Bugzilla. This raises an important question: if Bugzilla was being used primarily as a vehicle for code review, what benefit and/or role should Bugzilla play when code review is conducted outside of Bugzilla?
I posit that there are a class of bugs that won't need to exist going forward because bugs will provide little to no value. Put another way, I believe that a growing number of commits to the Firefox repository won't reference bugs.
Come with me on a journey to the future.
MozReview is purposefully being designed in a code and repository centric way. To initiate the formal process for considering a change to code, you push to a Mercurial (or Git!) repository. This could be directly to Mozilla's review repository. If I have my way, this could even be kicked off by submitting a pull request on GitHub or Bitbucket. No Bugzilla attachment uploading here: our systems talk in terms of repositories and commits. Again, this is by design: we don't want submitting code to Mozilla to be any harder than hg push or git push so as to not introduce process debt. If you have code, you'll be able to send it to us.
In the near future, MozReview will stop cross-posting detailed review updates to Bugzilla. Instead, we'll use Review Board's e-mail feature to send its flavor of emails. These will have rich HTML content (or plain text if you insist) and will provide a better experience than Bugzilla ever will. We'll adopt the model of tools like Phabricator and GitHub and only post summaries or links of activity, not full content, to bugs. You may be familiar with the concept as applied to the web: it's called hyperlinking.
Work is being invested into Autoland. Autoland is an automated landing queue that pushes/lands commits semi-automatically once they are ready (have review, pass automation, etc). Think of Autoland as a bot that does all the labor intensive and menial actions around pushing that you do now. I believe Autoland will eventually handle near 100% of pushes to the Firefox repository. And, if I have my way, Autoland will result in the abolishment of integration branches and merge commits in the Firefox repository. Good riddance.
MozReview and Autoland will be highly integrated. MozReview will be the primary user interface for interacting with Autoland. (Some of this should be in place by the end of the quarter.)
In this world, MozReview and its underlying version control repositories essentially become a database of all submitted, pending, and discarded commits to Firefox. The metaphorical primary keys of this database are not bug numbers: they are code/commits. (Code first!) Some of the flags stored in this database tell Autoland what it should do. And the MozReview user interface (and API) provide a mechanism into controlling those flags.
Landing a change in Firefox will be initiated by a simple action such as clicking a checkbox in MozReview. (That could even be the Grant Review checkbox.) Commits cleared for landing will be picked up by Autoland and eventually automatically pushed to the Firefox repository (assuming the build and test automation is happy, of course). Once Autoland takes control, humans are just passengers. We won't be bothered with menial tasks like updating the commit message to reflect a review was performed: this will happen automatically inside MozReview or Autoland. (Although, there's a chance we may adopt some PGP-based signing to more strongly convey review for some code changes in order to facilitate stronger auditing and trust guarantees. Stay tuned.) Likewise, if a commit becomes associated with a bug, we can add that metadata to the commit before it is landed, no human involvement necessary beyond specifying the link in the MozReview web UI (or API). Autoland/MozReview will close review requests and/or bugs automatically. (Are you excited about performing less work yet?)
When commits are added to MozReview, MozReview will read metadata from the repository they came from to automatically determine an appropriate reviewer. (We plan to leverage moz.build files for this in the case of Firefox.) This should eliminate a lot of process debt around choosing a reviewer. Similar metadata will also be used to determine what Bugzilla component a change is related to, static analysis rules to use to critique the phsyical structure of the change, and even automation jobs that should be executed given the set of files that changed. The use of this metadata will erode significant process debt around the change contribution workflow.
As commits are pushed into MozReview/Autoland, the systems will be intelligent about automatically tracking dependencies and facilitating complex development workflows that people run into on a daily basis.
If I create a commit on top of someone else's commit that hasn't been checked in yet, MozReview will detect the dependency between my changes and the parent ones. This is an advantage of being code first: by interfacing with repositories rather than patch files, you have an explicit dependency graph embedded in the repository commit DAG that can be used to aid machines in their activities.
It will also be possible to partially land a series of commits. If I get review on the first 5 of 10 commits but things stall on commit 6, I can ask Autoland to land the already-reviewed commits so they don't get bit rotted and so you have partial progress (psychological studies show that a partial reward for work results in greater happiness through a sense of accomplishment).
Since initiating actions in MozReview is light weight (just hg push), itch scratching is encouraged. I don't know about you, but in the course of working on the Firefox code base, I frequently find myself wanting to make small, 15-30s changes to fix something really minor. In today's world, the overhead for these small changes is often high. I need to upload a separate patch to Bugzilla. Sometimes I even need to create a new bug to hold that patch. If that patch depends on other work I did, I need to set up bug dependencies then worry about landing everything in the right order. All of a sudden, the overhead isn't worth it and my positive intentions go unacted on. Multiplied by hundreds of developers over many years, and you can imagine the effect on software quality. With MozReview, the overhead for itch scratching like this is minor. Just make a small commit, push, and the system will sort everything out. (These small commits are where I think a bugless process really shines.)
This future world revolves around code and commits and operations on them. While MozReview has review in its name, it's more than a review tool: it's a database and interface to code and its state.
In this code first world, Bugzilla performs an ancillary role. Bugzilla is still there. Bugs are still there. MozReview review requests and commits link to bugs. But it is the code, not bugs, that are king. If you want to do anything with code, you interact with the code tools. And Bugzilla is not one of them.
Another way of looking at this is that nearly everything involving code or commits becomes excised from Bugzilla. This would relegate Bugzilla to, well, an issue/bug tracker. And - ta da - that's something it excels at since that's what it was originally designed to do! MozReview will provide an adequate platform to discuss code (a platform that Bugzilla provides today since it hosts code review). So if not Bugzilla tools are handling everything related to code, do you really need a bug any more?
This is the future we're trying to build with MozReview and Autoland. And this is why I think bugs and Bugzilla will play a less central role in the development process of Firefox in the future.
Yes, there are many consequences and concerns about making this shift. You would be rational to be skeptical and doubt that this is the right thing to do. I have another post in the works that attempts to outline some common conerns and propose solutions to many of them. Before writing a long comment pointing out every way in which this will fail to work, I encourage you to wait for that post to be published. Stay tuned.
Mozilla's Mercurial documentation has historically been pretty bad. The documentation on MDN (which I refuse to link to) is horribly disjointed and contains a lot of outdated recommendations. I've made attempts to burn some of it to the ground, but it is just too overwhelming.
I've been casually creating my own Mercurial documentation tailored for Mozillians. It's called Mercurial for Mozillians.
It started as a way to document extensions inside the version-control-tools repository. But, it has since evolved to cover other topics, like how to install Mercurial, how to develop using bookmarks, and how to interact with a unified Firefox repository. The documentation is nowhere near complete. But it already has some very useful content beyond what MDN offers.
I'm not crazy about the idea of having generic Mercurial documentation on a Mozilla domain (this should be part of the official Mercurial documentation). Nor am I crazy about moving content off MDN. I'm sure content will move to its appropriate location later. Until then, enjoy some curated Mercurial documentation!
If you would like to contribute to Mercurial for Mozillians, read the docs.
The bzexport Mercurial extension - an extension that enables you to easily create new Bugzilla bugs and upload patches to Bugzilla for review - just received some major updates.
First, we now have automated test coverage of bzexport! This is built on top of the version control test harness I previously blogged about. As part of the tests, we start Docker containers that run the same code that's running on bugzilla.mozilla.org, so interactions with Bugzilla are properly tested. This is much, much better than mocking HTTP requests and responses because if Bugzilla changes, our tests will detect it. Yay continuous integration.
Second, bzexport now uses Bugzilla' REST API instead of the legacy bzAPI endpoint for all but 1 HTTP request. This should make BMO maintainers very happy.
Third and finally, bzexport now uses shared code for obtaining Bugzilla credentials. The behavior is documented, of course. Behavior is not backwards compatible. If you were using some old configuration values, you will now see warnings when running bzexport. These warnings are actionable, so I shouldn't need to describe them here.
Please obtain the new code by pulling the version-control-tools repository. Or, if you have a Firefox clone, run mach mercurial-setup.
Thanks go out to Steve Fink, Ed Morley, and Ted Mielczarek for looking at the code.
As I was looking at the list of process debt contributing to Firefox, one thought kept creeping into my mind: how many of these items go away if we utilize GitHub?
As I mentioned in these two posts, GitHub's popularity has essentially commoditized many items on this list, especially the parts around source control and submitting patches for consideration (just fork and open a pull request). It seems that everyone these days is on GitHub and asking people to use GitHub to send changes to Firefox would almost certainly be well-received by contributors and even Mozilla staff.
Here's what I think: Mozilla should utilize GitHub for Firefox development.
The verb in that sentence is important: I purposefully said utilize and not something like switch to. To switch or not to switch to GitHub for Firefox development is a false dillemma and a logical fallacy. So is the question about switching to Git. As I explain later, there is a spectrum of options available and switching or not switching are on the extremes. Utilize doesn't preclude a binary switch or don't switch outcome, but it does keep an array of options on the table for consideration.
So, how should Mozilla utilize GitHub for Firefox development?
I think that insisting people establish Bugzilla accounts and upload patches to Bugzilla/bugs is an anitquated practice in desperate need of an overhaul. I think that if someone has written code, they should be able to essentially throw it over a wall to initiate the change process. They should be able to do this in a manner that incurs little to no process debt. We, Mozilla, should be able to take only code and integrate it into Firefox, assuming a trusted person - a module owner or peer - agrees and grants review. GitHub pull requests would facilitate a lesser-involved code contribution mechanism.
Another benefit of GitHub is that the web interface goes further than just code submission: they also have facilities for editing files. It's possible to edit a file in someone else's repository and create a pull request direct from the web interface! My post on process debt began by comparing the process of edit a wiki versus the current Firefox change process. GitHub's web-based editing essentially reduces the gap to cosmetic differences. GitHub's ease of contributing purely via the browser would open the door to more contribution for lesser-involved changes (sometimes referred to as good first bugs).
To state it explicitly, I support the use of GitHub pull requests for submitting changes to Firefox.
Now, there are some concerns and challenges about doing this. These include:
- Fragmentation of code review and tracking could be problematic for Mozilla staff and other highly-active individuals.
- GitHub can lose some parts of code review after rebasing and force pushes. Edit: Comments below indicate this is no longer a problem. Great!
- You can only assign 1 reviewer per pull request.
- GitHub sends an email/notification per review comment. This can be extremely annoying for some mail clients.
- GitHub doesn't have a mechanism for dealing with security bugs.
- Data sovereignty concerns (all data hosted on GitHub and subject to their data retention and access policies). Their API has query limits, which can limit machine use somewhat.
- GitHub's model favors merges over rebases. Merges have a number of downsides, especially for large projects, and we strongly prefer to maintain our mostly-linear Firefox repository history.
- GitHub's model favors appending commits rather than rewriting commits. (This is due to Git badness when you force push.) Mozilla favors a world where the final commit is what's reviewed and landed.
- Git != Mercurial. Firefox is canonically stored in Mercurial. There is some impedence mismatch here. But nothing tools can't overcome.
- The Merge Pull Request button is almost completely useless for Firefox's existing and future workflows. This partially invalidates other niceness the pure GitHub pull request workflow buys you.
- Everything is lumped into a single bucket. We lose component-level subscriptions, making following harder.
- Following the entire Firefox project on GitHub would produce an overwhelming fire hose of data.
- We don't control GitHub and our options for extending it to extract even more process optimization are limited to what their APIs support and what they choose to implement.
- We are at the whim of GitHub should they ever change a feature or API.
- See also Servo's list of challenges.
Some of these issues can be overcome by tools and automation (which I would happily build in my capacity as a Developer Productivity Engineer at Mozilla). Others are more fundamental and seemingly would require buy-in and/or support from very senior Mozillians.
If Mozilla were to go forward utilizing GitHub pull requests for Firefox, I think it should be done incrementally rather than going all-in and attempting the entire GitHub workflow from the start. Although, this would mean diverging from GitHub's well-known practices, which would increase process debt from the GitHub base level. I don't like that. But I think it is a step in the right direction. Partial reduction in process debt is better than no reduction.
What do I mean by incrementally start accepting pull requests? Well, I don't think code review should initially be conducted on GitHub. When you look at the above list of concerns, many of them are around code review and interacting with pull requests. I think there's too much badness and risk there to make me comfortable about moving things to GitHub and giving GitHub exclusive domain over this important data, at least initially.
But if code review isn't conducted on GitHub, what's the value of a pull request? A pull request would be a well-defined and well-understood mechanism for importing data into Mozilla's systems. For example, submitting a pull request would automatically result in the creation of a review request on MozReview or even a bug/attachment/review on Bugzilla. This would allow people to send code to Mozilla easily while simultaneously allowing Mozillians to use familiar tools and processes without the aforementioned concerns with GitHub. That appears to be win-win.
Once we have a simple mechanism in place for turning pull requests into MozReview's review requests, we can start playing around with the syncing of code review activity between Mozilla and GitHub so review activity on either system results in cross-posting. There is precedent for this today. GerritHub has bi-directional syncing of code review activity between GitHub and Gerrit. Facebook also does something similar, syncing data between their internal Phabricator instance. Mozilla to GitHub sync would not be difficult: we control all those systems and I'm pretty confident in our ability to make a GitHub API call when a MozReview review request is updated (we already make Bugzilla API calls, so we know this works). GitHub to Mozilla is a bit more difficult. But, others have done it: I'm confident we can too.
I see bi-directional syncing of GitHub pull request / code review data between GitHub and Mozilla as achievable and relatively free from controversy. I think we should experiment with this sometime in 2015, probably in Q2, once MozReview is in better condition to host GitHub pull requests. Although, supporting Git in MozReview is on my Q1 goals list, so maybe I sneak this into Q1. Time will tell.
At this time, I believe using GitHub for the ingestion of proposed Firefox commits into existing Mozilla systems should be the limit of Firefox's GitHub presence, at least as far as day-to-day development goes. If other groups want to use GitHub more actively and they find a way to make that work while placating everyone who cares, power to them. But I think moving the pendulum any further toward GitHub - including things like making GitHub the exclusive location for code review data, utilizing GitHub Issues, and making Git[Hub] the canonical Firefox repository - remain difficult and controverial propositions. I believe each of these to be medium to high cost and risk with low to medium reward. I believe it would be wise to defer these questions until we have data about the value of GitHub pull requests for Firefox development.
To summarize, I propose using GitHub pull requests as an alternate, supported front end to the code contribution pathway. We would eliminate a lot of process debt for non-Mozillians by supporting a known process. Mozillians on the review and code submission side of the process shouldn't have to worry about change because, well, it shouldn't matter if a commit came from GitHub or elsewhere: it will all appear mostly the same. I'm not saying that we will never expand our utilization of GitHub for Firefox development beyond this scope. But I am saying that I don't think it would be prudent to do so today.
And that's how and why I think Mozilla should utilize GitHub for Firefox development.
While I'm here, it's important to note that GitHub does not and will likely never solve many items from our list of Firefox contribution process debt. GitHub is not a build system nor a tool for running and analyzing code and tests. We still have many, many deficiencies and usability concerns here. We have historically under-invested in this area and utilizing GitHub in any capacity won't address these other issues. In addition, Firefox is a magnitude larger and more complex than the vast majority of projects on GitHub. We will always be burdened with the cost of our success - of coping with and maintaining the additional complexity associated with that scale. Firefox is at least the 0.1%. There's a good chance GitHub and/or many of the amazing services associated with it (like Travis-CI) won't scale to our needs. I'd love to be proved wrong here, but the reality is supporting a marginal use case like Firefox likely isn't at the top of goals for GitHub and related organizations unless it is in their business interest (read: financial interest) to do so. One can hope that as these companies try to capture more of the enterprise market via offerings such as GitHub Enterprise that they invest in the features and scalability that large projects and organizations like Mozilla and Firefox need.
The ascendancy of GitHub has very little to do with its namesake tool, Git.
What GitHub did that was so radical for its time and the strategy that GitHub continues to execute so well on today is the approach of putting code first and enabling change to be a frictionless process.
In case you weren't around for the pre-GitHub days or don't remember, they were not pleasant. Tools around code management were a far cry from where they are today (I still argue the tools are pretty bad, but that's for another post). Centralized version control systems were prevalent (CVS and Subversion in open source, Perforce, ClearCase, Team Foundation Server, and others in the corporate world). Tools for looking at and querying code had horrible, ugly interfaces and came out of a previous era of web design and browser capabilities. It felt like a chore to do anything, including committing code. Yes, the world had awesome services like SourceForge, but they weren't the same as GitHub is today.
Before I get to my central thesis, I want to highlight some supporting reasons for GitHub's success. There were two developments in the second half of the 2000s the contributed to the success of GitHub: the rises of the distributed version control system (DVCS) and the modern web.
While distributed version control systems like Sun WorkShop TeamWare and BitKeeper existed earlier, it wasn't until the second half of the 2000s that DVCS systems took off. You can argue part of the reason for this was open source: my recollection is there wasn't a well-known DVCS available as free software before 2005. Speaking of 2005, it was a big year for DVCS projects: Git, Mercurial, and Bazaar all had initial releases. Suddenly, there were old-but-new ideas on how to do source control being exposed to new and willing-to-experiment audiences. DVCS were a critical leap from traditional version control because they (theoretically) impose less process and workflow limitations on users. With traditional version control, you needed to be online to commit, meaning you were managing patches, not commits, in your local development workflow. There were some forms of branching and merging, but they were a far cry from what is available today and were often too complex for mere mortals to use. As more and more people were exposed to distributed version control, they welcomed its less-restrictive and more powerful workflows. They realized that source control tools don't have to be so limiting. Distributed version control also promised all kinds of revamped workflows that could be harnessed. There were potential wins all around.
GitHub launched in April 2008 standing on the shoulders of both the emerging interest in the Git content tracking tool and the capabilities of modern browsers.
I wasn't an early user of GitHub. My recollection is that GitHub was mostly a Rubyist's playground back then. I wasn't a Ruby programmer, so I had little reason to use GitHub in the early stages. But people did start using GitHub. And in the spirit of Ruby (on Rails), GitHub moved fast, or at least was projecting the notion that they were. While other services built on top of DVCS tools - like Bitbucket - did exist back then, GitHub seemed to have momentum associated with it. (Look at the archives for GitHub's and Bitbucket's respective blogs. GitHub has hundreds of blog entries; Bitbucket numbers in the dozens.) Developers everywhere up until this point had all been dealing with sub-optimal tools and workflows. Some of us realized it. Others hadn't. Many of those who did saw GitHub as a beacon of hope: we have all these new ideas and new potentials with distributed version control and here is a service under active development trying to figure out how to exploit that. Oh, and it's free for open source. Sign me up!
GitHub did capitalize on a market opportunity. They also capitalized on the value of marketing and the perception that they were moving fast and providing features that people - especially in open source - wanted. This captured the early adopters market. But I think what really set GitHub apart and led to the success they are enjoying today is their code first approach and their desire to make contribution easy, and even fun and sociable.
As developers, our job is to solve problems. We often do that by writing and changing code. And this often involves working as part of a team, or collaborating. To collaborate, we need tools. You eventually need some processes. And as I recently blogged, this can lead to process debt and inefficiencies associated with them.
Before GitHub, the process debt for contributing to other projects was high. You often had to subscribe to mailing lists in order to submit patches as emails. Or, you had to create an account on someone's bug tracker or code review tool before you could send patches. Then you had to figure out how to use these tools and any organization or project-specific extensions and workflows attached to them. It was quite involved and a lot could go wrong. Many projects and organizations (like Mozilla) still practice this traditional methology. Furthermore (and as I've written before), these traditional, single patch/commit-based tools often aren't effective at ensuring the desired output of high quality software.
Before GitHub solved process debt via commoditization of knowledge via market dominance, they took another approach: emphasizing code first development.
GitHub is all about the code. You load a project page and you see code. You may think a README with basic project information would be the first thing on a project page. But it isn't. Code, like data, is king.
Collaboration and contribution on GitHub revolve around the pull request. It's a way of saying, hey, I made a change, will you take it? There's nothing too novel in the concept of the pull request: it's fundamentally no different than sending emails with patches to a mailing list. But what is so special is GitHub's execution. Gone are the days of configuring and using one-off tools and processes. Instead, we have the friendly confines of a clean, friendly, and modern web experience. While GitHub is built upon the Git tool, you don't even need to use Git (a tool lampooned for its horrible usability and approachability) to contribute on GitHub! Instead, you can do everything from your browser. That warrants repeating: you don't need to leave your browser to contribute on GitHub. GitHub has essentially reduced process debt to edit a text document territory, and pretty much anybody who has used a computer can do that. This has enabled GitHub to dabble into non-code territory, such as its GitHub and Government initiative to foster community involvement in government. (GitHub is really a platform for easily seeing and changing any content or data. But, please, let me continue using code as a stand-in, since I want to focus on the developer audience.)
GitHub took an overly-complicated and fragmented world of varying contribution processes and made the new world revolve around code and a unified and simple process for change - the pull request.
Yes, there are other reasons for GitHub's success. You can make strong arguments that GitHub has capitalized on the social and psychological aspects of coding and human desire for success and happiness. I agree.
You can also argue GitHub succeeded because of Git. That statement is more or less technically accurate, but I don't think it is a sound argument. Git may have been the most feature complete open source DVCS at the time GitHub came into existence. But that doesn't mean there is something special about Git that no other DVCS has that makes GitHub popular. Had another tool been more feature complete or had the backing of a project as large as Linux at the time of GitHub's launch, we could very well be looking at a successful service built on something that isn't Git. Git had early market advantage and I argue its popularity today - a lot of it via GitHub - is largely a result of its early advantages over competing tools. And, I would go so far to say that when you consider the poor usability of Git and the pain that its users go through when first learning it, more accurate statements would be that GitHub succeeded in spite of Git and Git owes much of its success to GitHub.
When I look back at the rise of GitHub, I see a service that has succeeded by putting people first by allowing them to capitalize on more productive workflows and processes. They've done this by emphasizing code, not process, as the means for change. Organizations and projects should take note.
« Previous Page -- Next Page »