Things I wish I’d known before creating Web3j

When I created the Web3j library for Ethereum, I had the naive worldview that creating a successful open-source library would naturally transition into a commercial success. Nothing could be further from the truth. Recently Web3j passed the 7-year-old mark. To mark this momentous occasion, here are 7 things I wish I’d known before I started the library.

1. Monetising open source is hard 

Open source software (OSS) is no different to any business venture in this respect. Finding a solution to a problem, and a solution to a problem that people are willing to pay for are two different things.

The open-source software movement has been a victim of its own success. Programmers don’t expect to pay for software they use to develop applications. 

If you can demonstrate how an application you’ve built with open-source software solves a problem, then you can charge for this. But if your target audience is developers, as is the case with Web3j, it’s hard to get them to pay for the software on its own. 

Two common models we see with commercialised OSS are the open-core model and hosted deployment models. 

The open core model is more applicable to enterprises as they deploy software themselves and have the appetite for paying for additional integrations such as single-sign-on capabilities. 

Hosted deployment models are by far the most popular approach, where OSS is made available as a SaaS platform. This model works where you have a stand-alone technology such as a database or analytics platform, whereby you host the software on behalf of organisations, who pay you for this service.

The Business Source License is not an open source license, but a source available license which allows anyone to view the code. However, it cannot be run in production without the explicit approval of the creator. 

The decisions by Hashicorp and Uniswap to embrace BSL demonstrate just how challenging monetising true open-source software is. 

Often projects end up reliant on grant funding to keep them going. This has been the case with Web3j, where we fund some of the development through the commercial activities of Web3 Labs, but have also received a number of grants for the project. 

2. It’s great for opening doors

Creating useful OSS is a great conversation starter. It gives you something to present at conferences, write articles for and just talk about with people. 

Having a project you can permanently have your name associated with as creator makes you stand out from other developers as there’s a very public place where people can see your work. 

It can also lead to opening doors with new customers for other types of work such as consultancy, or invitations to conferences. 

One of the most remarkable things that happens is that you often meet people at events that have used your software. This has happened countless times for me with Web3j, speaking with both startups and large enterprises! 

3. People won’t tell you they’re using it

The best metric of success for OSS is lots of downloads but not lots of bugs. If people are using the software and it just works, they won’t tell you that. 

They’re most likely to get in touch when there’s a problem with the software and they need to create an issue against the project. Or if you’re lucky, they submit a pull request to add new features or fix bugs improving the software for everyone. 

With Web3j on a number of occasions, we have done our own research to see who’s using the project. Sometimes it entailed examining Android binaries, and other times searching GitHub and software release repositories. We had to get creative. 

But it gave us useful insights into where it was being used. 

4. Companies love consuming it, but don’t expect them to pay for it

It’s stating the obvious, but no one expects to have to pay for free software. Most users of OSS have an expectation that issues will eventually be fixed as no one wants to leave bugs in their software. 

Depending on your target for the software, you may have a number of companies using it too. They will often be even more tight-lipped about their usage of it than users due to their commercial nature. 

When they start using your software in production, they may decide that they need a professional support agreement to cover it. But this is in the minority of cases. 

Most companies will consume your software and give you a pat on the back or high-five as a thank you. This isn’t a bad thing (see the previous point about opening doors), but it is important that you appreciate that just because a big name is using your software, it doesn’t mean you’ll profit directly from it. 

5. The development is the easy part, promoting is hard

There are few things more satisfying than greenfield development. Where you create a project and are writing all of the code from scratch. 

Most of the time, developers are importing other libraries or frameworks to do the groundwork. But it’s incredibly invigorating when it’s you and your laptop churning out software from scratch to fulfil your vision.

Unfortunately, this part of the process doesn’t last long. As soon as you put your first release out, you need to figure out how to get users. 

This doesn’t happen without letting people know about your project — the problem it solves and how to use it. You need to start writing documentation, blog posts, and giving talks, as well as sharing it with communities on Reddit, and figuring out SEO and other things. 

This takes time and is a never-ending process. You have to start selling or marketing your project to get users. It doesn’t matter how good the code is, without this effort, it’s unlikely anyone will ever find it.

You need to find time to do this and keep doing it! 

6. Keep the project focused

It may be tempting to expand the project by creating spin-off projects. I did this with Web3j where I created additional projects for generating OpenAPI endpoints for smart contracts and support for additional frameworks such as Spring Boot. 

The challenge with this was it increased the number of projects I needed to maintain and support. At the time it was tempting to expand the project as there was grant funding available to do this. But in the long term, it meant that there was even more work to do maintaining these projects. 

If I was back in this situation, I likely would have focussed on sharpening the documentation and fixing more of the bugs instead of trying to expand the project prematurely. 

7. Be prepared to commit to it for 10 years

As anyone who has run software in a production environment knows, once it’s out there it has to be maintained for the long haul. This is very much the case with OSS. There’s little point in creating an open-source project and walking away from it after a year or two unless there are zero users. 

Software is like a child that you need to nurture and support for the long run. It’s important to think seriously about how long you’re willing to commit to it. 

Perhaps I’m just stubborn, but I do think you need to be prepared to invest in it over a 10-year time horizon.

If you’re not willing to make a serious long-term investment in it, perhaps it shouldn’t be created in the first place as a public good. 

What’s the real reason for creating it? Be honest, is it solving a real problem for people or is it a vanity project you want to use to boost your own profile? It’s okay to be doing it for vanity reasons, provided you’re prepared for the commitment it entails.

Start with why

The decision as to whether to start an open-source project isn’t one to be taken lightly. Commitment aside, it’s important that you appreciate the underlying reasons for why you are doing it. When I first wrote Web3j, being aware of the things I listed above would have helped me. I’m sure the library would still exist, but it would have made me question the path I was planning on taking further before I embarked on the journey.