I am happy to announce that all our founding members agreed to turn Sourcetrail, our cross-platform source explorer, into free and open-source software. The source code is now available on GitHub and we aim to fund further development and maintenance via Patreon. In this post I will explain the issues we faced with commercial licensing and why we think this change will improve the situation and benefit everyone.
A Quick Introduction for Newcomers
Sourcetrail is a cross-platform source explorer that helps you get productive on unfamiliar source code. It uses static analysis on C, C++, Java and Python source code and lets you navigate the collected information within a user interface that interactively combines graph visualization and code display.
For more information:
- Watch our Introduction Video
- Read on our blog why we started building Sourcetrail
- Watch one of my talks on Software Visualization: C++Now 2018, ACCU 2019
Information for Existing Commercial License Owners
Abandoning our commercial license model is not only a big step for us, but also for our customers. We highly value our relation to all of you and want this change to benefit you as much as possible. If you own a commercial Sourcetrail license, you should already have received an e-mail informing you about this change. We already received lots of positive feedback, however there were also concerned voices wondering how things will continue.
For the moment there won’t be any major changes:
- We will continue our quarterly release cycle.
- We will continue to fulfill our obligation to provide customer support for as long as your “Sourcetrail - Commercial User License” qualifies for it.
We hope that you don’t regret spending money on a Sourcetrail license, even though you can use it for free now. Please rest assured that your funding was of great value to us. Without you the tool would not be where it is today. Still, there were not enough of you to adequately compensate our work. We hope that you will consider to continue supporting us on Patreon after your update period ends.
Thank you for your support!
Our Journey with Commercial Licensing
Sourcetrail (aka. Coati) was initially developed as a Master’s degree project at Salzburg University of Applied Sciences with a team of four software developers and one graphic designer. By that time each developer on our team had already worked on a couple of large software projects and from that experience we knew how hard it is to become productive on an unknown codebase as a newcomer (read the full story here).
We managed to build a rough alpha version and felt that this project had a lot of potential: Sourcetrail can accelerate a new developer’s productivity on a project. And even after theon-boarding phase, reading source code stays a relevant part of the daily work of a software developer. We had the vision for Sourcetrail to become the go-to developer tool for reading and understanding all sorts of unfamiliar source code.
Initially we received a couple of public grants that allowed us to launch Sourcetrail publicly. We decided to go down the traditional road of selling software licenses to sustain further development. Of course that meant to keep the code private if we wanted to protect our business.
In retrospect, this decision really narrowed down our user base, making it hard for developers to start using Sourcetrail for multiple reasons. The issues those developers faced can roughly be grouped into three major areas:
Not every developer recognizes Sourcetrail’s advantages
After our launch it quickly turned out that the majority of software developers doesn’t see the advantages of Sourcetrail at first glance. Some just need an introduction to get sold on the concept, others need a first real use-case where they experience the benefit of Sourcetrail first-hand.
Yet some seem impossible to convince to spend time learning a new approach for reading code. After all, we are all creatures of habit: Never change a running system. So it’s always hard to pick up a new way of doing things.
In summary: It is a rather big disadvantage for a small company to sell a product where the supposed value is not immediately clear to each user.
Not every developer agrees to Sourcetrail’s commercial licensing
We didn’t know this right from the start, but developer tooling is a pretty tough business. Actually the ‘toughest kind of software business’, as I was told by other founders and investors. Based on our experience I assume this is caused by a combination of factors:
Abundance of free tools
Lots of developer tools are free. And this is a great thing: It means that building software is not restricted by a pay-wall. And let’s be honest about this, it also means that we as software developers would rather evaluate and use a free alternative than a commercial tool. Unless the commercial tool has been recommended to us by a trustworthy source. And turning this around: we would rather recommend a free alternative than a commercial tool. So it is really not looking good for commercial tools here.
Weighing up costs and benefits
If we decide to buy commercial software, we usually judge the price to be high or low depending on our own budget. But for developer tools, we should actually judge the price by the costs we would save. Employing a software developer costs multiple thousand Euro/Dollar each month. Some employers are aware of this. They understand that buying hardware and software to make their developers more productive can actually save them a whole lot more than they are spending. But if we have to decide, looking at a price tag we often don’t see it that way.
Management hurdles
Usually management doesn’t decide to buy us new hardware or software just out of the blue. If we want to get new stuff, we have to convince management. And this can be hard. Sometimes we simply fail to convince our direct superiors. Sometimes management delays our request indefinitely, because the requested purchase is not essential to get the work done. And sometimes the purchase even gets stopped by the legal department for whatever reason. Over the years I saw developers that were happy with Sourcetrail fail in every single one of these steps.
Not every developer can use Sourcetrail on the desired codebase
Finally, whether we as developers are actually able to successfully apply Sourcetrail at our daily work, depends on a couple of factors:
Language Support
Does Sourcetrail actually support the programming language we use on the current project? So far Sourcetrail supports C, C++, Java and Python. That covers around 40% of all professional software development, but this could certainly be improved upon.
Build System Integration for Project Setup
As a developer we usually don’t want to spend a lot of time configuring our tools. Thus, Sourcetrail should be able to reuse the project configuration from our build system. Sourcetrail tries to support easy setup for the most common build systems, but doesn’t support them all.
Many companies also use self-made build systems, so developers have to resort to manual Sourcetrail project setup. This can cause quite a lot of frustration, since not all of us are too familiar with all the flags and paths necessary to successfully build the project at hand, especially newcomers that would benefit the most. It takes time to gather all necessary configurations and a lot of us simply don’t want to deal with this.
Scalability
While Sourcetrail manages to deal with projects of multiple million lines of code now, there is certainly some upper bound to this. If projects reach a size of close to or above 10 MLoC, Sourcetrail’s indexer will often simply be too slow or run into memory issues. And even if the indexing is successful, the user interface may be really slow as a result.
Cross-platform Support
Even though Sourcetrail is maintained and tested on Windows, macOS and Linux, cross-platform support still causes a lot of issues. Especially Linux with all its different distributions and flavors poses quite a lot of challenges. Certain issues just appear on a certain distribution, which could also be caused by some customization of the specific user. Issues like this are very hard to reproduce and fix without access to the respective system.
A Change of Plan
We have been going back and forth, discussing and testing potential solutions to many of those issues for a long time now. Many of our thoughts revolved around how to make more money and use it to solve those issues. Looking at other companies in the field, it seemed that to make more money, our only option was making our licenses more and more expensive, which in turn would limit our audience to fewer developers. We always dismissed the idea because we started to make Sourcetrail to benefit as many developers as possible and not to be a premium product for a few people in a handful of companies.
A few weeks ago we sat down again, looked at all the issues we faced and spent some time playing with the idea of going open-source instead. When playing it through, we saw that it would immediately solve a lot of our issues. If we eliminate commercial licensing, any developer can start using Sourcetrail without accepting terms, spending money or convincing management. Moreover, satisfied users may have less reservation to recommend Sourcetrail to other developers. It would allow everyone who has an issue preventing him or her from using Sourcetrail on the desired codebase to fix that issue. From past experience with our open-source code editor plugins we know how great it is when people chime in randomly, suggesting improvements, discussing questions or even fixing issues. Usually they have a different background than we do, so they have expertise that we cannot provide.
With these issues addressed, the diagram from above would now look more like this:
The only thing that kept bothering us is that open-source projects in general have a tendency to decay if no one has the time to actively maintain them. Over the last couple of years we have acquired a lot of knowledge about Sourcetrail’s codebase and all the expertise that was necessary to create it. So we feel that it would be a waste of knowledge to simply move everything to an open-source repository and walk away. We recently saw other projects that successfully financed even full-time work by setting up a Patreon page. Patreon would make it transparent how much compensation we are receiving and with the respective goals, patrons would see how much time we can put into this project. We think this would be an ideal model for us!
Becoming free and open-source software
We talked this plan through with all of our founding members and every one of them agreed. Two weeks ago we met and everyone put down the signature. We decided to go with the GNU General Public License for Sourcetrail, as this is a viral license that ensures that every modification or improvement of Sourcetrail will stay free software.
Today we are proud to announce that the product of five years of work is now freely available to the public on GitHub.
The repository is based on our previous public bug tracker, so all open issues are still in place. Please take a look at the README for information on how to build Sourcetrail, enable support for different languages, become a contributor to the tool or even work on new language support.
As I mentioned earlier, we aim to fund further maintenance and support via Patreon. Please take a look at the goals we defined, which show how much work you can expect from us on different funding levels. We added tiers for individual users and also offer sponsorship tiers for companies.
We hope that you are happy about our transition to open-source and will consider supporting us!