The GitHub Blog: General

Last month, we released the Octocat figurine, finally taking our mascot into the third dimension. For years, we’ve illustrated her in different themes—from human culture to pop culture—so a figurine seemed like the next logical step.

We all wanted Octocats on our desks, but we were new to the vinyl figurine world. Here’s a look into the journey we took to make this idea a reality.

Sculpting the facial structure

We began with her profile. The Octocat is the sum of two merged animals, but where does one animal begin and the other end? Her tentacles clearly originate from an octopus, but we had to decide which animal traits would define her head shape. She also needed some human characteristics to help round out the feline and cephalopod.

Anthropomorphizing animals is nothing new to character design. It helps us relate to a character through traits we find in our own species. Eyes are common elements to anthropomorphize because of their importance for visual communication. They help to emote and give personality, which is why we felt they would be important to emphasize, considering the size of her eyes in relation to her head.

To make the Octocat relatable, we extended her nose and mouth off her face giving the slight impression of a snout. Her ears and whiskers are important elements of her silhouette so we didn’t alter them. We choose to stretch the Octopus epidermis from her tentacles to her head giving her that smooth texture commonly found in sea creatures. This helps to reduce surface friction while swimming and helps to alleviate the unseemly byproduct of cat fur: hair balls. Here is one of our early concepts:

Solving the tentacle debate

Our next challenge was the tentacle count. Does she have eight tentacles or four legs and a tail? This particular dilemma has long been a point of contention and debate among GitHubbers. In the two dimensional world it was easy to leave this question ambiguously unanswered, but in three dimensions we were finally forced to choose.

Part of the beauty of the Octocat is her paradoxical nature, being a mixture of creatures stuck between worlds. She has been represented as a quadruped, a biped, and a pentaped, but never an octoped. While we absolutely respect the opinion of our eight tentacles favoring friends, with eight she would feel inauthentic, so we chose to stick with five.

With the tentacle count question settled, we focused next on her stance. With any mascot, recognition is paramount. Our goal was to design the figurine so the front view would look as close to the original image as possible. The Octocat is both a land and sea creature. She is quick and limber. Gravity and balance are less challenging under water but when she moves onto dry land these elements prove to be much more difficult. You’ll notice her original stance does not take this into consideration. If we were to keep the exact same tentacle pose from the front but in a position that would support her giant head, it would have to be one of these two choices:

We were not happy of these two options considering how unnatural they felt, so we decided to make a compromise. In the interest of creating a cartoony yet believable organic creature we had to do some repositioning. The end result was a pentagon configuration which would serve as the base of her tentacles. This meant the elasticity of the tentacles would absorb the weight of her large head, giving them a more round organic shape.

Perfecting the final product

With our design in place, we received our first samples. From here, it took a series of small adjustments to get us to production.

Designing the right package

Packaging was just as important to us as the figurine itself; we wanted the box to be emblematic of its precious cargo. We tried our a wide variety of concepts from shipping containers to Octocat head shaped boxes:

In the end, we found that simplicity was the best option:

The end result

The final product is an Octocat figurine we’re really excited about. Huge thanks to all the amazing people at Dead Zebra who helped us along the way.

We hope you enjoy her as much as we do.

Microsoft announced at their Connect event last week that they will be open sourcing much of the .NET technology stack, as well as moving development of these technologies over to GitHub.

And within hours of the announcement contributions were already being accepted!

You can browse and search the projects that Microsoft has made public on GitHub over on their landing page.

This isn't the first team from Microsoft to join us on GitHub - the Microsoft Azure, Microsoft Open Tech, TypeScript and ASP.NET teams are already on GitHub, collaborating in the open with the community.

If you're one of the 6 million developers building applications using .NET, this is your chance to contribute to the future direction of your development stack. Check out the GitHub help site or GitHub Guides to learn more about contributing to open source.

This week we will be conducting a "brownout" of all misconfigured GitHub Pages sites. If your GitHub Pages site's DNS is pointed at an out-of-date IP address, we will intermittently serve a warning page in place of your site's content. We will update our status site before we do so, and normal functionality will resume at the conclusion of the brownout.

