Or it's in alpha and they haven't found out yet what the feature is worth to corporate users; so they want to do that before anchoring them to a price.

Also, it might vary per account in an unpredictable way, since it's a heavyweight operation that'd cost more compute-hours when run against larger repos, but also involves static-analysis tasks that don't necessarily scale linearly with LOC. So they might just not yet have a predictive model yet for the baseline cost to them, but instead are doing a trial run for each interested user, observing the cost of the workload on their repo, and then extrapolating that out as the cost to run that workload persistently.

Either way, GitHub has been strongly on the side of "clear pricing" so far, so I doubt they would plan to leave things this way. But it's hard to get enough data for a feature like this, when you know each run you do "just to model the curve" is costing you real money.

The usual theory on HN is that having to call means they're gong to milk you for money.

But I work with a SaaS product and the up front pricing is sort of irrelevant if only because the customers want a highly customized product and frankly you really need to know their business / work with them to find what they want to figure out what the price for implementation and customization is.

In our case it isn't a scam or a ploy for more money, it's just the nature of the beast / industry / and every single time it is what customers end up asking for (lots of customization and etc).

Now maybe that is the case for Github Code scanning, but also maybe it is very much a product that depends on how exactly you want it to work for you and that changes the pricing ...

That means the price is negotiable. Rich users pay more, poor users pay less, both users get value, producer makes a profit; everyone wins.

If you're an inside salesperson, cold calling ought to be pretty straight forward:

Customer: Sorry, I just don't think it's worth the price...

Sales: Oh really? Because we've identified 42 critical vulnerabilities in your code base

Customer: Do you have an installment plan?

Sales: Oh really? Because we've identified 42 critical vulnerabilities in your code base

Customer: We know the software runs on java 7. We don't need to pay you 100k to find out.

What's the best way to put this politely from the seller's perspective lol. Do sales teams do background homework on clients' revenue and then come up with different numbers for the exact same offering?

It's one of the big reasons why I try to finalize contracts before announcing a round of funding. You'd be amazed at how much pricing for things jumps immediately after announcing that Series B.

Yes, that happens.

Sometimes it is also possible to brand the exact same service in different ways.

If you have a SaaS that is fully OSHA compliant on all tiers, it may be worth it to not mention the OSHA compliance on lower tiers, but only offer it on the Enterprise tier for example.

Sure, why not? Or they impute value from usage.

Cost based on usage seems very fair to me, but GP said "rich users pay more, poor users pay less," which seems to suggest that if Microsoft emailed me asking about a SaaS subscription for 1M req/day, I should quote them orders of magnitude more than a small startup asking for the same 1M req/day.

I don't think this will be free for all public repositories. Having designed and implemented these kind of static analysers, it's quite costly to scale them - you do want to avoid useless CPU time on the millions of public repositories.

They said during the Keynote that they were willing to spend the millions of dollars necessary to run this on public repos that would activate the option because it's the right thing to do.

I sure do like this MS better than the old one.

That said, Ballmer did get one thing right: https://www.youtube.com/watch?v=Vhh_GeBPOhs

I'm a developer and I hate closed proprietary ecosystems with a passion, so that was just lip service afaic. Current microsoft is much more "developers developers developers"

That's kind of the point, though? A lot of people make fun of Ballmer for using that as a repetitive mantra, but a point often to a mantra, to repeating it to yourself and others, is to remind yourself it is a value you hold, and one that you maybe aren't great at, but should continue to strive towards/get better on. Current Microsoft likely wouldn't have gotten better at "developers, developers, developers" if Ballmer hadn't been shouting that to the rooftops as a core company value, and trying to drive the company to be better at it. The irony that Microsoft got much better at it in part by ignoring some of Ballmer's other past paranoia/NIH/"home-team-ism" probably wouldn't be lost on Ballmer himself either, it always seemed like he kept repeating the mantra as a reminder for himself too to not get caught up in what seemed best to shareholders or to Windows when that wasn't best for developers. He wasn't always successful, but holding a value/ideal doesn't make you perfect, it gives you a goal towards it.

That's a problem that's simple to solve by putting a quota on # analyses per project per month, perhaps weighted by how popular the project is. Like everything else at GitHub, private project users pay extra to cover the public project users. It's proportionall regardless of a feature's cost.

Not sure if that's simple - the cost of running a static analyser is almost never linear. For large popular projects, special care will have to be in place to make sure the analysis terminates and gives meaningful results (a basic timeout won't cut it...). I've experienced many times huge differences in the running times of analysers by minor changes in the code. It'll be interesting to see :-)

It is typical enterprise sales. If the prices aren't listed, it usually means you're charged based on what they estimate you can afford for the value-add. It may be $12k/yr for a big company and $1.2k/yr for a small one.

No way it'll be $12k/year for a big company - I would say $50k minimum.

or vice versa - I remember that O'Reilly Safari was almost 10 times cheaper per person when I worked in 100k+ people company, compared to only couple of thousands people...

And that still makes the solution cost prohibitive for the large company because there's likely only 10 people who have access to the software and ever use it out of the 100 000 employees.

A small company buying a software might actually have a bunch of employees using it.

If you're a reasonably large org with lots of developers and tons of repos, this will be a cost well worth paying.

It's usually the opposite. The vendor tries to charge a crazy amount per user per month or charge for every employee in the company, which makes the solution acutely cost prohibitive.

Nobody wants to spend hundreds of thousands of dollars a year -if not millions- on something that's barely used. Better spend on anything else that is tangible.

Well, Semmle was extremly expensive by itself, so I'd doubt it will be free