The Wayback Machine - https://web.archive.org/web/20160517134919/https://github.com/blog/category/general
Skip to content

Introducing unlimited private repositories

unlimited private repositories

We couldn’t be more excited to announce that all of our paid plans on GitHub.com now include unlimited private repositories. GitHub will always be free for public and open source projects, but starting today there are just two ways to pay for GitHub.com:

  • Personal: $7/month
  • Organization: $9/user/month, $25/month for your first five users

One of the very best things about Git and other distributed version control systems is the ability to create a new repository without asking permission or getting approval. While this has always been true for our public plans, it hasn’t been the case for individuals and teams working together in private. All that changes today.

If you’re new to GitHub, you can sign up to start using unlimited private repositories. If you’re already using GitHub.com, read on to learn how these changes will impact you.

Individual developers

If you’re using GitHub for private projects, now there’s just one paid plan—unlimited private repositories for $7/month. No matter what you were paying before, your plan now includes as many repositories as you need to work on projects in private—you can even invite collaborators.

Over the next few days, we will automatically move all paid accounts, from Micro to Large, to the new plan. If you’re currently paying for one of those larger plans, look out for a prorated credit on your account.

Organizations

If you’re currently paying for one of our organization plans, you’ll have the option to upgrade to unlimited private repositories at any time. For many of you, this change will mean immediate freedom from repository limits and a better way to grow and pay for GitHub.

We want everyone to have a plan with unlimited private repositories, but don’t worry—you are welcome to stay on your current plan while you evaluate the new cost structure and understand how to best manage your organization members and their private repository access. And while we're currently not enforcing a timeline to move, rest assured that you'll have at least 12 months notice before any mandated change to your plan.

A better way to work

We’ve heard from developers across our community that this new model is a better way to work. We agree—through years of building our business and developing GitHub for you, we've seen first hand the advantages of working without private repository limits. We hope you’ll create more repositories, write more code, and keep doing amazing things with GitHub.

As always, we’re here to help. Take a look at our new plans, learn how to update your personal or organization plan, or get in touch—we’d love to hear from you.

Frequently asked questions

For a paid organization on GitHub.com what kind of users will be charged?

You must purchase a seat for each user in your GitHub.com organization. These users fill a seat:

  • Organization members and owners
  • Pending invitations
  • Outside collaborators with access to 1 or more private repositories

These users do not fill a seat:

  • Outside collaborators with access to only public repositories
  • Billing managers

Will GitHub force me to move to per-user pricing after 12 months?

No. At this time we are not enforcing a timeline to move and if in the future we do decide to set a timeline we are committing to giving you at least 12 months.

I am an existing organization customer and prefer the per-repository plans. Can I remain on my current plan?

Yes, you can choose to continue paying based on the number of repositories you use. You can also upgrade or downgrade in the legacy repository structure based on the number of repositories you need.

Can there be collaborators on private repositories for the personal plan?

Yes. A paid personal account allows you to invite collaborators directly to your private repositories. If you need more granular permissions beyond full access, an organization plan is recommended.

Electron 1.0 is here

For two years, Electron has lowered the barrier to developing desktop applications—making it possible for developers to build cross-platform apps using HTML, CSS, and JavaScript. Now we’re excited to share a major milestone for Electron and for the community behind it. The release of Electron 1.0 is now available from electron.atom.io.

New to Electron? Electron is an open source framework that can help you build apps for Mac, Windows, and Linux. See how:

What’s new in Electron 1.0

Electron 1.0 comes with API stability and usability improvements, and makes it simpler than ever to explore and learn about Electron APIs with a new app, Electron API Demos. We’re also releasing and improving upon a couple tools that help developers along the way.

Read the full story on the Electron blog

Built on Electron

In just the last year, we’ve seen 1.2 million downloads and a growing community of hundreds of developers, open source maintainers, and companies who use the framework as the foundation of their apps. They’ve built everything from email, chat, and Git apps to SQL analytics tools, torrent clients, and robots. Take a tour of even more Electron apps to see what’s possible.

Electron downloads

Electron 1.0 is the result of a community effort by hundreds of developers, building amazing things. Are you ready to build your first Electron app? Get started with our quick start guide—we can’t wait to see what you create.

GitHub Pages drops support for RDiscount, Redcarpet, and RedCloth (Textile) markup engines

Back in February, we announced, that GitHub Pages would be dropping support for the RDiscount, Redcarpet, and RedCloth (Textile) markup engines, and today we're making it official.

For the vast majority of users, making the switch should be easy, as kramdown supports all of RDiscount and Redcarpet's most popular features. If you're making the transition from Textile, follow these instructions to upgrade your site to Markdown.

In standardizing on a single Markdown engine, we're able to simplify and improve the publishing experience, by removing much of the confusion and complexity associated with the differences between various markdown interpretations, bringing things more closely in line with what you'd expect from Markdown rendering on GitHub.com. See last month's blog post on the subject, for more context behind our decision.

If you're still using RDiscount, Redcarpet, or RedCloth, next time you push to your GitHub Pages site, you will receive an email from us with instructions on how to upgrade. We highly recommend you test building your site locally with kramdown prior to pushing. If you're a GitHub Enterprise user, this change will affect GitHub Enterprise versions 2.7 and later.

