Completely agree. But the tools don't make this very easy.
Back in college I was working on patches to OpenSSL, Chrome, Firefox, Apache, etc., to add support for TLS-SRP, and it was a huge pain to jump into these massive codebases and try to understand them. I was using Emacs and had all of the various language support modes configured, but go-to-definition and cross-references barely worked. Searching was slow, and if I wanted to discuss a piece of code with my CS lab partners, I couldn't just share a link.
A friend felt the same pain but then went to work at Google for a bit. At Google, they have some pretty amazing code reading/searching tools (see https://static.googleusercontent.com/media/research.google.c...), and these tools helped Google build a culture of thoroughly reading and reviewing code. The causality is bidirectional, but having good tools certainly played a role in Google's success.
That friend and I ended up building a product, Sourcegraph, initially for ourselves to make code reading easier. We've now built a successful business out of it with the help of an amazing team. Here it is pulling in the OpenBSD sources: https://sourcegraph.com/github.com/openbsd/src/-/blob/lib/li.... Sourcegraph has advanced features for several languages; see https://sourcegraph.com/github.com/mholt/caddy/-/blob/caddyh..., for example. If you love to read code (or want to), we hope you'll love our product. Email me if you have any feedback/requests.
On first impressions, since I have no experience with OpenGrok nor Sourcegraph, they look to serve about the same core need and provide most the same core functionality, but Sourcegraph is about what I would expect from a company providing usability and features on top of what is generally available for free.
That is, Sourcegraph looks to compare to OpenGrok like Github compares to Gitweb. At least from a cursory look.
Considering that Sourcegraph doesn't support C or C++ and those are pretty much the only languages I write that have less than perfect IDE crossrefence support I don't really see a point in Sourcegraph at the moment.
Didn't one of the sourcegraph founders post a link to OpenBSD in sourcegraph at the top of this thread? That's C. Am I misunderstanding what you're taking about?
Just some honest feedback on your pricing that's hopefully helpful: Your Enterprise plan is at least an order of magnitude more expensive than what many organizations would pay for something like this.
E.g. a Jira license for 2000 people costs $24,000 yearly[1], licensing this for the same amount of users would be $1,200,000.
This is way more than organizations of that size tend to pay for top-tier support contracts for software that's critical to business continuity.
Pricing per-user without any advertised discounts is also a trap if you're selling to large organizations. A lot of them tend to, for simplicity's sake, want to just give everyone in the org access to a tool like this, but only 5-10% of the workforce might be using it, but due to how you're pricing it there's no way it's going to be bought in the first place.
Granted, Jira ends up costing way more than $24,000 yearly, because all plugins need to be purchased for all users, and Jira tends to require employing at least one full-time admin. All-told, it's more in line with a few hundred thousand dollars yearly.
With that said, $1.2 million for 2,000 users yearly for a code-search tool is some pretty insane Kool-Aid pricing, and it prevents me from even recommending it to my bosses - I'd be laughed out of the room.
A JIRA installation with 2,000 users probably has many fewer developers, and you'd only pay for Sourcegraph for developers. For customers where this makes a big difference, we work with them on the pricing.
But if you're a large company with 2,000 engineers, then you could be spending nearly a half-billion dollars on engineering salaries alone. If Sourcegraph makes your developers at least 0.5% more productive, then it pays for itself.
And shouldn't companies be spending 5-10% of their salary budget on getting the best tools? (That would mean tens of millions of dollars annually for this hypothetical 2,000-person company.) Companies routinely pay that for people in other roles, such as salespeople, medical professionals, stock/bond traders, etc. I think we all agree developers deserve the same. :)
> you could be spending nearly a half-billion dollars on engineering salaries alone. If Sourcegraph makes your developers at least 0.5% more productive, then it pays for itself.
A couple things:
a) $500 million / 2,000 engineers is $250,000 per engineer. Even if you take benefits and equipment / licensing costs into consideration, that's really high. Most enterprises aren't located in Silicon Valley and don't pay Silicon Valley engineering salaries.
b) I don't doubt your 0.5% figure, and the argument about the best tools money can buy goes all the way back to the Joel Test, but engineers aren't the ones who make the decision whether to buy these tools, the enterprise bean counters do. Do you have any evidence, even anecdotal evidence, to back up your 0.5% number? Because otherwise, the bean counters just see yet another toy that engineering wants to put on the budget, and the budget is always too restricted to add toys to the budget. Remember how long it took most enterprises to understand that multiple monitors aided productivity? And that's practically obvious. Why does Sourcegraph get a pass? What kind of concrete evidence can engineers pass along to their bean counters to justify the cost of Sourcegraph's licenses?
edit: I want to add, Sourcegraph isn't going to be paid only for engineers. It'll also be paid for QA, engineering management, infrastructure/ops... eventually, everyone wants to store something in version control.
Maybe what you're saying is true, but that simply isn't the reality we live in. JIRA is a great comparison point as it produces a lot of value for a team. Do you really think your tool provides 10x more value than JIRA for a team? Would you recommend a team buy your system over a quality issue tracker if they don't have one?
> I was using Emacs and had all of the various language support modes configured, but go-to-definition and cross-references barely worked. Searching was slow, and if I wanted to discuss a piece of code with my CS lab partners, I couldn't just share a link.
When you say something vague yet absolute like you "had all of the various language support modes configured," that is a big indication that you did not have them configured. There are about four major modes for C/C++. Searching and cross-reference is done with external tools. The only time I ever thought searching was slow was when using the grep that came with Mac OS X. There is absolutely no way that online tools can beat ag or rg for code searching, especially if you have an SSD. Exuberant ctags and GNU Global work for cross-referencing and support dozens of languages. And you have Magit and VC mode right there to track down source code history.
>There is absolutely no way that online tools can beat ag or rg for code searching, especially if you have an SSD. Exuberant ctags and GNU Global work for cross-referencing and support dozens of languages. And you have Magit and VC mode right there to track down source code history.
In my experience, you're right; but that opinion wouldn't make for a nice long-form advertisement for your software project.
Hook them with hinting "I have a solution better than emacs" first paragraph, add a happy tale about collaboration and friendship, and then pile on the advertisement.
A lot of us learned this way from John Lions' Unix Commentary. There have been similar books for Linux and Apache. (They didn't have a concordance for the Linux Core Kernel Commentary so I wrote one and sent it the author who mentioned it in the second printing.) But I think for OpenBSD something like SourceGraph is more than enough.
I would recommend the SourceGraph people post browsers for Linux, L4, Xen, LLVM, ... and other great open source infrastructure projects. You'll drive more interest in your product in a helpful way.
There is a note that shows up when viewing OpenBSD sources
"C/C++ is not yet supported (beyond basic code browsing and text search)"
In my experience, these two languages are the most difficult to find good tools for, to browse, jump, and manage large code bases. Yes, some exist, but I thought this was the point of "good tools matter"?
I never got around to really testing it, but still remember when OpenGrok was announced, way back when - apparently it's still active. I've been wondering if it would make a good front-end/source-browser component for a trac[t]-like product (with something else for vcs and bug tracking etc):
> I was using Emacs and had all of the various language support modes configured, but go-to-definition and cross-references barely worked. Searching was slow, and if I wanted to discuss a piece of code with my CS lab partners, I couldn't just share a link.
Meanwhile, most IDEs, QtCreator, KDevelop, VS, Eclipse... had this feature for years.
Back in college I was working on patches to OpenSSL, Chrome, Firefox, Apache, etc., to add support for TLS-SRP, and it was a huge pain to jump into these massive codebases and try to understand them. I was using Emacs and had all of the various language support modes configured, but go-to-definition and cross-references barely worked. Searching was slow, and if I wanted to discuss a piece of code with my CS lab partners, I couldn't just share a link.
A friend felt the same pain but then went to work at Google for a bit. At Google, they have some pretty amazing code reading/searching tools (see https://static.googleusercontent.com/media/research.google.c...), and these tools helped Google build a culture of thoroughly reading and reviewing code. The causality is bidirectional, but having good tools certainly played a role in Google's success.
That friend and I ended up building a product, Sourcegraph, initially for ourselves to make code reading easier. We've now built a successful business out of it with the help of an amazing team. Here it is pulling in the OpenBSD sources: https://sourcegraph.com/github.com/openbsd/src/-/blob/lib/li.... Sourcegraph has advanced features for several languages; see https://sourcegraph.com/github.com/mholt/caddy/-/blob/caddyh..., for example. If you love to read code (or want to), we hope you'll love our product. Email me if you have any feedback/requests.