If you use a custom domain with GitHub Pages, please verify that your domain's DNS settings are properly configured to point to the most up-to-date GitHub IP addresses. This will ensure that your site remains available this week and continues to remain available after December 1st, 2014.

For information on how to tell if your site is affected and what to do to fix it, see the original GitHub Pages Legacy IP Deprecation announcement or the setting up a custom domain with GitHub Pages documentation.

Of course, if you have any questions, we're here to help.

For years, the Octocat has been stuck in the realm of two dimensions—but no more! Now she’s crawling off your laptop and onto your desk as a 5" vinyl figurine.

Check out the Octocat in the GitHub shop.

To bring more transparency and clarity to the processes surrounding the DMCA, we are rolling out three improvements to the way we process copyright takedowns:

First, whenever possible, users will have a chance to fix problems before we take content down.
Second, we will not automatically disable forks in a network based on the takedown of a parent repository unless the takedown notice explicitly includes them.
Last but not least, we've published a completely revamped DMCA policy as well as a pair of how-to guides for takedown and counter notices to make our process more transparent and easier to understand.

Some Background

The Digital Millennium Copyright Act (DMCA) is a United States law that establishes how copyright holders must file complaints with internet service providers (ISPs) like GitHub, and what the ISPs must do in response.

The DMCA takedown process usually takes place behind closed doors, with little visibility for impacted users, let alone the opportunity for those users to modify the allegedly infringing content. The average DMCA policy is also usually written in dense legalese that can be difficult to understand.

Our users deserve better. GitHub already promotes transparency by posting DMCA takedown notices in a public repository. And our Support Team works hard to help our users navigate the process.

Like most other ISPs, we have been disabling content whenever we receive a complete and seemingly legally adequate DMCA notice. We have learned, however, that the conventional process is not a perfect fit for Git-versioned software projects. So we decided to make some changes.

GitHub's New Policy

The first change is that from now on we will give you an opportunity, whenever possible, to modify your code before we take it down. Previously, when we blocked access to a Git repository, we had to disable the entire repository. This doesn't make sense when the complaint is only directed at one file (or a few lines of code) in the repository, and the repository owner is perfectly happy to fix the problem.

In practice, our support team would often shuttle messages between the parties to work out a way for them to fix it. That usually worked out well and everyone ended up happier at the end of the day. So we are making it a formal part of our policy, and we are going to do it before we disable the rest of the repository.

The second change is that if we receive a takedown notice for a parent repository, we will not disable forks in the network unless they are specifically identified in the notice. In our system, parent and fork repositories are linked so that if one is disabled, they are all automatically disabled. In many cases, however, forked repositories may be different in significant ways from the parent. Accordingly, from now on we will require copyright owners to investigate and report each fork explicitly in a DMCA takedown notice. If some forks are not identified, we will split up the network to avoid needlessly disabling unnamed fork repositories.

Finally, we've also taken this opportunity to completely revamp our DMCA policy itself so that it is easier to understand, provides more background information, additional resources and outlines the process in detail. We want you to understand clearly what a takedown means, how to submit a takedown notice to GitHub, and how to respond to one if you believe there has been a mistake and want your content restored. We hope you find our revised policy easier to use.

Please feel free to email us with questions or comments at copyright@github.com.

The entries are in, the votes are tallied, and we've chosen the winners for our third annual Data Challenge!

First Place

Our first place winner is Issue Stats (repository), by @hstove.

Issue Stats tracks the time it takes for your project to close issues or merge pull requests. You can then display this data through a convenient badge in your project's README file or elsewhere. Issue Stats are easy to get started with, easy to understand, and simple to incorporate into your project — be sure to also check out the other analyses and visualization too.

Second Place

In second place is GitHut (repository), by @littleark.

Moving through the quarters of the calendar year, GitHut compares programming languages by development activity (via active repositories and push volume), collaboration (via forks and issues), social activity (new watchers on GitHub), and the language's age. GitHut makes it easy to compare and contrast languages over many metrics without overwhelming the viewer.

Third Place

The third place winner is Eigenfaces, by @c-w.