In most cases, upgrading to kramdown should be a matter of updating your site's configuration. If in the off chance you do run into any trouble, please get in touch with us, or if you have questions about what this change means for your GitHub Enterprise appliance, please contact GitHub Enterprise support. We're here to help.

GitHub Shop: water bottles are here

Stay hydrated while sharing your love for GitHub with the new water bottle. Available in the GitHub Shop

Water Bottle

Meet Richard Davey, creator of Phaser

To highlight the people behind projects we admire, we bring you the GitHub Developer Profile blog series.

Richard Davey

Meet Richard Davey, the game developer behind Phaser — a free open source HTML5 game framework used by developers from indies and multi-national digital agencies to schools and universities. A 34-year veteran dev, Richard built Phaser using Pixi.js for WebGL and Canvas rendering across desktop and mobile web browsers. The project is maintained by an enthusiastic open source community as well as Photon Storm Limited, a collaboration that has made Phaser one of the most starred game frameworks on GitHub. A pure gamer at heart, Richard is building tools that make it possible for thousands of people to turn their ideas into reality. We asked him to share the story of how he became a developer, and what he’s learned from his work.

Lee: Who inspired you when you were learning to program?

Richard: I looked up to those who were part of the demoscene. This counterculture took pride in pushing those humble little machines to their absolute limits. They would try crazy new hardware tricks and make them do things even the original chip designers never thought possible. Of course, most of the people in the scene were quite young, too, and this was reflected in their creations. Entire new art forms and styles of music emerged from those days, and it's still going on now.

Although there were many one-person game studios back then, typically their games would still be released by publishers. It was hard to recognise individual developers to look up to. There were some notable exceptions of course, like Jeff Minter, the Oliver Twins, Andrew Braybrook and Raffaele Cecco, but generally you'd only know about them because they appeared in magazines, often sharing coding tips.

Lee: The Oliver Twins were a huge inspiration for me - I also have them to thank for getting me into software development. How did you get into it originally?

Richard: Like lots of kids in the 1980s, my first taste of programming was on 8-bit home micros such as the MSX and ZX Spectrum. I spent countless hours pouring over type-in listings from computer magazines, tweaking things here and there to see what effect it would have on the game. Because those early machines were cassette-tape based, I often wouldn't even try to save my work. Or, it would get corrupted during the recording process. I'd literally type the code in, play with it until I got bored, and then turn it all off.

Moon Mission code listing Example listing from the December 1983 edition of Computer and Video Games magazine.

One day I went to a friend’s house after school and he had a brand new Atari ST plugged into the living room TV. He fired-up a copy of the game Bubble Bobble, and that was it. I was utterly blown away. My poor parents didn't hear the end of it, and I finally managed to get an Atari ST of my own. It was on this that I started doing game art and development properly (and yes, I would actually save my work now!).

As I was growing up and developing as a person, the Atari ST was providing me with an outlet for my creativity. It poured a constant stream of new game and art influences into me. I managed to find one of my early games a few years back and recorded a video of it, and of course I cringe when looking at it now. When compared to some of the games my own son is making today, they are miles apart in what's possible technically, but that same passion and desire to just create something is still there. Kids these days are no different in that respect.

Lee: The Phaser website is an amazing resource for people learning how to build games. What resources did you have available when you first got into web / game development?

Richard: When I first started coding all I had were books and magazines. Magazines back then were a treasure trove of information, often containing many pages of code to learn from. Tutorials, hardware experiments, and really in-depth technical pieces were common. There were loads of books as well. Of course, the front covers of these books never quite did represent what you'd finally create, but they served the purpose of drawing you in.

Lee: Have you seen the Internet Archive’s Computer Magazine Archives? All of our old favorites are there!

Richard: Let’s just say that accessing these materials is not a problem for me. Photo of my office wall shown below...

Richard Davey's computer magazine collection Richard Davey's computer magazine collection.

Learning web development was very different though. I started out building websites while still at University, when the most common web browser was the fully text-based Lynx, and Netscape Navigator was still in public beta. I remember it being a quite monumental day when we compiled a new build that was capable of displaying jpeg images in-page! I was now learning electronically. Knowledge would come from various sources: from IRC chat rooms, to Usenet postings, to just ripping apart the code in another web page and figuring it out. The difference was stark, though. There was no waiting for a new magazine to be published, or taking a trip to the library. You could nearly always find the answer right there online. This is definitely a change for the better.

Lee: Is there something you wish more people understood about software developers?

Richard: We're humans, just like everyone else. And humans make mistakes. Hindsight is a wonderful thing in life in general, but even more so in software development. Your first pass at solving a problem may not always be the best, but that's the beauty of software: most of the time you can go back and change it for the better. Without wanting to sound like a blatant plug, tools like GitHub have democratized distributed software development, and I honestly couldn't imagine working without them now.

Having said that, it has of course given rise to the 'entitled': those who don't appreciate that we're nearly all doing this for free, in our spare time. And because we're human, we react accordingly if you open a GitHub issue with a particularly negative tone to it. You have every right to point out flaws in my code. And if done with respect, I'll treat your feedback with respect, too.

In short: If you want something done, don't be an ass about it.

Lee: What advice would you give someone just getting into game development?

