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.
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 are reaching out to customers that are in unique situations such as the one you're mentioning here. If you have questions about how the pricing changes affect you, please don’t hesitate to contact support@github.com.
If you need to give Epic Games special treatment just because they have a huge amount of outside collaborators, then your pricing model is broken.
It would be more fair to charge $9/mo per organization member + $1/mo per active outside collaborator (somewhat similar to AWS CodeCommit) than to charge for every single active and inactive member and collaborator equally. Maybe throw in a 50% bulk discount for active outside collaborators over 1000.
This is not a "unique situation", it's how many organizations use GitHub (just on a smaller scale than Epic Games). As giovannibajo1 puts it[1], this change is very unfair to software houses. Giving Epic Games special treatment is only avoiding the issue.
If 5% of Epic Game's 90664 collaborators are active for a given month, then with my proposed pricing model it would now cost them ($9/organization member + ~$2766)/mo, instead of >$800k/mo. No special deals needed, and everyone (presumably) is happy.
This proposed pricing model also scales well for software houses that have have many active outside collaborators. For example, a company with 20 employees and 50% of 100 outside collaborators active in any given month would be charged $230/mo. With 50 employees and 50% of 500 outside collaborators active, it would be $700/mo.
This should also work well for large companies. 200 employees + 30% of 4000 outside contributors active = $2900/mo.
Business are free to close deals with clients in their own terms whenever is lucrative for them. Almost every single company will have "unfair" treatment for big corporations... That way they can get big paying clients. clients that could possibly host their own solutions... It might be that Epic Games in the old business model, with so many users, was not profitable for github, but they are open to negotiate a middle term. It's just business. It is fair.
I think github is on their own right and if you have a case where you think you would be able to negotiate with them, you can send them an email as well... If not, go search another company that have a better cost/benefit for your use case.
Special deals can be made for special cases, it happens all the time. We have a service related business with official pricing, but always bend over backwards when we want to retain long term customers or big paying customers by giving them price cuts and other concessions that we wouldn't normally do to any of our other regular clients.
Not sure why the topic of fairness even comes to the discussion, this is a business not a charity.
> If you need to give Epic Games special treatment just because they have a huge amount of outside collaborators, then your pricing model is broken.
This is an unfair thing to say. Exceptions to otherwise simple rules does not at all mean that the simple rules are "broken".
It is also an unfair thing to say since he clearly says that not only is Epic Games getting this treatment, so is everyone in a similar situation. Furthermore, it has always been possible to negotiate special pricing for special cases. Just send them a message. That is how sales works at almost every company.
Do you understand how businesses work? Almost every company I work for has different terms for lots of customers. They negotiate a deal with a customer, and sign a contract. Every customer might pay different amounts.
So what you're saying is - you know your new pricing is even more ridiculous than your old pricing, but you're willing to burn a little profit to keep big-name clients for the sake of PR.
If I understand this model correctly you fail to admit that there are at least 3 distinct types of users: developers (full access), users (read-only), issue trackers (wiki/issues only). And this model is geared toward a very specific type of organization with a relatively low number of users/trackers compared to developers.
Epic's example is just silly, but nevertheless the world is not black and white. I guess there should be a large number of organizations with multiple CI/CD agents each using distinct credentials for each target. Or examples of software houses requiring client access to issue tracker/wiki.
I guess GitHub analysed their data and made the best decision, but this really does not seem geared toward Enterprise in traditional sense of the word.
Some $vendors (just using familiar terms here) somewhat cover the gray areas pricing $x per unit, where unit is e.g. 2 users or 5 repos, whichever is higher.
It is interesting that - this change will force organizations to pay for "bot" users - that exist for deployment/notifications etc. Our payment bill just doubled from $50 to $106 now (including the bot accounts).
What about organizations that have many members, but few that actually contribute code? We have accounts for most of the people at our company so they can view issues and pull requests, but only about a dozen ever push code.
You are right. For better or worse, we have not had traditional PMs at GitHub. Often that is a role played by what we call a PRP (primarily responsible person). That person is often an engineer or designer.
Personally, I very much like the organic approach to PM'ing products you guys are pioneering, even if this particular project didn't go anywhere. I want to move away from a software culture where Important People hand down mandates to the developer masses. If the PM function can be accomplished organically, e.g., by one or two people who have opinions about where the project should go along with the ability to inspire others in that direction, and this works, it seems to me like such an arrangement would be far preferable.
> Often that is a role played by what we call a PRP (primarily responsible person).
So Github doesn't have managers, it just has Primary Responsible People, who sound an awful like they do the same thing? Just don't call them "managers", because you don't have those. Cute.
Every successful startup eventually discovers that the O(n^2) communication overhead of a perfectly flat org doesn't scale, and needs to adapt to deal with that. The question is whether to develop coordination specialists implicitly or explicitly. Developing doublespeak to protect an idealistic worldview from its incompatibility with reality does seem pathological.
The biggest difference is that our "PRPs" don't see management as their primary responsibility. They're still an engineer or designer first.
> Every successful startup eventually discovers that the O(n^2) communication overhead of a perfectly flat org doesn't scale, and needs to adapt to deal with that. The question is whether to develop coordination specialists implicitly or explicitly.
Yep. This is certainly something we feel the pain of and are wrestling with right now.
> Developing doublespeak to protect an idealistic worldview from its incompatibility with reality does seem pathological.
By definition, we don't have anyone that plays the role of "manager" right now (again, for better or worse). I wouldn't call that doublespeak.
The difference being that instead of having someone who is a "project manager", i.e. that's their job title, all they do is manage and set deadlines and such, you have one of your regular people be the responsible person for some project.
Guessing this is what you mean by "implicitly".
It nicely solves a recurrent enterprise problem where PMs have as their primary duty "go to meetings all day every day" and don't have any understanding of what precisely they're managing.
