Github For Everything(wiredcraft.com)
wiredcraft.com
Github For Everything
http://wiredcraft.com/posts/2013/09/18/github-for-everything.html
13 comments
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.
Welcome to the internet! You must be new here :)
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.
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.
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.
Walled gardens are not new. HTTP was first documented in 1991. Compuserve was founded in 1969!
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.
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.
Might not be free software, but: https://enterprise.github.com/
hosting GitHub: https://enterprise.github.com/
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.
That is an inaccurate generalization of free software. Also, free software has the most important advantage off all: giving you freedom.
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.
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.
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.
> If you really want a Web interface there's Gitorious (which has been around longer than GitHub) and GitLab.
and recently https://rhodecode.com/ which kinda looks like an opensource version of BitBucket.
and recently https://rhodecode.com/ which kinda looks like an opensource version of BitBucket.
I see nothing on Rhodecode's website indicating it is open source, by any definition of the term.
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.
cheers
cheers
yeah, looks like they removed the info.
https://secure.rhodecode.org/rhodecode
https://github.com/marcinkuzminski/rhodecode/
https://bitbucket.org/marcinkuzminski/rhodecode/
https://secure.rhodecode.org/rhodecode
https://github.com/marcinkuzminski/rhodecode/
https://bitbucket.org/marcinkuzminski/rhodecode/
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.
>As far as changes, you're right, but the changes are true with any product.
This is true, but only with proprietary software are they unfixable.
This is true, but only with proprietary software are they unfixable.
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 _____"....
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.
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.
> I think it would be cool to set up a 'github' 'p2p protocol'
I believe that one is called Git, with HTTP or SSH and SMTP as helper transports.
(In particular, pull requests are done with `git format-patch` and `git send-email`)
I believe that one is called Git, with HTTP or SSH and SMTP as helper transports.
(In particular, pull requests are done with `git format-patch` and `git send-email`)
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.
So what you really want is a torrent tracker?
It lacks the issue tracking, though.
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..
You're looking for this:
https://code.google.com/p/gittorrent/
Frustratingly, it has been dead in the water for years. It strikes me as a crucial piece of technology.
https://code.google.com/p/gittorrent/
Frustratingly, it has been dead in the water for years. It strikes me as a crucial piece of technology.
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.
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.
Although maybe this blog post was already in the pipeline, unfortunate juxtaposition with yesterday's GitHub outage.
Although I truly do love GitHub, it's not unconditional love. My love's uptime closely tracks GitHub's.
Although I truly do love GitHub, it's not unconditional love. My love's uptime closely tracks GitHub's.
Your wife wishes github was more reliable.
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.
Protip: A user with an account name, "fuckyoutoo" does not care about protips.
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 ;-)
Alas, perhaps times have changed around here and I need to start treating people like redditors until proven innocent ;-)
Looks like a throw-away account. Who knows what the dude's problem (cowardice my guess) but he didn't want to take the rep hit.
Another way of putting it might be that accurate judgement of the audience is an essential skill for any comedian.
[deleted]
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.
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.
Wanna try it? Take any repository, for example Hubot: https://github.com/github/hubot. Now go ahead and run:
git clone https://github.com/github/hubot.wiki.git
Wanna try it? Take any repository, for example Hubot: https://github.com/github/hubot. Now go ahead and run:
git clone https://github.com/github/hubot.wiki.git
Issues are an important part of a product/library that is evolving. If you loose an edge case bug, you could take months to face it again.
You could also use the GitHub Issue API http://developer.github.com/v3/issues/ to backup the issue data
I didn't know the ".wiki" notation for downloading it. Thanks!
Every repo can be cloned down as normal. ~~I'm not certain about the issue tracking.~~
Edit: according to a quick Google search issues can be exported in JSON format.
Edit: according to a quick Google search issues can be exported in JSON format.
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.
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.
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?
1. We wrote a WYSIWYG for Markdown (https://github.com/Wiredcraft/Moleskin). Also, everybody learns Markdown at Wiredcraft.
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.
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.
never understood why people send you a contract in a format that is easily editable
All formats are easily editable; contracts should be digitally signed to prevent shenanigans.
All formats are easily editable; contracts should be digitally signed to prevent shenanigans.
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.
I guess that your WYSIWYG editor might do the trick — it depends on the extent to which your counterparties rely on MS Office tools.
I actually imagine github would work quite well for this if office users edited directly from the github website.
Please do share, would be interested to see it.
Github goes down far too frequently to consider using the non-enterprise version for everything.
The realtime collaboration on Google docs is also mega useful for weekly meetings and something that Github's wikis doesn't match.
The realtime collaboration on Google docs is also mega useful for weekly meetings and something that Github's wikis doesn't match.
I'm still bracing myself for the Github for Writers; http://madebyloren.com/github-for-writers
I'm writing a book for O'Reilly and we use their Atlas tool which stores everything in a git repository. Pretty cool, especially for technical books.
It's open to the public [oops, I lied. It's private beta] in beta: http://atlas.labs.oreilly.com/
It's open to the public [oops, I lied. It's private beta] in beta: http://atlas.labs.oreilly.com/
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)
Disclaimer: I work at Axiom Zen
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)
Disclaimer: I work at Axiom Zen
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.
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.
We've been using Huboard recently, but I'm definitely in terested in seeing how Zenhub compares to it. How are you guys going to monetize this?
This idea is awesome. Thanks for sharing!
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?
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.
Like this way of getting things done. Geeky! I may translate the post into Chinese later.