Don't give up. While there are many more learning materials and resources than ever before, there are also many more distractions, too. If what you're working on just doesn't do it for you, then ditch it and move onto something else. Unless it's a client project, of course :) Keep yourself motivated by working on things that interest you, sharing what you're doing with others, and soliciting their feedback and help when needed.

Also don't be tempted by the grass-is-always-greener mentality. I've seen it time and time again: someone assumes that if they move over to "Tool X" instead, they'll become instantly more productive as a result. This is rarely true. If you're struggling to complete something the issue seldom has anything to do with how it's being built, and nearly always to do with things impacting and pulling on the person trying to make it.

Lee: Hubot tells us the first Phaser code was committed in 2013. What were your initial aspirations for the project? Did you draw on any inspiration or incorporate lessons learned from Flixel or your Flixel Power Tools project?

Richard: Back in 2013 I was stuck in a large, complex project. When you're in deep like this, sometimes you need some small wins to rekindle your love for development. So I literally spent a weekend while the family was away hacking together a crude conversion of Flixel. For those not familiar with Flixel, it was a popular Flash game framework. I literally copied it wholesale, having to rebuild classes that existed in AS3 and porting the others.

A couple of days later I was done. It was small, clean, and just worked because it only tried to do a few things, so it did them pretty well. I wanted to release it on GitHub. I asked Adam Saltsman, the creator of Flixel, if I could call it Flixel5 but he said he'd rather I didn't as it would confuse things with the Flash build. So, I spent an hour brainstorming some names with my good friend Ilija and we settled on Phaser. He drew a cool little spaceman sprite and logo and the first build was pushed to GitHub on April 12th 2013.

Then an interesting thing happened: other people started using it. It started to take on a life of its own. A small-but-constant trickle of devs submitted pull requests and bug fixes. People actually started making games with it. And this does a curious thing when you've been working effectively in isolation for so long: it motivates you like nothing else possibly can.

Phaser was a weekend creation born from a pit of frustration that went mental and grew into what you see today, utterly unplanned, but utterly wonderful because of it.

Now, 3 years on, Phaser has evolved significantly. I believe you can clearly see a lot of my personal game development history and influences within it, and those of the wider HTML5 game developer community too.

Lee: Phaser relies on Pixi.js and Qici Engine relies on Phaser. What are some useful or cool open source projects you use, admire, or couldn't live without?

Richard: I love what Ricardo Cabello (Mr. Doob) is doing with three.js. We recently used three.js in a client project and it was great to work with. I like that he keeps pushing it in whatever direction he feels like, and not following the whims of the wider developer community.

I also admire Stefan Hedman’s work on p2.js, the physics engine that Phaser uses. Although development has dropped off massively on this since he joined Goo, it's still a fantastic library.

As you mentioned Phaser uses Pixi.js, and Mat Groves works tirelessly on improving that. V4 has just landed in beta tools. The rapid rate of iterations, from v1 to v4 in just a few years, is a bit of a challenge if you ever build a library around it :) But, at the same time, where else do you ever get the chance to experiment like this? Mat doesn't just change things for the sake of it. None of us do. We change things because we feel like we're making it measurably better in the process, and I admire him for constantly trying new approaches.

Lee: Talk to us about a subject we know is close to your heart, the future of game development. Where do you see it headed?

Richard: Honestly, I see it carrying on much as it has been for decades. New tools and frameworks will arrive from out of nowhere, and older ones will fade away if they stop being maintained.

For me, 2016 and beyond is all about taking advantage of the significant updates we're seeing in JavaScript. As a language it's really growing up fast. Even just a cursory glance at the new features that have already landed, or are coming soon, is enough to excite any longtime JavaScript developer. It's entirely possible to carry on in the old way, of course, and lots of people will. For me though, I see this as being a fundamental change in the way we'll be coding in the near future, so I am embracing it now rather than later.

The next generation of Phaser, called Lazer, is all about this. I covered the topic in depth in my article 'Phaser in 2015 and beyond'. You can read all about my reasoning, and the approach I'm taking, in that article.

Ever since I saw my first web page load into a text based terminal system all those years ago, the web has never failed to keep on innovating and exciting me. We're on the cusp of WebGL 2, Vulkan, VR in the browser, WebAssembly and loads more exciting tools to play with. Some will become standards, others will be sparks that die away quickly. But being a developer has always been about keeping a careful eye on those sparks, and knowing when to use them to light fires.

The fact that I can keep making tools that empower anyone to create games is what keeps my passion burning. In that respect I feel no different today, than the 10-year-old me who sat staring into the phosphorescent TV display, marveling at what possibilities it could unlock.

From the OctoTales video series: advancing cancer research through open source

There are no shortage of open source projects making an impact on our world, and we’ve been especially excited to see an increase in collaboration across the healthcare community. A few months ago we met a team at the Fred Hutchinson Cancer Research Center that is working to break down silos across cancer research by open sourcing their data and a tool called Oncoscape to visualize and interact with it. We thought the best way to introduce you to Oncoscape and the team behind it was through OctoTales, our video series about incredible companies using GitHub to work better together.

Meet Desert, Lisa, Jenny, and Eric, and discover what Oncoscape is all about.

"The project needs help at every level, from simple CSS improvements, to D3 refinements, to new interactive visualizations and extending all the way to novel challenging computational tasks, such as robust implementations of recently published computational biology algorithms", says our friend Paul Shannon, the founding architect of Oncoscape. "Cancer researchers at Fred Hutch and around the world will welcome your contribution!"

