I think this is a great step, for several reasons -- both corporate and user-facing.
(1) It is true that this is more likely to turn GitHub into a generic file-dump place similar to DropBox. GitHub's infrastructure is sufficiently good to handle this, and this new addition is unlikely to disrupt the workflow of veteran users. However, since it is likely that some companies will use GitHub for file dumping, GitHub will be justified in charging companies a fee for particularly large repositories -- capitalizing on the file-dumping. I sense an alternate revenue stream coming in for GitHub.
(2) I've often run into situations in which I had written a small script and wanted to quickly turn that into a GitHub repo. To do so, I'd have to go through the online interface to initialize a new repo, and then make a folder on the command line, type a few commands, etc. Though it's a very short process, I couldn't understand why I couldn't just use the online interface to type up a readme and then drag-and-drop my script into the repo. The update smooths this work experience.
(3) Obviously, it'll make GitHub far more accessible to less technical users -- some users are intimidated by the Git learning curve, and this update makes them much more likely to use GitHub (and then slowly learn the ropes of using it via the command line).
(4) By inviting more non-technical users as in (3), it becomes more likely that (1) succeeds.
With regards to (1), being a file-dump place: it's worth noting that GitHub currently imposes soft (50MB) and hard (100MB) size limits per single file[1]. If you try to push a file that exceeds either of these limits from the command line, you'll receive a response from the remote server pointing you in the direction of their Large File Storage (LFS) service[2], which they charge for beyond the free 1GB storage/bandwidth per month.
Out of curiosity, I just tried uploading a file larger than 100MB to test the limits via the browser and received the following error:
Yowza, that’s a big file. Try again with a file smaller than 25MB.
For me, this significantly limits its feasibility as an alternative to Dropbox.
This is probably as a DoS protection; accepting large responses have always been a vector. They could work around this by having some additional logic fire beforehand to prevent it becoming an attack vector.
> (3) Obviously, it'll make GitHub far more accessible to less technical users
I'd have to imagine this is probably the main driving factor. As GitHub tries to make further inroad into Enterprise, I can see them focusing more and more on making things more accessible to non programmers (project managers, secretaries, etc.)
I really won't be surprised if 5 or 6 iterations down the road, you'll have the option to change the repo landing page. For example, instead of showing the files in a repo, you'll just see the README markdown file. And before you know it, they (GitHub) will start marketing GitHub Enterprise as a competitor to Confluence and other wiki/document management system.
The "repo landing page" is already handled, somewhat, by GitHub Pages—the idiomatic repo setup is to have a GitHub Pages site "about" your software, linked from the description field of the repo; to link Release downloads directly from the GitHub Pages site, bypassing the repo; and to link to the repo from the GitHub Pages site under a "view source" or "contribute" Call-to-Action. The repo itself, with its README.md, then serves just to document the implementation—setup, usage, release notes, etc.—rather than to describe, explain, or teach you how to use the software.
Speaking of GitHub Pages, this feature complements it perfectly. Now you can create a GitHub-powered website—including images et al—without touching git, in much the same way you'd use one of those "FTP web interface" panels on a VPS. Except that each upload becomes a commit, rather than just mutating some ephemeral folder somewhere.
The current landing page format has long been an annoying thorn. Only having a one line summary and URL "above the fold" is a terrible UX for people just arriving at a new repo. I wish they'd add a reactive layout for widescreen displays that shows the README and dev info side by side.
With a gist you're able to quickly and easily upload a single file script (or multiple files).
Also once created you can clone it as a git repo and make updates and push back to it (e.g. add files etc). Also people can fork your gist just like git repos.
I like this approach rather than creating a "new repository" on github for small scripts or snippets because then your github profile doesn't get cluttered with small snippets and script repos and is reserved for actual "project" repos.
I think sort of the implication here is he's just coded up something that may be a starting point for something that will later involve more files - just makes it easy to do the initial repo setup.
[Hub](https://hub.github.com/) is a great little tool for simplifying (2). Initialize a local repo with `git init`, make an initial commit, and `hub create` sends it to GitHub and creates the repo for you.
Right, because Dropbox is so hot right now as a company and a business. Meanwhile, Atlassian's IPO went very well. Even though I hate JIRA I understand why many people need it. GitHub offers nothing on the project management layer and turning GitHub into generic file-dump is a good way to kill the company. GitHub needs to offer project management on top of git, not silly WYSIWYG features.
(1) It is true that this is more likely to turn GitHub into a generic file-dump place similar to DropBox. GitHub's infrastructure is sufficiently good to handle this, and this new addition is unlikely to disrupt the workflow of veteran users. However, since it is likely that some companies will use GitHub for file dumping, GitHub will be justified in charging companies a fee for particularly large repositories -- capitalizing on the file-dumping. I sense an alternate revenue stream coming in for GitHub.
(2) I've often run into situations in which I had written a small script and wanted to quickly turn that into a GitHub repo. To do so, I'd have to go through the online interface to initialize a new repo, and then make a folder on the command line, type a few commands, etc. Though it's a very short process, I couldn't understand why I couldn't just use the online interface to type up a readme and then drag-and-drop my script into the repo. The update smooths this work experience.
(3) Obviously, it'll make GitHub far more accessible to less technical users -- some users are intimidated by the Git learning curve, and this update makes them much more likely to use GitHub (and then slowly learn the ropes of using it via the command line).
(4) By inviting more non-technical users as in (3), it becomes more likely that (1) succeeds.