Too bad, it was a good product. It appeared around the same time we launched QuantifiedCode, which was a static analysis & automated refactoring SaaS. Our learning was that developer tools are really hard to monetize, except maybe from the security/compliance/productivity angle (which doesn't really target developers though, more their superiors). Developers are just used to "everything" being free & open-source and large organizations like Github/Microsoft keep pushing this angle, as they can monetize their products differently in the long term.
Not sure if this will be good for the developer community though, it seems right now the large cloud players are trying to lock them into a closed ecosystem from which it will be hard to escape. Most open-source code already lives on Github and I'd wager that in 5-10 years most development will take place in cloud solutions, as the complexity of systems increases and makes local development harder. When that has happened I think it's not unreasonable the large players will tighten the screws on developers a bit and start squeezing out more money from them, since it will become very hard to migrate away from that entire ecosystem.
In my opinion, everyone who's willing to pay for a good IDE is already subscribed to JetBrains. And since they have static analysis, excellent refactoring, and plenty of navigation aids for foreign source code, I never got frustrated enough to start DuckDuck-ing for another external tool that might help.
Accordingly, I believe that new developer tools are difficult to monetize because the established ones are already exceptionally good. There's no customer pain to alleviate.
I maintain a similar (but less popular) open-source CLI that generates flow charts for dynamic languages (Python, JS, Ruby, PHP) - https://github.com/scottrogowski/code2flow/
The thought has crossed my mind to try to actually sell it as a SaaS. But by itself, call graph visualizers are the sort of thing that you would need only once or only every once in a while. That sort of software is very difficult to monetize - as 10,000 failed productivity app companies could tell you. I don't know the details of what happened with Sourcetrail but I assume it was similar - developers might have found it useful occasionally but it's not something most developers would use daily or even monthly - so it's hard to justify a subscription.
Hmm. Hard to monetize I guess. Does anyone know of any code analysis software that looks at dataflow? Specifically for embedded contexts, a lot of code is written in a very non-functional style, where the output of one module is a series of global variables. That variable is then picked up by other modules as an input, and used to calculate that modules output, etc etc. I'd pay big $$$ for any software that would tell me "modifying variable X will affect downstream Y which will affect Z"
That’s effectively what Sourcetrail/Coati does in C/C++. Coati was super-helpful for me many years ago when I had to dissect and analyze some crappy vendor code. It also helped me get up to speed on a bunch of C++ spaghetti code on the same project. They hit the nail on the head with their tool and I’ve been using it off and on ever since. I’m actually wondering now if it could be used to analyze Yocto project dependencies and build steps.
I was using Sourcetrail in the past, and I thought it was only an interactive code field/method browser, and didn't have any way to trace causality... unless I missed some functionality.
I was able to use it to trace causality because the code base I used it for was simple enough that given the relationships between each variable and function call I was able to construct the call graph for a particular set of inputs myself.
Is Sourcetrail and a document for taking notes measurably better than having an IDE with 2 panes, "go to definition" and "find all references", and a document for taking notes? In my experience it's not really, and it was tricky to setup Sourcetrail for a given project.
I saw in another comment saying Sourcetrail supplies "who-implements-who". CLion gives you this, Qt Creator doesn't really (outside of Find References), and I'm not sure about VS Code Clangd or Microsoft C++.
Well it’s a matter of friction. Clion gives you the same information but for each item in the chain you have to click on it bunches. In Sourcetrail you mouse over the symbol and click once. And it exposes the dependencies graphically so you can see who uses it. I hardly use that function in Clion but I use it all the time in Sourcetrail because the way it’s presented is easier for me to read and understand.
I read a paper a while back that does almost the inverse of what you're asking (given Z, how could I get a Y and an X). I tried the code and it almost worked, but gave up and had to move on unfortunately. Still, you might find it useful.
AppMap (https://appland.com/products/appmap) takes the approach of recording code execution flows and presenting them visually. There are also some tools to diff and compare AppMaps. These more advanced tools aren’t on the website because they are in development but I’d be happy to share with you, or do a demo. In this way you can get a clear view of the difference in code paths and dependencies, based on different parameters.
Really sad to read this. sourcetrail helped me to understand a foreign codebase when I started my last job. The ability to navigate who-calls-who and who-implements-who back and forth is invaluable, and the search bar is fantastic. This morning I woke up and fantasized about forking the project to keep it alive, but I understand that the work behind it is too much to keep it as a side project.
If it's a useful and helpful tool (and I assume it is from what you've said), what's the problem? It's not as though the existing tool is suddenly going to stop working.
Do you mean "what's the problem with using the last available package of sourcetrail?"?
Nothing, I'm using it. eventually, in some timeframe, the compiled package will stop be installable in a new system, or the unrecognized language features will be too many, which is sad.
This is extremely unfortunate. I've found Sourcetrail so useful for my work. I'd continue paying just to keep the current functionality working without adding anything new.
I'm disappointed that JetBrains do not integrate SourceTrail-like functionality in Intellij and their other IDEs. It just seems to be such a natural (and marketable) feature to bring the IDE experience to the next level.
(I'm aware that SourceTrail plugin exists but it did not work well for me)
I'm slowly getting the impression that IDEs for JetBrains became just a cash cow with limited dedicated developer resources and now the most investment goes into Space.
> The next thing is also fairly straightforward: we expect Kotlin to drive the sales of IntelliJ IDEA. We’re working on a new language, but we do not plan to replace the entire ecosystem of libraries that have been built for the JVM. So you’re likely to keep using Spring and Hibernate, or other similar frameworks, in your projects built with Kotlin. And while the development tools for Kotlin itself are going to be free and open-source, the support for the enterprise development frameworks and tools will remain part of IntelliJ IDEA Ultimate, the commercial version of the IDE. And of course the framework support will be fully integrated with Kotlin.
After all, they need to keep the Mountain View customer happy.
That customer is a cheapskate, too. They strongly encourage everyone to use the free Community versions of the IDEs unless you absolutely need something in the paid editions. (e.g. if you write C++ code it's OK to burn a CLion license.)
For my personal and work use, I pay for my own All Tools subscription or whatever they call it now. $149/year for everything JetBrains makes!
Some of us don’t have workstations capable of running or even indexing our codebases. Jetbrains Projector is the beginning of a remote development story, but VSCode is the only GUI editor taking remote seriously.
Shame, but good on them for open sourcing it (I realise they did a couple of years ago but it's still good that someone can pick it up if they want to).
Not sure if this will be good for the developer community though, it seems right now the large cloud players are trying to lock them into a closed ecosystem from which it will be hard to escape. Most open-source code already lives on Github and I'd wager that in 5-10 years most development will take place in cloud solutions, as the complexity of systems increases and makes local development harder. When that has happened I think it's not unreasonable the large players will tighten the screws on developers a bit and start squeezing out more money from them, since it will become very hard to migrate away from that entire ecosystem.