If you’re inspired to help the Oncoscape team advance their goals, you can find out more in the project repository. They have detailed contributing guidelines, issues labeled Help Wanted, and even a contributions cheat sheet.

If you would like to be a part of the OctoTales series, tell us your story at [email protected]

Supporting the student hacker community

To stimulate the growth and show our support of the student hacker community, we've partnered with Major League Hacking (MLH) to provide each new member hackathon with a $1,000 grant and one sponsored ticket to Hackcon, the conference for hackathon organizers.

GitHub <3 Students

Hackathons are amazing social gatherings where students interested in technology can come together to learn, build, and share brand new creations over the course of a weekend.

For a small, first-time hackathon, $1,000 can make or break the event budget. For organizers, having the opportunity to meet the people behind the most successful student hackathons at Hackcon is invaluable to the continued success of their events.

As the official student hackathon league, MLH provides member events with organizational support including mentorship, hardware labs, and connections to technology companies. Last week, they announced their seed funding and B-Corp certification to reaffirm their mission-driven focus on empowering student hackers. Together, GitHub and MLH have supported a community of 50,000 students at over 150 global events in the last year.

We're proud to be part of the rapidly growing movement of hackathons organized for students by students. GitHubbers regularly participate in student hackathons as mentors, guest speakers, and judges while the GitHub Student Developer Pack gives student hackers free access to the best developer tools to use for their hacks.

To organize a hackathon at your school with support from GitHub start an MLH member hackathon in the 2016-2017 season.

A look behind our decision to standardize on a single Markdown engine for GitHub Pages

Two months ago, we announced that GitHub Pages is dropping support for the RDiscount, Redcarpet, and RedCloth (Textile) markup engines on May 1st. For the vast majority of users, this should be an easy transition, as kramdown supports all of RDiscount and Redcarpet's most popular features, and if you're making the transition from Textile, @jldec's post last month should walk you through the process.

With the May 1st sunset quickly approaching, we wanted to take a few moments to take a look at the numbers and the discussion behind our decision to drop support for the non-kramdown markup engines within GitHub Pages:

Web publishing has come a long way since the Jekyll project began some eight years ago. Today, Markdown is largely the lingua franca of the open source community, but that doesn't mean that certain regional dialects haven't emerged over the years, as each markdown engine adopted a slightly different interpretation of how they thought Markdown should work. As Markdown engines diverged, so too did the experience of authoring content on GitHub Pages and authoring content elsewhere on GitHub.com such as in comments and READMEs.

One of our historic design philosophies at GitHub is that "anything added dilutes everything else". While being able to fine tune the pipeline that's used to render your content may be helpful in some unique cases, for the vast majority of users, that added complexity is one more thing that you'll have to learn, one more decision that you'll have to make, and ultimately that option serves to heighten the learning curve for new users.

Today, GitHub Pages is home to just over one million distinct sites, with thousands more being added each day. On an average day, we'll process upwards of 50,000 builds, and of those 50,000 builds, more than 40,000 either don't ask for a specific Markdown engine, or ask us to use kramdown, the default. That means that when we look at markup rendering across GitHub Pages, Redcarpet accounts for just shy of 2% of all builds, RDiscount accounts for about half a percent, and Textile accounts for one-tenth of one percent.

builds-by-deprecated-engine

In standardizing on a single Markdown engine, we are able to improve the publishing experience for the vast majority of GitHub Pages users. Not only are we able to remove the complexity and confusion associated with new users being forced to distinguish between multiple markup engines or reading documentation for the incorrect interpreter, we are able to bring the experience of authoring Markdown content on GitHub Pages more closely in line with the experience you've come to expect when using Markdown anywhere else on GitHub.

If you're still using RDiscount, Redcarpet, or RedCloth, next time you push to your GitHub Pages site, you will receive an email from us with instructions on how to upgrade. We highly recommend you test building your site with kramdown prior to the May 1st deadline. If you're a GitHub Enterprise user, this change will affect GitHub Enterprise versions 2.7 and later.

In most cases, upgrading to kramdown should be a matter of updating your site's configuration. If in the off chance you do run into any trouble, please get in touch with us, or if you have questions about what this change means for your GitHub Enterprise appliance, please contact GitHub Enterprise support. We're here to help.

Meet Sean Marcia, founder of Ruby for Good

To highlight the people behind projects we admire, we bring you the GitHub Developer Profile blog series.

Sean Marcia

If you know Sean Marcia, chances are that it’s through Ruby for Good, an annual event that brings Ruby developers together to work on projects that benefit their communities. But when he’s not empowering developers to use their skills for collective good, he’s partnering with academics at George Mason University to advance their research through software and the web. Oh, and saving the world’s pollinators, of course. We asked Sean to share the story of how he became a developer, and what he’s learned from his work.

Erin: How long have you been developing software?
Sean: Let’s see... It’s been my legit full-time career for about five years now. Like many nerdy types, I’ve been poking and prodding at computers since I was a wee one. Getting paid to do it is a relatively new and delightful thing!

Erin: What programming languages do you use?
Sean: I primarily use Ruby on Rails and Javascript for the projects I work on at George Mason University. I also sneak in Go whenever I am able.

