I think depending upon a single, proprietary web service for everything is foolish. When Github is down, you're out of luck. If Github changes in a way you don't like, you're out of luck.
Jokes aside, using any proprietary web service has the exact same downside. And yet here we all are using Google Apps, Dropbox, GitHub, HipChat, Intercom, and dozens of others. As a team, we found additional web services add exponentially increasing complexity; we eventually needed a platform to keep track of all the platforms we were using. So we back-tracked and went the same route as the Wiredcraft guys, centralizing everything into GitHub.
As a community, instead of advocating turning the clock back (which will never happen: the toothpaste has exited the tube), we should explore ways to satisfy security & reliability concerns while maintaining convenience. Also, you can self-host GitHub.
Erm, I think you're the one who's new here. Proprietary Web services and walled gardens are a recent thing. FTP, email, HTTP, etc. are all open systems.
Of course some companies did try to flog proprietary services and protocols decades ago too, but the users were clued up enough to avoid them and let them die.
Yes, you are correct that using any proprietary web service has the same downsides, which is why I have taken it upon myself to avoid as many of them as possible and support free, decentralized alternatives.
I do use github to host my source code currently, but it would be trivial for me to move to a free service such as gitorious, or a gitlab instance, or my own server running cgit or gitweb.
What do you mean you can self-host GitHub? GitHub is not free software.
Using free software has its downsides as well. Like, bugs all over the place that require you to dig into the source code even just to understand what went wrong. Also, glacier-slow updates, since everyone has a day job.
How many times have you had a game-breaking bug? Why are a good amount of folks still on .NET then? That last point is just hollow. Freedom from what? Oppression?
In an actively maintained project, that bug could be fixed in a day (or at least within the week). In an actively maintained proprietary game, it could go out in a patch pretty quickly. In an abandoned proprietary game, the bug will never be patched. In an abandoned open source game, there's at least a chance you might be able to fix the bug yourself.
And that's one part of the freedom. Open source software will live as long as people are interested in it, while proprietary software dies very definitively.
I agree with what you are saying, but as far as reliability goes github sucks badly and until it gets much much more reliable I think using it for "everything" isn't really viable for most businesses (unless they have enterprise). I might not have any more redundancy with Google Apps, but I am yet to be affected by an outage.
Exactly. The entire reason Git was created is because a proprietary version control platform (BitKeeper) was given too much trust and power over Free Software projects, which it inevitably abused.
The whole point of Git is that you don't have to surrender control. GitHub is just another BitKeeper. If you really want a Web interface there's Gitorious (which has been around longer than GitHub) and GitLab.
The number of Git-backed Wikis, bug trackers, filesystems, etc. is huge too, judging by the New Packages I see in aptitude every few weeks.
Hey, i'm the creator of RhodeCode, we're still open source, the whole core is still GPLv3. It's stated in our header of the enterprise release: https://rhodecode.com/enterprise.
I dont think diversification would do much better. Most big github features are probably handled by separate teams and function somewhat independent of each other as well. But downtime could be a big issue although Github has been generally good at it (https://status.github.com/graphs/past_month) People also rely on github git repos for deployment (e.g. in requirements.txt) so their work would likely survive standard levels of downtime.
GitHub offers and enterprise offering that you can host yourself. It's no better/worse than hosting your own version of JIRA, Confluence, and a git repository. That way you're not 100% dependent on github.com actually being up. As far as changes, you're right, but the changes are true with any product. At my last company, we did a JIRA upgrade which ended up being a nightmare for process because lots of things changed and were configured incorrectly. I guess I'm trying to say that what you're saying is true for any SaaS product you use and doesn't take away from trying to use GitHub, maybe not necessarily github.com, to run everything.
This isn't what I thought it would be. I think "Github for everything" is something everyone should be looking for in their lives. Version control is useful for so many things.
I think the understand this already though. With the release of stuff like 3d diffs now it's the "GitHub of CAD", I could imagine a useful future for the "GitHub of legal documents", "GitHub of _____"....
While I appreciate the sentiment that version control is very useful, I'm loathe to put all of my data in the hands of a US based company again. Went down that road once with Google. Never again. I think "Git for everything" should be the mantra, but I realize the unix philosophy behind git probably makes that unlikely.
I think it would be cool to set up a 'github' 'p2p protocol' where if you sign up with one server you can access projects from any other server following the protocol. For example, I run my own 'github' instance just for me on my personal server. A company can host an instance on their servers and, if they implement the protocol, I can use my instance to submit a pull request on a repository they host. Complete interoperability.
Very good to know, thanks. But I did say 'github' and not 'git'. A lot of the important parts of what makes github so nice to use aren't supported in the standard git protocols. Issue tracking (which icebraining mentioned), search/browse/other discoverable features and the social elements, to name a few.
Bugs Everywhere was an attempt at storing issues and bugs inside the git repository itself. Maintenance activity has been on a down slope for Bugs Everywhere, though..
Wow, that's an awesome idea. I'd love to try and bring it back to life, but I know absolutely nothing about p2p protocols or the inner workings of git.
For example, I run my own 'github' instance just for me on my personal server. A company can host an instance on their servers and, if they implement the protocol, I can use my instance to submit a pull request on a repository they host.
Yeah, and that'd be really nice since you could see all the issues you submitted to different repositories/companies in a single view, which should receive updates from the remote tracker.
Protip: In almost no circumstances is it a good idea to make comments about someone's spouse. Much less on a professional forum, and certainly not on HN. Regardless of the intent, the potential for misunderstandings, over reactions, and incorrect inferences is great, meanwhile such comments almost never add any meaning to the discussion.
Yeh. I guess usually when I'm on HN I just respond to people as if they're real, have a brain and not intentionally trying to stir shit up. In this case I didn't even notice the name.
Alas, perhaps times have changed around here and I need to start treating people like redditors until proven innocent ;-)
Idea: Github should allow "plugin repositories" that can be shared or private.
The first iteration would have some way to provide file type viewers. A file under filetype/viewer.js.js would replace github's default JavaScript viewer (itself simply published as a repository that just happens to be the top node). You could start your own customizations by forking that repository. If you develop a viewer/editor/future plugin component that you think the world should use, send it in as a pull request to the canonical repo.
The other thing I think github should do is go the JetBrains Upstream / Google Grok (if it ever happens) route and provide syntactic / semantic analysis as a service, from which all these visualizers, editors, and other tools are built.
It great, but I concern about exporting data out from GitHub for whatever a reason. Is there a backup anything or we just have to dig data out from API?
Issues are disposable data, it has an expiration date. Once you closed an issue, there's little value in it. Most of the valuable data ends up in the Wiki (or in code), and Wikis are actually Git repositories. You can't make it easier to backup.
Although it's nice that everything is in one place I don't think Github would be my first choice. It's made primarily for managing code and everything surrounding that. I do think the issue tracking translates very well over to "real life" issues.
Why are the legal documents not on GitHub though? That would be perfect for github.
We've actually stored legal documents on Github in the past (think contracts, proposals, employee handbook, invoices...) as Markdown files. It felt very strange though to collaborate around files through Git. The `PULL > COMMIT > PUSH` workflow works well for a lot of things, not necessarily well when you're preparing a contract.
We've actually built a tool around Dropbox for that very use case. Happy to share it here when it's ready end of this month.
You made your non-tech staff write Markdown files? How did that go? Also, about contracts — .doc/.docx is lingua franca. How did you deal with collaborating with the rest of the world?
2. Actually, the standard would be PDF for legal documents (never understood why people send you a contract in a format that is easily editable). The tool we're currently building allows you to use our WYSIWYG to collaboratively edit documents online while keeping Markdown in the backend.
The final version of a contract is certainly PDF, but during negotiations, people must be able to make and track edits. Git has these features covered, but I just can't imagine sending a Markdown contract draft file marked "FOR DISCUSSION ONLY, NOT INTENDED AS A BINDING CONTRACT" to a typical counterparty.
I guess that your WYSIWYG editor might do the trick — it depends on the extent to which your counterparties rely on MS Office tools.
This is exactly what we do at our team too -- we're developer centric and as developers, we love using Github and Github issues (+ pull-requests) for everything (including PM and HR)
One thing we do miss are certain features from Trello-like tools that give a nice overview of your issues and facilitate PM, so we built a Chrome/FF extension to fill in those gaps (http://zenhub.io)
One thing I wish Github would do is allow for a more granular permission structure. It would be fantastic if we could allow people without github accounts do things like submit issues, or allow certain users (e.g. non-technical staff) only have access to the wiki and issue tracker.
Right now the permissions are centered around what you can do with repositories, it's very developer-centric. I think there is a lot that GitHub could do here to expand their service to be more applicable to an entire organization.
Are your internal wiki, recruitment process, Day-to-day operations, etc. on a private repository? Do you have only one repository or do you have multiple repositories for your internal work?
I expect with a few custom front end UIs, even the poor fits could at least use github as a backing store. This could give other company tools one data layer to inspect.
