In addition, if you like what you’re seeing here and want to support this project as open source, please consider a monthly donation: https://www.patreon.com/sourcetrail/overview
I was a happy licensed user for the Java project I was working on, but had to stop using Sourcetrail when I switched jobs and started with .NET and TypeScript. So I’ve been working to create indexers against their open source SDK in the last few weeks. That the project is now open source means it’s making my spare-time effort of writing an indexer that much easier, and I personally look forward to contributing more to the project. I think graph visualization of source code has a bright future ahead of it, and there’s plenty of opportunity to crowdsource improvements to Sourcetrail that will benefit even more developers. This seems like a smart move... if they can financially support themselves at an open source initiative like this.
Thanks for the link; the site is indeed down for me.
Honestly HN generates nowhere near enough traffic (from experience) that a site with any semblance of sane design/architecture cannot handle on even the constrained resources of a RaspberryPi.
Reddit /r/all on the other hand, I can understand.
I've been following sourcetrail since the author did his cppcon talk. It does the job well - I remember loading Wolfenstein 3D into sourcetrail and watching the call graph explode from a single point of MAIN into a massive menorah of calls, all winding back to a circular buffer, and finally a single point of FREE. It was beautiful, and it's bittersweet to see the author go the open source route. I had high hopes for their commercial success.
This going open source is just wonderful, but I have a feeling this is going to significantly decrease lower the company's revenue and ultimately hurt the product.
So here's my question: how do we avoid that? Outside of freelancers who control their finances directly, most developers probably won't be able to convince their company's money people to pay for something they can get for free. Paying a relatively low annual license can usually be justified for the sake of efficiency, but "donate to the devs to keep the project going" is a much tougher sell.
My only idea is selling a "subscription" to signed binary builds under a non-free license, but I'm not sure that would work very well either...
So far, with far fewer users, the paid tier is a _dramatically_ more effective option: it makes nearly $1000 a month, and increasing, while donations make $50 a month. The latter library is a small package, but it is a small package that's installed 6 million times a week, so there's a huge volume of software depending on this. The former app has a few thousand monthly users but similarly isn't something that your whole business is typically going to revolve around, it's just a useful tool.
Imo, unless you're huge or you're going to become a really fundamental part of people's business, donations aren't going to work. Small libraries or occasional-use tools just won't get there. If you're webpack it's great, and I do think it's super valuable for those cases, but most projects aren't webpack.
However for almost any tool you can separate the power user/enterprise features from the basic features, and then put the former behind a simple paywall. It can remain open source, so the determined can fork the whole project and remove the paywall easily if they prefer, but for any large organisation that doesn't really make sense from a time or ongoing cost perspective, and you either miss out on all future development, or you have constant work to merge upstream changes with yours. Alternatively, you pay $10 a month and the problem goes away.
So far so good, and it feels like a win-win. Hard to translate to libraries I think, but there's interesting developments here like https://gitroyalty.com/.
I don't get all the posts saying it's sad that it didn't take off commercially. No obstacle prevents grateful programmers from enriching the creators of a useful tool, and expanding the audience of likely users increases the probability of that happening. It's a great looking product (that I had not been aware of when it was commercial) and deserves wide adoption.
It's odd that we're so reluctant to spend money on quality tools that increase our productivity. It pains me to spend the $300 for my editor even though it has paid for itself dozens of times over. I think we're spoiled by open source(and shareware before that).
Most engineers have an easier time getting their company to pay for a 1000$ tool, than donate 1000$ to an open-source project, that's the long and short of it.
I agree. I think this is the sort of tool that is better off as an open platform on top of which others can build more specific pieces. In some sense, I think a lot of the advantages of programming languages being open apply here.
It's sad to see Sourcetrail didn't make it as a commercial product. I really enjoyed it when I tried it out a year or so ago.
I appreciate the retrospective on the hurdles you faced. Could you share some learnings for things that did work? I could tell you spent a lot of resources getting the onboarding flow correct (Visual Studio Project Import was nice!), anything related to onboarding-related learnings you can share?
Applying the tool on your codebase should be easy. For us, using the Clang Compilation Database format, that already holds all configurations to build a project was of great value for faster C and C++ project setup.
You cannot convince developers to use a tool with just words. They need to experience the benefits first hand. And getting to the benefits should happen as fast as possible after starting to test the tool.
I bought Sourcetrail a few years ago. It’s been highly useful in diving into large, unfamiliar projects. Thank you! I hope the open model works for you. I know the cost stopped some of my co-workers from buying it.
For others, I suggest giving it a try. The only issues I’ve run into is when a project has a build setup that won’t work on your machine. It still works, you just can’t dive as deep.
I wonder if selling integrations with language server[1] implementations would be a way to multiply the customer base enough to make this viable as a business.
If indexers were to be maintained separately, the only thought I have is something based on an IDE like Eclipse or IntelliJ, or something based on SourceGraph. To that end, I think open sourcing will do more to support usage, and usage would drive further licensing/support...
It’s possible there could be add-ons sold to help refactor code or maybe a web-based version, perhaps merging with SourceGraph as a client? Or use in code review? Lots of possibilities, perhaps, just not easily/quickly commercial I would think without further development first.
I'm not sure what lesson to draw either, but I kind of suspect that the situations where this tool adds the most value (e.g. a developer needs to jump into a code base without anyone around to help orient exploration) are also the situations where there's least likely to be funding. And in that particular example, if the developer is new to the org, it is a situation where they're unlikely to know how to/feel comfortable asking how to gain funding.
I indexed a few samples. It looks pretty good. Can't use it for work, but definitely makes it really fun to look at source code. Java is 3GL. Python is 4GL.
McKayDavis|6 years ago
https://github.com/CoatiSoftware/Sourcetrail
lstamour|6 years ago
I was a happy licensed user for the Java project I was working on, but had to stop using Sourcetrail when I switched jobs and started with .NET and TypeScript. So I’ve been working to create indexers against their open source SDK in the last few weeks. That the project is now open source means it’s making my spare-time effort of writing an indexer that much easier, and I personally look forward to contributing more to the project. I think graph visualization of source code has a bright future ahead of it, and there’s plenty of opportunity to crowdsource improvements to Sourcetrail that will benefit even more developers. This seems like a smart move... if they can financially support themselves at an open source initiative like this.
If anyone wants to pitch in on the TypeScript indexer, I’ve an SourcetrailDB SDK diagram I put together at https://github.com/LouisStAmour/SourcetrailTypescriptIndexer... and a thread with ongoing notes and Node.js bindings at https://github.com/CoatiSoftware/SourcetrailDB/issues/2#issu...
egraether|6 years ago
ComputerGuru|6 years ago
Honestly HN generates nowhere near enough traffic (from experience) that a site with any semblance of sane design/architecture cannot handle on even the constrained resources of a RaspberryPi.
Reddit /r/all on the other hand, I can understand.
app4soft|6 years ago
[0] https://github.com/CoatiSoftware/Sourcetrail/releases
egraether|6 years ago
glouwbug|6 years ago
Thanks for sourcetrail.
srikz|6 years ago
franga2000|6 years ago
So here's my question: how do we avoid that? Outside of freelancers who control their finances directly, most developers probably won't be able to convince their company's money people to pay for something they can get for free. Paying a relatively low annual license can usually be justified for the sake of efficiency, but "donate to the devs to keep the project going" is a much tougher sell.
My only idea is selling a "subscription" to signed binary builds under a non-free license, but I'm not sure that would work very well either...
pimterry|6 years ago
I'm building & selling a 100% open-source product myself (https://httptoolkit.tech) funded by a paid but still open-source premium tier, and I also have a popular open source library (https://github.com/pimterry/loglevel) funded by donations via tidelift: https://tidelift.com/subscription/pkg/npm-loglevel.
So far, with far fewer users, the paid tier is a _dramatically_ more effective option: it makes nearly $1000 a month, and increasing, while donations make $50 a month. The latter library is a small package, but it is a small package that's installed 6 million times a week, so there's a huge volume of software depending on this. The former app has a few thousand monthly users but similarly isn't something that your whole business is typically going to revolve around, it's just a useful tool.
Imo, unless you're huge or you're going to become a really fundamental part of people's business, donations aren't going to work. Small libraries or occasional-use tools just won't get there. If you're webpack it's great, and I do think it's super valuable for those cases, but most projects aren't webpack.
However for almost any tool you can separate the power user/enterprise features from the basic features, and then put the former behind a simple paywall. It can remain open source, so the determined can fork the whole project and remove the paywall easily if they prefer, but for any large organisation that doesn't really make sense from a time or ongoing cost perspective, and you either miss out on all future development, or you have constant work to merge upstream changes with yours. Alternatively, you pay $10 a month and the problem goes away.
So far so good, and it feels like a win-win. Hard to translate to libraries I think, but there's interesting developments here like https://gitroyalty.com/.
anigbrowl|6 years ago
01100011|6 years ago
Roritharr|6 years ago
coziestSoup|6 years ago
bachmeier|6 years ago
jclay|6 years ago
I appreciate the retrospective on the hurdles you faced. Could you share some learnings for things that did work? I could tell you spent a lot of resources getting the onboarding flow correct (Visual Studio Project Import was nice!), anything related to onboarding-related learnings you can share?
egraether|6 years ago
You cannot convince developers to use a tool with just words. They need to experience the benefits first hand. And getting to the benefits should happen as fast as possible after starting to test the tool.
JoachimS|6 years ago
m463|6 years ago
You also tend to compete against free tools (either via licensing or vendor-giveaways)
gwittel|6 years ago
For others, I suggest giving it a try. The only issues I’ve run into is when a project has a build setup that won’t work on your machine. It still works, you just can’t dive as deep.
guruz|6 years ago
It's with open source but not free software: https://github.com/woboq/woboq_codebrowser/
randoramax|6 years ago
What do you mean?
hoistbypetard|6 years ago
[1]: https://langserver.org
xvilka|6 years ago
[1] https://github.com/CoatiSoftware/Sourcetrail/issues/750
[2] https://github.com/github/semantic
lstamour|6 years ago
If indexers were to be maintained separately, the only thought I have is something based on an IDE like Eclipse or IntelliJ, or something based on SourceGraph. To that end, I think open sourcing will do more to support usage, and usage would drive further licensing/support...
It’s possible there could be add-ons sold to help refactor code or maybe a web-based version, perhaps merging with SourceGraph as a client? Or use in code review? Lots of possibilities, perhaps, just not easily/quickly commercial I would think without further development first.
agambrahma|6 years ago
Sad to see that it didn't make it as a commercial product (wonder what lesson to draw from this ...)
hoistbypetard|6 years ago
khalidshaikhmo|6 years ago
unknown|6 years ago
[deleted]
fleur-de-lotus|6 years ago
Jahak|6 years ago
senthilnayagam|6 years ago
sjwright|6 years ago