Erin: Who did you look up to in your early days?
Sean: In my early days, full-stop, I definitely looked up to (and continue to look up to) Jim Henson and Mr. Rogers. These guys genuinely cared about people and their happiness. My favourite Jim Henson quote nicely sums up why I admire him so much and what I strive for everyday:

My hope still is to leave the world a bit better than when I got here.

In my early days of career software development, who did I look up to? Hmm, it’s tough to narrow it down to a short few. I definitely have to mention _Why, James Edward Gray II, Greg Brown, Jim Gay, and Evan Light. These folks were helpful (understatement), encouraging, smart, generous with their time and expertise, and just all-around great people; I hope I can offer back even half of what they’ve given me. Ruby fosters a culture of inclusion, kindness, and learning. It’s a community comprised of some of the best people I’ve ever met. As a newbie, I was privileged to be exposed to this great bunch, and now as a Ruby Meetup organizer I count myself lucky to see newcomers’ passion about development and their world.

Erin: Tell us about your journey into the world of software development.
Sean: Okay, brace yourself, best sit down for this one: I've always been a bit of a computer nerd with an affinity towards technology. No big shocker that this interest manifested itself in computer games. The first substantive programming I did was using a language called LPC for a multi-user-dungeon (MUD). That’s right, I wear my nerd badge proudly! For those who have no idea what I’m talking about, MUDs were the precursor to MMORPGs. Everything was text based, there were no snazzy graphics, and they only had a few hundred people playing at once (none of this thousands upon thousands business). It was great fun, as I was friends with a lot of the people who used the things I built and was able to directly observe their happiness and pains when they were interacting. Quite the dichotomy from today when some of the things I build disappear into the ether after delivery and I never see how it is used or what happens next.

Erin: What resources did you have available when you first got into software development?
Sean: Not a lot! I remember begging my parents to buy me Borland's C++ compiler but it was outside their budget so I was only able to read the code in the book but not compile and execute it myself.

Erin: What advice you would give someone just getting into software development?
Sean: I would tell them to get involved in the community! I have learned and benefitted so much from having access to people at meetups, conferences, and other events. I wouldn't be where I am today without the help. I would also let everyone know that you don’t need a computer science degree to get into software development. We live in an amazing world where information is so widely available that you can learn anything you want with a few clicks. It is fantastic that schools like MIT, Stanford, and others have open sourced so many courses. If you have access to an Internet connection you can access courses taught by some of the smartest people in the world. This isn’t to say that software development isn’t hard! Don’t get discouraged. Don’t give up.

Erin: What additional advice would you give someone looking to get into open source?
Sean: I would tell them to not be afraid! Everyone I've met who works on or maintains an open source project is super nice and generally pretty overworked. They are friendly, welcoming to new people, and love the help! An easy way to get started with an open source project is to help with documentation. I think most people would be surprised with how much help even well-established projects need in that area. If you are new to development and are using and learning an open-source project, document your learning, and submit it to the project’s GitHub wiki as a newbie's guide to help others.

Erin: I was inspired (and entertained!) by your talk on saving the bees with Ruby and was amazed at how much you did with so little. What advice would you give to someone with a big, impactful idea, but a small budget?
Sean: Not to sound like a broken record, but get involved with your community! I couldn't have done everything I did without the help of my community. For the project you mentioned, several people donated a Raspberry Pi that would have otherwise been collecting dust on a shelf. Plus, a friend did all the soldering for me and was nice enough to allow me to record him so others could replicate it. And, the wealth of knowledge and feedback that so many people provided made it a success. A lot of people are happy and want to help, you just need to ask!

Erin: Are there any misconceptions out there about software developers that you think need to be retired?
Sean: I think the biggest misconception is that you need a computer science degree to be a software developer. This is an archaic notion as there are so many paths into the software development field, from boot camps to those who are self-taught. One of the best developers I know, who has published several popular books on software development, has a fine arts degree in ceramics. I firmly believe that excellent mentorship, bootcamps, and community events are producing better software developers than universities.

Erin: What role did MINASWAN play in inspiring you to start Ruby for Good? Can you share with us an example or two of how you’ve personally experienced MINASWAN (or perhaps seen others experience it)?
Sean: MINASWAN played a huge part. Outside of the technology industry many people are struggling and I believe that because we have it so good in tech it is easy to lose sight of that. The genesis of Ruby for Good was to provide a way to help and make a difference for the people who need it most. There are everyday MINASWAN heroes in this community and one person I'd particularly like to shine some light on is Zander Hill and the amazing work he does mentoring. Getting into software development can be intimidating and overwhelming, but I've seen Zander take the most difficult concepts and make sense of them for his mentees.

Erin: Okay, we’ve talked a little bit about Ruby for Good, a conference that gets Ruby developers together to hack on projects that make an impact on the world outside of tech. What are some of your favorite projects that have been helped by the conference attendees?
Sean: I think my favorite project was a ticket-tracking app we built. Before we helped them through Ruby for Good, the nonprofit was using a telephone line and its voicemail as their project management tool. The telephone line would ring continuously throughout the day. People would check messages with the rule that you could only delete a message once the task was completed. This required people to forward through as many as 80 messages before getting to the one they needed and they estimated that each employee who used it wasted at least five to six hours a week on the phone. The new system has made their lives much better and given them more time to devote to the great work they are doing. I'm also pretty excited about the help we provided the Fairfax Humane Society because it doesn't get much better than helping puppies and kittens! This year, Ruby for Good is going to be held June 16-19 where we will be helping some truly amazing organizations, including researchers who are working with red pandas. I'd encourage anyone who wants to do good and hang out with red pandas to attend!

