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.
>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
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:
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.
The thing I'd like to see Github focus on with their API is granular permissions. There are many SASS integrations that I am just not comfortable with granting access to because I don't want to have any more than necessary 3rd parties having access to repositories. Please correct me if I'm wrong, but every time I grant an application access to my Github account, it automatically has access to all repositories I have access to. I know there are ways that organizations can set permissions such that they can approve app integrations. Still, there are private repositories I have that I would prefer to not have 3rd party integrations be able to access. With 3rd party SASS providers having access to private repositories, it would be trivial for code to be stolen or sold to competitors. If they wanted to be real nasty they could rebase and force push, delete branches, tags, inject malicious code. There are so many potential ways that providing full access to everything you have access to in Github could be exploited.
I would love to see Github add permissions to apps requesting OAuth permissions be able to restrict access to the repositories the 3rd party app has access to. It would also be nice to be able to revoke individual permissions.
Hey! Just in case you missed it, the new GitHub Apps might be a suitable alternative for you - they can have granular permissions (https://developer.github.com/v3/apps/permissions/), so the app can select just enough permissions that it needs. For example, a GitHub App could request permissions to write issues, but not read your code - which isn't possible with OAuth Apps and scopes, as you mention. You also install them on a per repository basis, so you can pick and choose that access. Mostly these are for the app to carry out actions as itself (e.g. create a status, write an issue comment, run a build), but some actions as an authorized user are allowed just now. There's more info on them here: https://developer.github.com/apps/building-integrations/sett...
Thanks for pointing this out. I guess it will take a while before most services start taking advantage of the more granular permission APIs. I've lost count of how many SASS products offer Github integration and then ask for all the permissions. I never feel comfortable with that level of access so I always decline or create a new github account so I can contain access I am granting.
GitHub Apps (was called Integrations until today) allows for 'per repository' configuration. We use it at Percy.io and it works pretty well. It has some other parts that need smoothing (like a non-admin going through the flow), but GitHub's been improving it. :) I like it a lot.
+1 this a thousand times. The only way i have found to effectively lock things down is using an org and creating a new Github user just for third-party integrations.
Yes, though it has been a year or two. However it's more of a personal preference / fits within my normal work routine to use GH. I have a number of OS repos that, for community reasons, need to stay on GH, then most of my normal work is on GH which is generally where the concerns come in from a security standpoint.
I just got an advertising email about this from GitHub, even though I've never subscribed to GitHub advertising mail. I just checked my email settings and it looks like GitHub has added a new option (defaulting to being "on" of course) that auto-subscribes you to spam.
Surely the unsubscription laws don't allow you to retroactively add more options that are defaulted to being on that subscribe you to things you were never subscribed to in the first place? Seems like an easy way to spam people without having any repercussions.
I usually give aliases for such accounts because of this (and because of data breaches). Send me spam and I don't have to put up with your UI to unsubscribe, I just delete mail alias. Of course, that doesn't work if I want to receive any mail from you...
In Australia we have similar legislation, but there are some circumstances where a sender can "infer" that you "probably would consent" to spam. Though I think lots of companies are far too liberal with their interpretation of such provisions.
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".)
I've recently been exploring GraphQL. It's an excellent way to design and maintain Web APIs imo. GitHub is a great resource for learning how GraphQL works. I've been using the GraphiQL tool to experiment with it. However, there is a big issue with the GraphQL implementation in that requests using the POST method work, but the mirror GET requests do not return the same results. For example, see the response for the simple query
> In REST, HTTP verbs determine the operation performed. In GraphQL, you'll provide a JSON-encoded body whether you're performing a query or a mutation, so the HTTP verb is POST. The exception is an introspection query, which is a simple GET to the endpoint.
Thanks. I'm not sure that this conforms to GraphQL best practices. http://graphql.org/learn/serving-over-http/ It seems GET methods should be supported for more than just introspection queries.
You are correct. The transport is a detail and if the query is the same, the response should be the same. What sometimes do create a difference is if one transport has one way of authenticating whereas the other transport-path hasn't. Perhaps this is what happens with the `viewer` output here.
I'm fond of the idea of allowing the query itself to contain every head-meta-data as well, i.e.,: `query { viewer(auth_token: "...") { login }}` because such queries are possible to copy in a URL without having to worry about side-channels of auth.
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.
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!
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.
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.
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.
"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.
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.
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.
Nice to see the old "oops we didn't bother to check the if the 'subscribed' column was true when we imported the mailing list" trick isn't beneath GitHub either.
"...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.
REST v3 API supports conditional requests, that return 304 when content hasn't changed since last time you asked and don't count against rate limit. It means one can use a caching HTTP transport and benefit from that.
Is there any support for caching in the GraphQL v4 API? I'm not seeing anything about it in the docs.
If your query is complex and/or depends on sharded data, it can be difficult or impossible to cheaply (i.e., without re-executing the query) check whether the results have changed. That doesn't mean that the server couldn't execute the query, hash the results, and compare to an ETag from a client's If-None-Match: header, or some GraphQL equivalent of that (if it has it), thus saving network bandwidth. You just might not be able to save cycles and I/O on the server-side.
Github's Marketplace would be much better to Github's bottom line long term if they expanded the free plan to include private repos. I can see this working more to bitbucket's benefit if Atlassian gets more aggressive with its own marketplace offering.
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.
This feels like a Docker-esque move. Taking a product that people love, then thinking that they can conjure new features on top to grow more. The issue is, none of these new features really seems to be something that people want. So, it creates bloat and harms the core product.
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?
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.
> Apps cannot actively persuade users away from GitHub.
This is listed as requirement from the "Requirements for listing an app on GitHub Marketplace" page. Is this saying your app should only support GitHub?
GitHub apps are slightly different than OAuth Apps.
GitHub Apps are per-repository "integrations" that don't perform actions on behalf of a specific user and are installed directly to a repo (with fine-grained permissions).
OAuth Apps are the classic "integrations" installed by a specific user and perform actions on behalf of that user.
I imagine they have lower requirements because they are new, more specialized, and likely to be installed a little less.
I also see that the security requirements are quite high. While its difficult to argue with source code security - here are some of the security requirements:
The standard annual risk assessment shall include, to the best of Developer's ability, the following:
(i) SOC 1 and/or SOC 2 audit report;
(ii) 3rd party proof of PCI compliance (a certificate showing Developer's handling of credit card payments is compliant);
(iii) Privacy Shield Attestation;
(iv) ISO Certification or Cloud Security Alliance Self-Assessment;
(v) Cloud Security Self Assessment;
(vi) any information on subcontractor or vendor production datacenter(s), IaaS, PaaS, or private hosting providers, as required by GitHub based on data and services rendered; and
(vii) Written responses and evidence of specific security requirements as outlined in this agreement
Kinda random - anyone have experience scaling GraphQL APIs? It seems super difficult since you're basically giving clients the ability to arbitrarily query your data.
I never worked on Github scale but if your API is not open and you're in control of all of your clients. Take a look at Persisted Queries[1] . It enables you to whitelist all queries that your application uses.
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.
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.
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.
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.
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.
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.
I think it's only an upgrade for shitty REST-like protocol for APIs. The next after GraphQL will be something like executing your own code in sandboxed environment on the server, with strong constrains etc.
Anyhow, I don't like centralized approaches. Easier access to Github data will encourage to create apps based on a global variable which is the Github. I'd rather want them to release installable libraries that communicate with other parts of the system. Sort of.
> The next after GraphQL will be something like executing your own code in sandboxed environment on the server, with strong constrains etc.
Ah, like a SQL database with procedures? Honestly, I've wondered why the SQL interface isn't common for the remote APIs. My thoughts are that it's possible to run very expensive queries and you'd need provide some HTTP transport so it works for browser JavaScript.
I think we're don't do that because it's too dangerous and user would have too much privileges. I'm referring to something like AWS Lambda, but handled by your library on your web server. Say you can run JS snippet only for 10ms and the only global non-standards variables are those that contain data that can be queried. Or even pass them through function params, look:
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.
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?
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
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.
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.