"...fine-grained repository permissions with GitHub Apps...", excellent, this caused us more problems integrating than anything else. Especially for an organization, anything beyond 15-20 repos and they just couldn't give permission.
Edit: It only applies to Github Apps, we have an OAuth App. shame.
All new features at GitHub are now developed with GraphQL first which means integrators will have access to the same API that we built the feature on once it ships.
GraphQL is a method of creating APIs for consumption by e.g. JavaScript apps or mobile apps that is gaining popularity at the moment. So it can be seen as a successor to REST. It gives you a pretty easy query language to specify which data on which objects you are interested in and that data is then fetched for you. An example could be a React app where each component specifies which data it needs to work on, and then when a page is loaded, all of the rendered component's queries are merged into a single query that fetches all the data in one go.
The main thing vs REST is that it fixes the 'overlapping data in resources' issue. Want a timeline of tweets? Well you'll also want avatars to display, and you probably don't want that in a separate resource (because of multiple requests), so both /tweets and /users/userid will give you avatar details. It's a bit messy.
In graphQL there's one resource and you query it to tell you what you want.
tl;dr: maybe you want OData, JSON-API, or one of the many other standards or practices that solve this simple problem as their super-set of functionality on top of the networking principles of REST.
Using GraphQL for this alone is rather nuclear, as you gain a lot with GraphQL but lose other stuff.
REST and GraphQL are two completely different things, and one is not a replacement for the other. REST is an architectural concept, whereas GraphQL is a query language spec.
That's true in theory, but in practice REST is a (limiting) spec for the kinds of verbs you're allowed to use between systems, and graphQL is a significant and much needed expansion of that.
I have, a lot, and when I could only GET kinds of hierarchical data instead of lumping nested queries, I turned to graphQL (or a, er, homegrown subset of it - it had just been announced) to fill in the gaps. It turns out that most software doesn't, really, care about asking for or updating 'state' per se, and the amount of awkward munging you have to do interpret every kind of query as 'asking about state' is, in my opinion, largely pointless.
The REST philosophy is so conceptually big that it's useless for actually building a system; what I meant by 'in practice' is that REST in practice is 'how do I stuff what I want into the http verbs and make it seem plausibly like state transfer' and that's an exercise that I can't see myself doing 'for purity' again. (in a simple app that actually is just asking about and updating state, sure, it's fine. But when you have to make ten queries for different records because you can't ask the server to join things for you dynamically, it's less fun.)
(edit: especially when you need the results to be an atomic picture of the underlying data, gathered in a transaction. Do I invent a GET resource for every tuple of values I might want to query directly? Or do I stop blindly following an architecture and do the practical thing and implement real queries? A: Always the latter.)
Again, the problems you describe with REST are a limitation of your implementation, not of REST itself. GraphQL itself is built on top of REST via a single GET/POST query endpoint.
The difference between it and typical REST implementations is that the resource identifier and fields to return have been moved into a novel query syntax. However, the same result can be achieved with a typical REST endpoint combined with a sparse fieldset query parameter [1]:
When you say that GraphQL is built on top of REST, are you sure you're not mixing up REST and HTTP? Replace the hierarchical URI structure from REST with a 'novel query syntax' and all that's left is pretty much just the fact that both are ways of fetching data using HTTP methods.
GraphQL is limiting as well, just in a different way. GraphQL uses POST by default, which means you don't get browser caching.
It's a tradeoff that makes sense for Facebook. It allows them to make changes to their API without needing to version it. And they can take the hit of more requests hitting their server. For most apps though, I think the tradeoff is probably not a great one to choose.
Nitpick but REST is not a spec to begin with. It's a set of ideas. There is absolutely no normative REST spec. Developers as of today are still debating what REST is, for better or worse. GraphQL IS a spec, like SOAP, XML-RPC ...
I agree that REST isn't a spec theoretically, but in my experience when you talk about building a Restful api you tend to be actually agreeing to use the HTTP verb spec, which is what I don't like at all.
You might be the wrong person to ask, but I can't really find anything about this elsewhere:
As an App/Integration, is your interaction with the GitHub interface itself limited to only those things that you can do via API calls, such as creating new issues? Or do you have some capacity to modify or add on to the existing interface?
"Once your revenue reaches a minimum of $500 USD for the month, you'll receive an electronic payment from GitHub for 75% of the sales price."
So it looks like Github takes a 25% fee. I thought maybe they would do something more innovative regarding the fee structure, or maybe have a lower intro fee like 15%. But here is seems pretty much on par with the 30% of the Heroku marketplace.
I assume you are referring to GitLab, so yes. GitLab and Bitbucket are both actively releasing new features and have sizable paid user bases. GitHub is the market leader, no question, but it not nearly a monopoly.
"Can a company that's not even close to profitable be considered a "market leader"?"
Sure it can. Uber and Twilio are generally considered, far and away, as market leaders in their respective spaces; Uber is massively unprofitable and Twilio was operating at a loss at the time of its IPO.
Market leadership is a function of production and capacity, not profitability.
It is not uncommon in business to pay a premium for access to a pool of qualified potential buyers. 25% pays not only for the single conversion but all the other exposures and access to the market. So 25% doesn't seem that bad to me.
Atlassian takes 25% fee. If Atlassian takes 25%, GitHub does, if Atlassian has a marketplace, so does GitHub. But Atlassian makes money, while GitHub lost $66m in 9 months of 2016 ( https://developers.slashdot.org/story/16/12/16/1639222/build... ). GitHub is the fallacy of a valuation based on monthly users (33m) instead of based on actual invoices.
Congratulations to the GitHub team for a great release here on the new Marketplace. I'm Matt - CEO at ZenHub [1], one of the launch partners for the Marketplace. We've been building apps on top of the GitHub platform for 3 years now and watching the evolution has been amazing. The three releases here have really helped with our biggest integrator pain points:
GraphQL - better and faster access to data without hitting API limits
GitHub Apps - not having to ask users for so many permissions!
Marketplace - user acquisition targeted specifically at GitHub users
Zenhub is great Matt, good to hear it's beneficial to you :)
I'm going to recommend it to others here, with a caveat: I really wish it would not be so aggressively hijacking the Github UI.
Tabs and side panels move around because the JS on the page finishes executing, making the Github UI feel super sluggish. We also have a lot of projects which end up with the settings tab in a "More" dropdown, despite Boards and Reports being more easily accessible from keyboard shortcuts (and we don't even use Reports)...
All those features are great, but there's no option to turn them off at the UI level, or customize them in any way. Very annoying :(
Thank you for the kind words - and the honest feedback! This are similar to thoughts we have heard for other users and we are working on better ways to give you more control over the UI in the near future
After trying new GitHub Desktop Beta mentioned in the article a week ago: it's still nowhere near compete enough to work:
- You can only stage all changes in a file - so you can't discard 'console.log('Wooo'); debugger;' when committing, you have to remove those in your editor first, then commit.
- you can't reverse commits. Need to roll HEAD back to a previous commit, push those fixes, then resume what you were working on? You can't do it.
- still no graphical interactive rebase to merge and squash and reorder commits (the main reason people put up with sourcetree).
It feel fast and responsive though.
Edit: downvotes seem odd. If you think this is offtopic, the GitHub Desktop Beta is announced in the article.
If I'm understanding you correctly, this is wrong. You can add individual lines in a file to your commit. That's one of the main uses I have for the app: it's easier to split up file changes between commits than on the command line. See this screenshot: http://imgur.com/a/4CQG7 You have to click on the line numbers to add/remove individual lines.
No, Tower works differently (unless it has changed in the few months since I used it). In Tower, you can select lines by clicking line numbers, but then you must click "Stage" to actually stage those lines. Then your selection is cleared and those lines are moved to a separate "Staged" tab for that file. Whereas with GitHub Desktop, just selecting the lines marks them as lines to be staged. (GitHub Desktop doesn't actually run `git add` on those lines until the moment you click "Commit".)
Hm, I like Github but I don't like this. This is a great move, but we already have a code hosting monoculture, and this subtly piggy-backs on it towards lock-in for tooling. Github knows orgs have inertia.
Sorry for the slippery slopeism. I'm just imagining a future where shipping an app without a middleman moves to inconvenient, then annoying, then difficult, then impossible. Because this is exactly how we lost the ability to send email without paying the middleman privacy tax.
Honestly, the marketplace doesn't seem like a good fit for Github. I couldn't see my company or any organization that I am in buying services through Github when we have that capability in the following locations already:
>this subtly piggy-backs on it towards lock-in for tooling
FTA: "More than a dozen integrators have apps in GitHub Marketplace today, including Travis CI, Appveyor, Waffle, ZenHub, Sentry, and Codacy"
Travis CI and many others were widespread prior to this marketplace. Seems to me that creating a marketplace is a logical way to collect these third-party services in one place.
That's an oversight on Github's part and will end in a TOS change in one of two directions: price parity or complete prohibition of paid services that use GH integrations outside of the marketplace
Bitbucket has more traction than you think. Especially in megacorps who use JIRA. As long as the services have a docker container you can run locally I see no lock-in.
bitbucket was a consideration for my team, until we went through the end of life with their other git saas stash. won't consider it again because of the pain we went through due to that. went over to gitlab after that.
Having a complete suite of tools will help Github compete with other options for tooling designed for bigger companies (various ALM suites, Atlassian, etc). I'm happy with it as long as third-party integrations are handled well.
GraphQL will be available in GitHub Enterprise 2.10, and GitHub Apps will be available in 2.11. For Marketplace, we will be researching how to solve similar problems for Enterprise customers after this initial launch.
We've bet big time on Github, and we have a lot built on it. Part of our business depend on it. We're thankful for all that GH has given us, but it'd really really help us to know an estimate when the V3 API is going to be deprecated.
We're a small business and planning the work ahead of time is our only hope.
How about communities, forums, boards? When I see an interesting project I'd like to talk to the developer without cluttering the Issues section.
It could be the entry point of every repo, moderated by the owner of course (something like php docs where people can post interesting stuff related to the page at the end). And it would make Github more social.
I think a dev-social site like that should be separate to GitHub and just use their API to pull in repo data.
Someone should probably give a go at making a site like that. Making it easier for project owners to find contributors and for potential contributors to find projects. Facilitating discussions beyond in issues, etc.
Why do you think you'd be cluttering the issues section? I wouldn't let that (your) perception stop you. Just open the issue if you have something to say.
Please don't. Issues are for bug reports and are not a support forum. If the repo maintainer asks in the README that usage questions should first be asked on Gitter, Slack, or Stack Overflow, please respect that request!
That's why I wish every project had an IRC channel or something - it's a PITA trying to contact a maintainer or project creator because they don't always include their email and github doesn't have private messages.
Feature requests are fine, since, like bugs, they have a defined scope and will eventually be done. However, I've seen some major products move their feature requests to a platform like UserVoice that's designed to track votes and progress.
If I install a free version and hit the limit does it auto upgrade me and charge me or am I just cut off from the service and told I should upgrade to keep using it?
I'm an owner at Codetree - one of the project management launch partners for Marketplace. We talked through this scenario with GH when we were integrating.
What happens today is the limits are enforced on the app side, not he GitHub side.
So for example our free plan is two users. If you wanted to add a third you'd need to go GH Marketplace and upgrade to the eg 10 user plan. That would trigger an upgrade in Codetree and your plan there would enable you to add up to ten users.
In short: you trigger upgrades and downgrades, not the tool vendor you're using or GH, and thresholds are stored in the tool vendors database so they're the ones who decide how to tell you that you need to upgrade.
Edit: sorry for this. it was not my intention to come across this way. I was wrong.
The Github team was great and tireless during this launch, congrats to Github and all the partners.
I'm Jaime, CEO of Codacy[1] and one of the three chosen Code Quality partners for this launch.
We specially love the Github Apps, since we heard for a long time the feedback of asking too many permissions. This has been a bit of a pain point. With Github Apps, it will be easier to cherry pick permissions. This is not yet running in Codacy but it will soon.
One of the reasons why we're excited and decided to take part is the really qualified audience. Everyone just really gets what we do (automated code review) when they are already familiar with Github.
I don't think you understand your "really qualified audience" very well if you thought a coordinated marketing campaign with all the other "chosen" launch partners was a good idea.
I guess that the main benefit of GitHub Marketplace would be the full-scale integration with GitHub Issue and Project board, launched last year. Consider a common situation: when CI fails, people need to reopen an issue manually, getting an error report via email. People who are in charge of project management may be seeking a better way to streamline the manual task, which probably increased since the introduction of Project board.
To be clear, I’ve been away from software development over the years, so I’m curious about the impact of Project board. Does it useful in the first place? Did it require manual tasks between other services such as CI? Do you, who is in charge of issue or board assignment, feel frustration using it?
I'm Tomek, CEO at codebeat [1] - automated code review for the web & mobile and one of the launch partners for the GitHub Marketplace. For us and probably for many tools that integrate with Github, an announcement about Github Apps is great news because we won't need to ask users for so many permissions.
GraphQL also seems to be an interesting way to combine more data available on Github with results of our code analysis.
I think Github Marketplace is a right fit for Github and community because it lowers the barrier to use third-party tools. Github puts them in one place, and it is super easy to add or remove each of them.
Mike from Percy[1] here, we're one of the 4 Continuous Integration launch partners in the GitHub Marketplace.
Congrats to GitHub on this impressive launch! We're very happy to share the stage with so many great partners and dev tools, many that we use everyday too. Happy to answer anyone's questions about what we're working on or our integration in to the marketplace.
The shameless support posts by execs/founders at launch partners are slimy! You guys should be ashamed. This isn't your marketing site, it's for discussion.
I'm not affiliated with anyone doing this, but a) I haven't seen anything yet, and b) in general, the availability of (even commercial) options is valid discussion. Plus, I'm not unsympathetic: developer tooling is notoriously difficult to market, and it's hard to pass up an opportunity like a Hacker News front-page story about an almost universally loved service (GitHub) building a dev tool marketplace to talk about your dev tools! When Valve announced Steam you think game devs weren't gushing about their games? Of course they were.
Show HN is expected to be submitted by the person who made the thing to show, and it's expected that they're showing it for a reason: it's either new, or had a significant change.
Edit: So technically, GH probably could have had their new shit posted as a Show HN: but you generally want that to be something people can 'play' with right away, not a blog post about a way to pay more for the same things. /Edit
My best guess with what happened here (based on the similarity of the texts) is that GH arranged a pre-formatted 'base' text, with placeholders, sent it to each of the involved CEOs/whatevers and said "we will submit our story to HN, once we do please comment using this template".
Every one of the comments basically matches this pseudo-regex:
"<Name> (at|from) <Company> [1] ..... one of the ([:digit:] <App Category>)? launch partners" and the [1] is referenced as a link to GitHub Marketplace. Only one has a link to their own site.
The HN story itself was submitted by someone who at least used to be, and based on that, likely still is a GH employee.
I assume they were trying to drum up lots of positive attention about this with the cool-kid me-too cargo-culting developer set that makes up a large part of HN readers.
165 comments
[ 5.0 ms ] story [ 232 ms ] threadEdit: It only applies to Github Apps, we have an OAuth App. shame.
https://developer.github.com/apps/building-integrations/sett... https://developer.github.com/apps/building-integrations/sett...
All new features at GitHub are now developed with GraphQL first which means integrators will have access to the same API that we built the feature on once it ships.
If you want to learn more, one of our engineers just spoke at GraphQL Europe yesterday detailing our experiences with GraphQL thus far, here are his slides: https://speakerdeck.com/bswinnerton/launching-githubs-public...
In graphQL there's one resource and you query it to tell you what you want.
https://blog.runscope.com/posts/you-might-not-need-graphql
tl;dr: maybe you want OData, JSON-API, or one of the many other standards or practices that solve this simple problem as their super-set of functionality on top of the networking principles of REST.
Using GraphQL for this alone is rather nuclear, as you gain a lot with GraphQL but lose other stuff.
https://philsturgeon.uk/api/2017/01/24/graphql-vs-rest-overv...
The REST philosophy is so conceptually big that it's useless for actually building a system; what I meant by 'in practice' is that REST in practice is 'how do I stuff what I want into the http verbs and make it seem plausibly like state transfer' and that's an exercise that I can't see myself doing 'for purity' again. (in a simple app that actually is just asking about and updating state, sure, it's fine. But when you have to make ten queries for different records because you can't ask the server to join things for you dynamically, it's less fun.)
(edit: especially when you need the results to be an atomic picture of the underlying data, gathered in a transaction. Do I invent a GET resource for every tuple of values I might want to query directly? Or do I stop blindly following an architecture and do the practical thing and implement real queries? A: Always the latter.)
The difference between it and typical REST implementations is that the resource identifier and fields to return have been moved into a novel query syntax. However, the same result can be achieved with a typical REST endpoint combined with a sparse fieldset query parameter [1]:
where "work" is a sub-resource in the same vein as GraphQL. The difference between this and GraphQL is purely syntactic: [1] http://jsonapi.org/format/#fetching-sparse-fieldsetsGraphQL is a form of RPC, it's not REST.
It's a tradeoff that makes sense for Facebook. It allows them to make changes to their API without needing to version it. And they can take the hit of more requests hitting their server. For most apps though, I think the tradeoff is probably not a great one to choose.
Nitpick but REST is not a spec to begin with. It's a set of ideas. There is absolutely no normative REST spec. Developers as of today are still debating what REST is, for better or worse. GraphQL IS a spec, like SOAP, XML-RPC ...
Actually fix the underlying cause, not just add a quick hack to make it go away.
Happy to answer questions about our experiences working with the GH team to integrate, why we decided to list in Marketplace, etc.
[1] - http://blog.codetree.com/articles/project-management-launch-...
[2] - https://github.com/marketplace/codetree
As an App/Integration, is your interaction with the GitHub interface itself limited to only those things that you can do via API calls, such as creating new issues? Or do you have some capacity to modify or add on to the existing interface?
So it looks like Github takes a 25% fee. I thought maybe they would do something more innovative regarding the fee structure, or maybe have a lower intro fee like 15%. But here is seems pretty much on par with the 30% of the Heroku marketplace.
Do you compare all usage, or just their hosted versions (i.e. do on-premise installs count)?
Do you compare all usage, or just paid usage?
Can a company that's not even close to profitable be considered a "market leader"?
Sure it can. Uber and Twilio are generally considered, far and away, as market leaders in their respective spaces; Uber is massively unprofitable and Twilio was operating at a loss at the time of its IPO.
Market leadership is a function of production and capacity, not profitability.
GraphQL - better and faster access to data without hitting API limits
GitHub Apps - not having to ask users for so many permissions!
Marketplace - user acquisition targeted specifically at GitHub users
[1] https://github.com/marketplace/zenhub
I'm going to recommend it to others here, with a caveat: I really wish it would not be so aggressively hijacking the Github UI.
Tabs and side panels move around because the JS on the page finishes executing, making the Github UI feel super sluggish. We also have a lot of projects which end up with the settings tab in a "More" dropdown, despite Boards and Reports being more easily accessible from keyboard shortcuts (and we don't even use Reports)...
All those features are great, but there's no option to turn them off at the UI level, or customize them in any way. Very annoying :(
- You can only stage all changes in a file - so you can't discard 'console.log('Wooo'); debugger;' when committing, you have to remove those in your editor first, then commit.
- you can't reverse commits. Need to roll HEAD back to a previous commit, push those fixes, then resume what you were working on? You can't do it.
- still no graphical interactive rebase to merge and squash and reorder commits (the main reason people put up with sourcetree).
It feel fast and responsive though.
Edit: downvotes seem odd. If you think this is offtopic, the GitHub Desktop Beta is announced in the article.
If I'm understanding you correctly, this is wrong. You can add individual lines in a file to your commit. That's one of the main uses I have for the app: it's easier to split up file changes between commits than on the command line. See this screenshot: http://imgur.com/a/4CQG7 You have to click on the line numbers to add/remove individual lines.
You could submit an issue or a pull request with suggestions on what a more obvious UI might be!
- First I thought you select lines, like other git apps. No, it's not just that numbered line, it's the actual digits on the left.
- Then I selected some digits, expecting a 'stage' button to appear.
Then finally I realised just selecting the lines committed only them.
Even working out how to do it, it's still weird because lines with blue digits now get committed, lines with green ones don't.
Sorry for the slippery slopeism. I'm just imagining a future where shipping an app without a middleman moves to inconvenient, then annoying, then difficult, then impossible. Because this is exactly how we lost the ability to send email without paying the middleman privacy tax.
- Docker - Heroku - AWS - Google - Direct
Feels more for "discovery" than purchasing.
FTA: "More than a dozen integrators have apps in GitHub Marketplace today, including Travis CI, Appveyor, Waffle, ZenHub, Sentry, and Codacy"
Travis CI and many others were widespread prior to this marketplace. Seems to me that creating a marketplace is a logical way to collect these third-party services in one place.
TravisCI Pro Bootstrap via Github is $89: https://github.com/marketplace/travis-ci/plan/MDIyOk1hcmtldH...
I would say that the irony occurred when the "hub for open-source projects" is a closed-source platform.
(And I would say that as a paying user of Github that rather loves it.)
People already pay anywhere from 3-10x more for GH than for alternatives like BitBucket. I'm sure plenty will just click on 'buy'.
You want to see a tax? How does $72/user/year for code coverage tooling sound?
We're a small business and planning the work ahead of time is our only hope.
It could be the entry point of every repo, moderated by the owner of course (something like php docs where people can post interesting stuff related to the page at the end). And it would make Github more social.
Someone should probably give a go at making a site like that. Making it easier for project owners to find contributors and for potential contributors to find projects. Facilitating discussions beyond in issues, etc.
And what if the maintainer does not talk about any forum in the README? (What is, like, some 90% of the repos.)
https://github.com/marketplace/category/continuous-integrati...
What happens today is the limits are enforced on the app side, not he GitHub side.
So for example our free plan is two users. If you wanted to add a third you'd need to go GH Marketplace and upgrade to the eg 10 user plan. That would trigger an upgrade in Codetree and your plan there would enable you to add up to ten users.
In short: you trigger upgrades and downgrades, not the tool vendor you're using or GH, and thresholds are stored in the tool vendors database so they're the ones who decide how to tell you that you need to upgrade.
The Github team was great and tireless during this launch, congrats to Github and all the partners.
I'm Jaime, CEO of Codacy[1] and one of the three chosen Code Quality partners for this launch. We specially love the Github Apps, since we heard for a long time the feedback of asking too many permissions. This has been a bit of a pain point. With Github Apps, it will be easier to cherry pick permissions. This is not yet running in Codacy but it will soon.
One of the reasons why we're excited and decided to take part is the really qualified audience. Everyone just really gets what we do (automated code review) when they are already familiar with Github.
[1] https://github.com/marketplace/codacy
To be clear, I’ve been away from software development over the years, so I’m curious about the impact of Project board. Does it useful in the first place? Did it require manual tasks between other services such as CI? Do you, who is in charge of issue or board assignment, feel frustration using it?
GraphQL also seems to be an interesting way to combine more data available on Github with results of our code analysis.
I think Github Marketplace is a right fit for Github and community because it lowers the barrier to use third-party tools. Github puts them in one place, and it is super easy to add or remove each of them.
[1] http://github.com/marketplace/codebeat
Congrats to GitHub on this impressive launch! We're very happy to share the stage with so many great partners and dev tools, many that we use everyday too. Happy to answer anyone's questions about what we're working on or our integration in to the marketplace.
[1] https://github.com/marketplace/percy
"We are the chosen ones. We love the leader."
HN submissions are open, nothing stops them writing a blog post and submitting that.
The similarity of the posts makes it seem like a coordinated effort by those involved. A circle jerk of marketing bullshit, if you will.
Edit: So technically, GH probably could have had their new shit posted as a Show HN: but you generally want that to be something people can 'play' with right away, not a blog post about a way to pay more for the same things. /Edit
My best guess with what happened here (based on the similarity of the texts) is that GH arranged a pre-formatted 'base' text, with placeholders, sent it to each of the involved CEOs/whatevers and said "we will submit our story to HN, once we do please comment using this template".
Every one of the comments basically matches this pseudo-regex: "<Name> (at|from) <Company> [1] ..... one of the ([:digit:] <App Category>)? launch partners" and the [1] is referenced as a link to GitHub Marketplace. Only one has a link to their own site.
The HN story itself was submitted by someone who at least used to be, and based on that, likely still is a GH employee.
I assume they were trying to drum up lots of positive attention about this with the cool-kid me-too cargo-culting developer set that makes up a large part of HN readers.