The Eigenfaces project sampled about 8,000 user avatars, after filtering for automatically generated pictures (like Identicons) and other outliers, then used a machine learning technique called principal component analysis to reduce these avatars to the 20 most significant "features". Each "feature" is interpretable as a shape that contributes significant amounts of variance to the entire body of avatars that were sampled.

Congratulations and Thanks!

Congratulations to our three winners! The first place winner receives travel, lodging, and attendance to Presenting Data and Information, a one-day course offered by Edward Tufte this December in San Francisco. Our second and third place winners will receive cash prizes.

Each year we receive entries that raise the bar for quality and exceed our expectations — this year was no exception. In fact, this year we received a record 79 entries from all over the world! We want to extend our sincere thanks to every individual and team that submitted an entry this year. We're extremely gratified by the level of craftsmanship and creativity exhibited by your entries, and humbled by the obvious amount of work involved. Thank you!

We hope you enjoyed checking out this year's winning entries. We can't wait for next year.

GitHub has always been about making open source software better, and today we're launching TODO with a number of partners to help large organizations better support the open source community. If your company has an open source program–or is looking to initiate one–we hope you'll join us.

With TODO, we want to talk openly and develop openly to solve the unique challenges of using and building open source technologies within companies of all sizes. We plan to explore topics like what it looks like to release open source projects, how to shift ownership of projects from companies to the community, and how to make sure that open source projects remain healthy and active.

The inaugural members of TODO include Box, Dropbox, Facebook, GitHub, Google, Khan Academy, Square, Stripe, Twitter, and Walmart Labs. You can visit todogroup.org to sign up and learn more.

Our open and free Internet fuels some of the most incredible innovation in history. It provides new opportunities for billions of people to communicate and collaborate, contributes to economic growth across the world, supports a flourishing open source community, and changes the way we live our lives for the better.

GitHub stands in solidarity with our Internet peers in urging all our US-based users, customers, and fans to call, write, or tweet at your local Senator or Congressperson to let them know you oppose the FCC's proposed changes to the net neutrality landscape.

We believe a new Internet "fast lane" that only privileged businesses can buy into threatens freedom of choice for users, and could ultimately harm the efforts of developers building and shipping both open source and commercial software. Without net neutrality, your users could have a very different experience of your software depending on how much Internet providers are paid.

Congress has the power to take real action to ensure the Internet remains an open platform for speech and commerce. For example, when cable television called into question the traditional conflict between physical point-to-point telephone communication and airwave television broadcasts, Congress responded by adding Title VI to the Communications Act.

GitHub believes that with encouragement and education from the broader Internet community, Congress can be motivated to take action once again. In May of this year, we indicated our support of net neutrality by co-signing a letter to the FCC, but we're not there yet.

We think an open and free Internet is a better Internet, and today we’re asking you to join us by telling Congress you agree.

In the summer of 2009, The New York Senate was the first government organization to post code to GitHub, and that fall, Washington DC quickly followed suit. By 2011, cities like Miami, Chicago, and New York; Australian, Canadian, and British government initiatives like GOV.UK; and US Federal agencies like the Federal Communications Commission, General Services Administration, NASA, and Consumer Financial Protection Bureau were all coding in the open as they began to reimagine government for the 21st century.

Fast forward to just last year: The White House Open Data Policy is published as a collaborative, living document, San Francisco laws are now forkable, and government agencies are accepting pull requests from every day developers.

This is all part of a larger trend towards government adopting open source practices and workflows — a trend that spans not only software, but data, and policy as well — and the movement shows no signs of slowing, with government usage on GitHub nearly tripling in the past year, to exceed 10,000 active government users today.

How government uses GitHub

When government works in the open, it acknowledges the idea that government is the world's largest and longest-running open source project. Open data efforts, efforts like the City of Philadelphia's open flu shot spec, release machine-readable data in open, immediately consumable formats, inviting feedback (and corrections) from the general public, and fundamentally exposing who made what change when, a necessary check on democracy.

Unlike the private sector, however, where open sourcing the "secret sauce" may hurt the bottom line, with government, we're all on the same team. With the exception of say, football, Illinois and Wisconsin don't compete with one another, nor are the types of challenges they face unique. Shared code prevents reinventing the wheel and helps taxpayer dollars go further, with efforts like the White House's recently released Digital Services Playbook, an effort which invites every day citizens to play a role in making government better, one commit at a time.