Erin: Where would you point someone who wants to get involved, but can’t attend the conference?
Sean: If someone wants to specifically get involved with Ruby for Good, check out the projects with open issues on our GitHub organization page and submit a pull request! I would also encourage people to look closer to home. Stop by a local non-profit that appeals to them and offer to help. One ubiquitous issue among non-profits that we've spoken to is how starved they are for help with technology. Nonprofits desperately need the help that we can offer, but for most part it is completely outside of their budget. Through our volunteer work, they can get new ways of doing things that they might have done the same way for the past 20 or 30 years.

Erin: Anything else you’d like to share?
Sean: I've had a great deal of fun whenever I've been able to use Go and would love to do something more substantial with it. I'd love it if anyone could make some suggestions :).

Git 2.8 has been released

The open source Git project has just released Git 2.8.0, featuring a variety of features, bugfixes, and other improvements from over 70 contributors. Here are some of the most useful new features:

Parallel fetches of submodules

Using "git submodules", one Git repository can include other Git repositories as subdirectories1. This can be a useful way to include libraries or other external dependencies into your main project. The top-level repository specifies which submodules it wants to include, and which version of each submodule.

When you fetch into the top-level repository, you typically want to fetch into the submodule repositories as well:

git fetch --recurse-submodules

If you have a lot of submodules, all of these fetches can be time-consuming; git fetch is essentially run in each submodule in turn. But now you can speed things up by fetching from multiple submodules in parallel. For example,

git fetch --recurse-submodules --jobs=4

runs four submodule fetches at the same time. This should be a real time saver! [source]

Don't guess my identity!

If you use the same name and email address to commit to all of your Git projects, then you can configure those values once and for all in your global .gitconfig file:

git config --global user.name 'Me Myself'
git config --global user.email [email protected]

But if, say, you want Git to use one email address for your open source projects and a different one for your work projects, you've undoubtedly made the mistake of committing to a new Git repository without having first set your email address in that repository. In this situation, Git emits a warning, but it creates the commit anyway, using an email address that it guesses from the local system hostname. If you're trying to do something as complicated as different addresses for different projects, this is almost certainly not what you want.

Now you can tell Git not to guess, but rather to insist that you set user.name and user.email explicitly before it will let you commit:

git config --global user.useconfigonly true

[source]

Convergence with Git for Windows

There has recently been a big push to make Git feel as comfortable on Windows as it does on Linux and OS X. For example, it is relatively expensive to start processes on Windows, so many Git commands that were originally written as scripts have been rewritten in C to make them snappier.

In this release, a bunch of Windows-specific changes have been brought back from the Git for Windows project into the main Git project. This continuing effort will make it easier to keep the functionality of Git in sync across platforms as new features are added. [source, source, source, source]

Along the same lines, several Git commands that use text files as input have been made to accept both LF and CRLF line endings. That should reduce friction on Windows, where many tools may produce files with CRLF line endings. [source]

Security fixes

Git 2.8.0 includes the security fixes for CVE-2016-2324 that were first made available in Git 2.7.4. This vulnerability is not known to have any exploits in the wild, but could result in executing arbitrary code when cloning a malicious repository. We recommend that everybody upgrade to a version of Git with these fixes, namely 2.4.11+, 2.5.5+, 2.6.6+, 2.7.4+, or of course 2.8.0+.

In addition to these fixes, this release contains a number of cleanups designed to make it easier to avoid similar bugs in the future.

[source]

Brief mentions

  • Git's clean and smudge filters can now be turned off by setting them to the empty string. This feature is notable mainly because it is used by the new git lfs clone command, which can dramatically reduce the time to clone a repository that uses Git LFS. [source]

  • Git configuration values are read from several different places, including system-level, user-level, and repository-specific files. This can make it hard to figure out where a setting has to be changed. Now you can use git config --show-origin to show where a particular setting came from:

    $ git config --show-origin user.name
    file:/home/me/.gitconfig    Me Myself

    [source]

  • You can use the new git ls-files --eol FILENAME to help diagnose end-of-line problems in a file:

    $ git ls-files --eol README.md screenshot.png
    i/lf    w/lf    attr/                   README.md
    i/-text w/-text attr/                   screenshot.png

    The output shows (i) the EOL style auto-detected from the file's contents in the index, (w) the EOL style detected from file's contents in the working copy, and (attr) the style that is configured for the file via gitattributes. [source]

  • git ls-remote can now also tell you a remote repository's default branch:

    $ git ls-remote --symref origin HEAD
    ref: refs/heads/master  HEAD
    db6696f653b917509dac1ac13b922e12773a84ff        HEAD

    [source]

  • Support for cloning via the rsync protocol, which was superseded long ago by better alternatives, has been dropped. [source]

The rest of the iceberg

That's just a sampling of the changes in Git 2.8.0. Check out the the full release notes for the complete list.


[1] Git submodules are analogous to Subversion's svn:externals.

Atom reaches one million active users