However, not all government code is open source. We see that adopting these open source workflows for open collaboration within an agency (or with outside contractors) similarly breaks down bureaucratic walls, and gives like-minded teams the opportunity to work together on common challenges.

Government Today

It's hard to believe that what started with a single repository just five years ago, has blossomed into a movement where today, more than 10,000 government employees use GitHub to collaborate on code, data, and policy each day.

Those 10,000 active users make up nearly 500 government organizations, from more than 50 countries:

Government code on GitHub spans more than 7,500 repositories with @alphagov, @NCIP, @GSA, and @ministryofjustice being the top open source contributors with more than 100 public repositories each:

You can learn more about GitHub in government at government.github.com, and if you're a government employee, be sure to join our semi-private peer group to learn best practices for collaborating on software, data, and policy in the open.

Happy collaborative governing!

So many of us here at GitHub have benefited from early exposure to science, technology, engineering, and mathematics that we're always looking for ways to help young people develop a genuine interest in technical fields.

We can't think of a better (or more fun) way to help inspire a life-long love of science than to encourage students to experiment with robotics. That's why we're proud to be a sponsor of FIRST (For Inspiration and Recognition of Science and Technology).

FIRST Robotics Competition

Every year, FIRST brings together coaches, industry mentors, and volunteers to help students from all over the world learn by building robots. Its oldest program, the FIRST Robotics Competition (FRC), is geared towards high school students. In 2014, over 50,000 students on more than 2,000 teams participated in FRC.

This year's competition had teams build robots that could transport balls and score goals, with the assistance of a human player. We traveled to St. Louis, MO, for the world championship and made a video about the competition:

FIRST Robotics on GitHub

GitHub supports FIRST to help give students and teachers first-hand experience with software development tools used in the industry. Individual teams host their sites with GitHub Pages, students collaborate on control and vision code across teams, mentors teach code review, teams release applications for scouting, and at least one team (@iLiteRobotics) has released 3D models of all of their robot parts.

Here are just a few examples of how FIRST teams are using GitHub:

GitHub Pages Sites

Code on GitHub

3D Models

Get involved with FIRST

FIRST is a team effort. Coaches, industry mentors, and volunteers are all essential to the continued success of the organization. Here are some ways that you can get involved:

Individuals

Attend a local FIRST event.
Volunteer with an team or regional competition.
Start a new team.

Organizations

Encourage your employees to volunteer and mentor.
Sponsor a local team, especially the teams your employees volunteer with.
Offer a scholarship to participants.
Become a kit of parts supplier.

GitHub's annual data challenge is back, and we can't wait to see what you'll build this year, be it beautiful generative art or full blown, third-party activity dashboards. Check out the winners from 2013 and 2012 for some inspiration.

The Details

Entries are generally visualizations, prose descriptions of data analyses, or both. We love innovative entries, so an "entry" is defined somewhat loosely.

There are only three rules:

To enter, you must fill out our submission form by midnight PDT on August 25th, 2014.
Your entry needs to use publicly available GitHub data from any number of available sources described below.
Show your work! Whatever you submit needs associated code or documentation describing what data you used and how you processed it. Some examples of what we're looking for include code (and instructions to use it) in a GitHub repository, an academic write-up of your analysis, or an informal prose write-up. If you're not linking to a repository, you should submit a Gist with your documentation.

After the submission deadline on August 25th, GitHub employees will review and vote on all entries to pick the three top winners. We'll send out notifications to those top three by mid-September.

Data Sources

GitHub activity data is available from several publicly-available sources. Here are a few links to get you started:

Our very own API.
The GitHub Archive, providing historical archives of our public timeline data.
Google BigQuery, where GitHub's public timeline is a featured public dataset; see the GitHub Archive home page for getting started instructions.
GHTorrent, which maintains a relational model of GitHub activity data and offers archives for download.

ProTips

There are a few things we're looking for when we score your entry:

Innovation/Story: Does your entry tell a good, data-driven story? Does it reveal interesting insights about GitHub activity? We love it when we're surprised by new insights hidden in our own data.
Accuracy: Is your analysis accurate? Do accompanying visualizations clearly and unambiguously convey your conclusions?
Completeness: Is your entry a code submission? If so, is your code well-organized and documented? Can others easily understand and reproduce your analysis from the materials you've submitted?

The Prizes

The winning entry in this year's data challenge will receive an all-expense paid trip to attend a one-day data visualization course taught by Edward Tufte, a data visualization expert and the author of some of our favorite books on visualization. We'll cover your enrollment for the course (either December 18th or 19th in San Francisco, CA), along with travel expenses to and from San Francisco, lodging at a nearby hotel for two nights (the evening before and of the course), and your meals.

The second and third prize contestants will receive $500 and $250 cash prizes, respectively.

Finally, all winners will have their GitHub profile and their data challenge entry publicly featured on our blog!

If you have questions about the data challenge rules, drop us a line at data@github.com. Good luck!

We're happy to announce a new Patchwork hack night at the beautiful ustwo studio in London.

Learning open source, together

Patchwork is a hands-on workshop for learning Git and GitHub. We'd love for you to join us. There will be snacks for fortified hackin', lots to learn, and new friends to be made.

Forks you don't eat with? Branches not made of wood?

Attendees will leave with a merged pull request, a square on your contributions graph, and confidence to get more involved in the exciting world of open source.

Let's do this

Are you ready to show the open source community what you've got? Myself, @muan, @andrew, @lildude, @shiftkey, @tobiasahlin, other GitHub staff and community mentors will be on hand to answer your questions.

No coding experience required!

Want to learn Git and Github? RSVP as an attendee.
Want to help guide future open source maintainers and contributors? RSVP as a mentor.

Details:

For: Git and GitHub beginners.
When? Wednesday, June 18th from 6:30-8:30pm.
Where? ustwo's studio at 62 Shoreditch High St, London E1 6JJ, United Kingdom.
Bring: Make sure you bring your laptop with Git-it installed (we'll help you if you get stuck).

Once registered, you'll receive an email a few days before the event with a few more details on Git-it, so you can hit the ground running.

Back in April I said we would share the new initiatives we're launching to ensure GitHub is a welcoming and inclusive company. This work is long term and will remain a constant focus for us, but I wanted to share some of the progress we've made so far.

A few weeks ago we identified a number of areas we'd like to improve, and so far we've focused our early efforts on three in particular: the experiences of women at GitHub, improving feedback, and supporting diversity both internally and externally.

Task Force

In April, a group of employees formed a task force to explore the experiences of female employees at GitHub and surface any issues that might not be obvious. The group has been gathering feedback from some of the women at the company, meeting regularly to discuss, and sharing this feedback internally.

The task force has been using a repository to discuss new ideas and individual experiences, which has been helpful in opening up the discussion to the whole company. We know not everyone wants to share their experiences openly and we are working on developing a formal feedback system (more on that later), but we have already received some good ideas and feedback from the people who have participated.

The big themes we've heard so far:

We all need to get better at respectful and constructive feedback and communication, both verbal and written.
We need to better educate employees on everyone's role and function, and we need to especially get better about understanding and appreciating people in non-developer roles.
We need to do more to celebrate and increase diversity within the company, including women.

Some of the things we're doing based on this feedback:

We’re in the planning stages of designing a diversity and communication training curriculum for GitHub employees with input from Hubbers and external experts. Topics will include diversity training, effective communication, giving and receiving peer feedback, and conflict resolution.
We have started informal internal workshops focused on developing leadership skills, and we are looking to create more formalized training programs by early next year.
We have started an internal cross-training program where different teams within GitHub educate other teams on what they do. This is part of our push to help everyone understand how different roles and skills contribute to making GitHub work.

The task force will continue to meet, gather feedback, and discuss ways we can improve, and we're encouraging everyone to participate in these discussions. We will also continue to gather feedback from every employee so we know what we can do better.

Improving Feedback

GitHub has historically operated without any formal feedback system. While we've tried to encourage employees to give each other direct feedback, the lack of clear process and training left Hubbers on their own to understand how and when to have conversations with other people in the company.

We are currently in the process of developing and implementing a formal, documented feedback system for everyone in the company. So far we've begun rolling this out in Engineering, our largest department, and we intend to take it further. Our goal is to ensure that everyone has frequent, constructive feedback and someone they can go to with questions or concerns who can help them. We want people to know where they stand and that someone has their back, and in the past we haven't been good at this.

We've also been expanding our HR team since hiring a head of HR in January and are using their experience to help develop this system, from the communication training program I mentioned earlier to clear steps to take when you need help.

Supporting Diversity

Supporting diversity has always been important to us but recently we've been ramping up our support, participation, and sponsorships for community groups and events that promote diversity in tech. This includes sponsoring more groups focused on helping women in tech and sending employees to conferences focused on these issues, such as the The Grace Hopper Celebration of Women in Computing.

We’re also planning to use the community space at our San Francisco headquarters to sponsor and host more frequent diversity-focused events, including events led by community organizations, official GitHub events, classes, and meetups.

If you’re interested in using our space, are seeking sponsorship, or have an idea for how we can help, please let us know: https://community.github.com

One of the biggest lessons I've learned over the past few weeks is improving isn’t just about developing solutions - a huge part is getting good at surfacing problems. Without a solid feedback system, without talking to people regularly, without explicitly focusing on these issues, without asking people how they're doing and having them feel safe telling you the truth, you'll never know what the real problems are. If people feel like they can't speak up, you'll never hear what they have to say, and you'll never know they're not saying it.

Making GitHub a great place for everyone is something we have to work towards every day. In the future we’ll continue to post about new initiatives, updates on our progress, information on how our philosophies around things like sponsorships are evolving, and details on events we're hosting or participating in. Consider this post the first of many.

GitHub is being used today to build scientific software that's helping find Earth-like planets in other solar systems, analyze DNA, and build open source rockets.

Seeing these projects and all this momentum within academia has pushed us to think about how we can make GitHub a better tool for research. As scientific experiments become more complex and their datasets grow, researchers are spending more of their time writing tools and software to analyze the data they collect. Right now though, these efforts often happen in isolation.

Citable code for academic software

Sharing your work is good, but collaborating while also getting required academic credit is even better. Over the past couple of months we've been working with the Mozilla Science Lab and data archivers, Figshare and Zenodo, to make it possible to get a Digital Object Identifier (DOI) for any GitHub repository archive.

DOIs form the backbone of the academic reference and metrics system. With a DOI for your GitHub repository archive, your code becomes citable. Our newest Guide explains how to create a DOI for your repository.

Academic accounts on GitHub

We also know that as a scientific researcher, sometimes you're going to want to work privately. That's why we've created a discount where individual academic researchers can receive a free micro plan with 5 private repos, while research groups can receive a free silver plan with 20 repos.

To set up an academic account on GitHub, first associate an academic email address with your account and then request a GitHub Education discount.

Awesome science happening on GitHub

If you're interested in seeing all the science happening on GitHub, check out some of our favorite projects, including rOpenSci. This group recently held a Hackathon at GitHub HQ, where their team worked with collaborators from academia, business, and various research labs to build open source tools for science.

Lots of businesses today are experimenting with open source, both by maintaining open source projects and also by internalizing open source workflows. However, adopting open source tools in a business context often presents a steep learning curve. Implementation isn't always straightforward, and cultural changes can sometimes be long-term and tedious.

On Wednesday, May 28, 2014, we've invited a set of speakers to GitHub HQ to talk more about this topic for our first ever public Town Hall, moderated by Eric Knorr, Editor In Chief of InfoWorld. Join us to hear more about how open source is evolving inside companies from:

Chris Aniszczyk, Twitter
Kurt Chase, Autodesk
Dominik Tornow, SAP
Nate McWherter, GE

Event Details

When: Wednesday, May 28, 5-9 pm
Where: GitHub HQ, 88 Colin P Kelly Jr. Street, San Francisco CA
Space Limited: Please RSVP

Update: If you're not able to attend the Town Hall in person, we will have a live stream available. We'll share the link here and on Twitter next week before the event starts.