We have reached an exciting milestone: one million people have launched some version of Atom in the last month. That's three times the number of active users we had under a year ago at the one-year anniversary of Atom becoming completely open-source.

Graph of active users over Atom's history

Atom has been successful because of the community that has grown around it. The people that have contributed to Atom—that have given their time, expertise, feedback, suggestions, and insight—have helped Atom improve by leaps and bounds. We also hear of exciting or just plain cool things that people are doing with Atom all of the time—like MuleSoft's API Workbench, Jibo Robot's SDK tools, and Facebook's Nuclide.

It's not just companies that are coming up with interesting ways to use Atom. Some packages written by individuals that have caught our attention recently are:

  • Atomic Chrome - Syncs what you type in Atom to text inputs on web pages in Chrome so you never have to worry about losing what you wrote
  • Git Time Machine - Shows an interactive plot of the current file's Git commit history
  • Activate Power Mode - A fun package that infuses your typing with :boom:power:boom:

All of us on the Atom team appreciate the work that the community has put in to our collaborative project. We're looking forward to what Atom will look like when we reach the next million users and hope that you are, too!

Introducing the GitHub Community Cast

At the heart of what makes GitHub great are the thousands of open source communities that build incredible things every day. The brand new GitHub Community Cast shines a light on these awesome projects and the people that make them.

Take a look inside a project, learn about their tools and workflow, discover where you can get involved, and get inspired for your own work. In addition to seeing behind the curtain on a great open source project, you'll also get news and updates from around the GitHub community.

The inaugural episode features an interview with Andy Miller from the Grav project, a modern flat-file CMS with some bold ideas. We also share some of the new features recently landed in GitHub and events going on around the GitHub community.

podcast

You can each episode from our SoundCloud page or subscribe to the podcast feed.

Creating a new contributor on-ramp

One of the most important elements of creating a strong community is shaping the new contributor experience. The on-boarding experience for new participants plays a huge role in how quickly someone can get up and running on your project. The most successful projects make this experience simple and accessible.

Getting someone started with their first contribution in a community typically follows a linear path, from discovery through appreciation. The environmental factors surrounding your project play the largest role in making that experience comfortable, empowering, and worthwhile.

The new contributor on-ramp

The on-ramp is a framework for growing your community. From getting your project noticed through celebrating a new contributor, building out each area will help your community thrive.

New Developer On-Ramp

At the beginning is a user that hasn't yet discovered your community. And at the end is a user that has made their first contribution to your project. Along their journey, the user usually goes through six steps of progress:

  1. Discover that the community exists and welcomes contributions from new members.
  2. Setup tools needed to build the project and create a contribution (e.g. editors, compilers, libraries, frameworks).
  3. Learn skills and knowledge to understand the codebase, contribution guidelines, and understand how their contribution will be reviewed.
  4. Identify tasks to work on, or know what kind of contributions would be welcome and worthwhile.
  5. Get help with the questions, queries, and sticking points they may have with their first contribution.
  6. Feel appreciated when they have successfully made their first contribution and at other key moments to know that the community is kind, supportive, and welcoming!

Within each of the six steps, there are many different things you could implement. This series will take a look at each step in turn, and for the rest of this post we'll delve into what you can do to help your project be discovered.

Discover

"If you build it, they will come" only works for Kevin Costner and baseball fields. For your project, the first step in building a community is making your project discoverable.

There are three goals for the discover step in the on-ramp:

  1. Welcome and inform new visitors about the community
  2. Establish your project as inclusive and welcoming of new contributors
  3. Show people how they can begin to contribute to the community

There are plenty of options on how to achieve these goals, below are a few of the basics that every community can use.

Create a README.md file

Whenever you visit a GitHub repo, the contents of the README file is displayed underneath the file listing. It is a great opportunity to give a quick overview, including:

  • What your project is and what it does
  • How to build and run the project
  • Ask for new contributors
  • Provide details on how to get started, such as a CONTRIBUTING.md file

By using Markdown you'll be able to format the README for easier viewing and link to resources for new contributors. Plus it'll look great!

Create a project website

While a README.md is a good start, many projects can benefit from a comprehensive website. A full site gives the project a home for things like extensive guides, tutorials, and blogs.

Build the site from the perspective of a new user to your project:

  • Highlight the features of the project (with screenshots, if applicable)
  • How to install it
  • How to use it
  • Where to get in touch with the community
  • How to get involved in the community

The front page should have the most important information, like what the project does, how to get it, and how new contributors can join. Check out Bootstrap, Jekyll, or Electron for some ideas for your project site.

A fast way to get started with this is with GitHub Pages, which provides free hosting for a project website. When you create this site it will be publicly hosted at http://<yourproject>.github.io.

Engage on social media

Social media is a powerful tool for raising awareness about your project. Many people will follow the social media accounts of projects to keep up-to-date on news and announcements, it is also a great place to engage new contributors. Though tread lightly at first as social media can be time-consuming to maintain.

Twitter and Facebook are the best places to start. After registering the accounts, take some time to spruce up the profiles. Match the account design to your project website, and link back to it.

You can grow your community on social media by providing valuable and interesting content. Images and video are great additions to social posts. Be careful not to over-saturate your audience with too much content though. You should stick to:

  • Links to blog posts with updates, news, and other material
  • Videos with demos, screenshots of new features, and other visual content
  • Invitations for users to participate in issues, surveys, or other ways of getting engaged
  • News about growth of the project, partnerships with companies/organizations, and interesting use cases

A useful tool to simplify social media is Buffer. You can prepare your posts and content ahead of time, and it'll publish it on a schedule. By dedicating time to your social media strategy, you can free up your time for the week ahead.

Promote the community

There are many other ways to get the word out and highlight the work happening in your community. A few places you can start:

  • Organize Google Hangouts on Air to host an interactive show that gets the community involved. A bi-monthly show could be used to demonstrate new features, answer questions, or feature a new contributor.
  • Do interviews on podcasts, news website, and blogs to talk about the vision of the project and get people involved. It is often as simple as asking the site or podcast if they'd be interested in featuring your project.
  • Speak at conferences to show the great work going on in the project and provide simple steps for how people can get involved.

The new contributor on-ramp is a valuable framework to make the new user experience simple, empowering, and effective. These basic building blocks will setup your project to have a healthy and thriving community of contributors. We'll dive into the Setup Tools and Learn Skills steps in the next installment of the series.

Udacity joins the Student Developer Pack

Student Developer Pack + Udacity

Following up on the release of the Ruby Nanodegree program that we co-created with Udacity, we've extended our partnership to offer GitHub Student Developer Pack members one month of free access to any Nanodegree program. Pack members can choose from Android Developer, Front-End Web Developer, Data Analyst, or any of the 12 Nanodegree programs offered by Udacity.

In a Nanodegree program, you will:

  • Learn at your own pace from industry experts at Google, Facebook, and GitHub
  • Get access to coaches who provide you with personalized guidance, accountability, and code review
  • Create a portfolio of work to showcase your skills
  • Receive career support to help with your job search, and a guaranteed job when you sign up for Nanodegree Plus

The Student Developer Pack gives students free access to the best developer tools from 15 different technology companies like Stripe, Travis CI, and Unreal Engine. Now, with Udacity included in the pack, it's even easier for students to get started learning to program with professional tools.

Students, get your pack.

Kindly Closing Pull Requests

Getting your first pull request from an outside contributor on GitHub is an exciting experience. Someone cared enough about the problem you were solving to check it out themselves, change something, and contribute that change back to your project. When your project has a relatively small number of high-quality, desirable incoming pull requests it is easy to happily merge them.

Where things can become more difficult is when your project becomes more notable and the quality, desirability, or number of pull requests you receive causes difficulties. Now the positive feeling you had about the time people spent can be reversed; you don't want to reject someone's work when they have already spent the time to get it included.

Let's discuss some common types of pull requests that can be closed and how to do so in a way that encourages positive behavior in your community (rather than discouraging participation).

Close pull requests you will never accept

Sometimes outside contributors will submit pull requests for changes that you don't want to make to your project. For example, they may submit a feature you consider to be out-of-scope for your project. In this case the best option is to politely explain to users that, although you value their contribution, you are unwilling to accept it and close their pull request. Ideally, also explain to them and in a CONTRIBUTING.md file how they can get a better indication in the future on what would or would not be accepted before they begin the work. The github/git-lfs project's CONTRIBUTING.md file provides a good explanation of what features might be accepted.

Close pull requests you cannot accept

Hopefully you have continuous integration set up for your project to test pull requests before they are merged. In some cases, outside contributors may submit a change that breaks continuous integration tests and they may be unable or unwilling to make the changes required for the pull request to be merged. Another situation that can occur is that you request changes be made but the contributor never responds. In this case, it's better to close the pull request after a fair amount of time with no response or fix (e.g. a couple of weeks) and note this policy in a CONTRIBUTING.md file (e.g. that merging a pull request requires passing tests). This does not need to be permanent; the contributor can always make more changes and submit another pull request in future.

Close pull requests on unmaintained projects

You may have created a project to solve a particular problem that you no longer have and open-sourced it just to share it with the community. In this case, consider documenting it in the README that you will not be accepting pull requests and close any that are submitted. Hopefully the clarification of project status in the README means the project will not receive any pull requests. If this is decided when you already have open pull requests: politely close them and explain why.

If your community has enough interest in maintaining the project they may fork it and decide to manage contributions there. A great final thing you can do with your project is to point people to the new project in the README and "bless" it as the new version of your project.

Close pull requests that turn sour

Discussions on pull requests can sometimes deviate from the original intent of the pull request and may even become unpleasant. In those cases, prioritize care for yourself and your community by closing (and optionally locking) pull requests. The original intent can be dealt with in another pull request.


For every pull request it's important to consider the users and maintainers of your project and ask yourself, "would merging this pull request make the project better or worse for them?". If you cannot answer "better" to this question: spend the time to help the outside contributor alter the pull request or submit another pull request for something you would be able to merge. Do not merge pull requests out of guilt for how much work the submitter has put in; you will only regret doing so in the long-term.

Although it's never nice to reject someone's work it's preferable to leaving pull requests open that you will never merge. Those pull requests will just hang over you and the contributor indefinitely. One of the indicators of a healthy project is its responsiveness to contributions, whether it is giving feedback, merging, or closing pull requests.

This post explains some of the reasons why you might want to close pull requests on your project and how to do so. We hope this helps project maintainers and contributors use pull requests to build software more effectively.

Something went wrong with that request. Please try again.