- Get the most out of open sourcing your software!
Get the most out of open sourcing your software!
Suppose: you have written a piece of software to solve a problem. Why would you keep this to yourself, instead of sharing it with the entire world? Roel Spilker, developer at TOPdesk and one of the authors of Project Lombok, explains how open sourcing their project helped them get a lot of users.
How did you start with Project Lombok?
We are big fans of the Java programming language, but we are no fans of boilerplate code. Boilerplate code is required by the programming language, but you don’t want to see it, since it obfuscates your code. Project Coin was a project, sponsored by Oracle, to implement changes in the Java language for Java 7. Suggestions to reduce boilerplate were not picked up, so we started on our own project.
We started with the @Data and related annotations and integration of our project with the current Integrated Development Environments. Without a good integration we would not get a widespread adoption of Project Lombok. Another goal of Project Lombok is to make it easier for developers to write good, compact code using modern paradigms and programming patterns.
From the start we wanted to open source Project Lombok. We put our code on GitHub, tracked our issues with Google Code, had a mailing list on Google Groups and we had a webserver for our project and documentation pages. Everything is publicly available and we invite people to contribute with a “Fork me on GitHub” banner on our project pages. We provide easy Ant and Ivy scripts so contributors can easily start contributing.
To verify external contributions to Project Lombok, we have spent a lot of effort to write end-to-end tests. These test also serve as documentation.
Why did you choose to open source Project Lombok?
We want to be open to input from the Java community, be it code through pull requests or feedback. We also want to enable other people to experiment with Project Lombok, for example by creating extensions. And this works: we have received multiple contributions and besides pull requests, we even have some external committers as well.
Other benefits we attribute to being an open source project:
- Easy adoption by users: it is free, customizable and trustworthy since the sources are open.
- It helped get a positive vibe in the media; Project Lombok is featured on the JavaPosse, blogs, articles, Devoxx presentations, Java User Groups, and more.
- Many people have heard of it, so it makes a great subject of conversation to get to know other people.
Do you also see a downside to Project Lombok being open source?
Giving support to our users can take up quite some time. Especially incomplete bug reports, or duplicate features requests. Since we don’t get paid, we sometimes find it hard to find the time to answer.
Another downside is that we have a wide range of tools and platforms to support, like Java, Eclipse, Maven, Gradle, other Java Virtual Machine implementations, other IDEs, etcetera. If Project Lombok would have been closed source we might have permitted ourselves to say ‘no’ to some tools or platforms. And we might have been more focused on the tools we do support, to keep more up to date.
A last, small downside is specific to how Project Lombok works. Some of our code is not code to be proud of. It does not adhere to our otherwise high code standards, and should not serve as an example. But for some of the tricks that Project Lombok employs to provide its features, we have no other choice but write not-so-clean code.
Do you have some tips and tricks for people who think about open sourcing their project?
Stay true to your idea and your vision. Be prepared to disappoint people. People who disagree with you will be more vocal than those who agree.
It is important to communicate openly and timely. Close issues as soon as possible, and let people know if you won’t or can’t fix the issue. Dare to deny feature requests. If the features are important, they will pop up as feature requests again. Respond to emails. Be especially swift in giving feedback to external committers or pull requests.
Do not be ashamed of your code or your solution to a problem.
Make sure you choose an appropriate license from the start of your project. If you want to change a license afterwards, you need approval of all committers. So make sure you have the name and email address of all committers. See for example the AUTHORS file in the Project Lombok repository.
Ensure to have and expose as few external dependencies as possible. Don’t send users of your project into a dependency hell, wherein different libraries use different, incompatible versions of the same dependency. Shade your dependencies using JarJar or the Maven Shade plugin.
What are your current development stack and tools?
License: MIT license
Issue tracker and revision control: GitHub
Communication platform: Google Group email list
Testing framework: JUnit
Build processor: Apache Ant
Dependency management: Apache Ivy
Bootstrapping and configuration of IDEs: IvyPlusPlus
Distribution: The Central Repository
TOPdesk believes in giving back to the open source software community. We regularly contribute to open source projects, like JUnit Lambda. Developers are stimulated to spend their apenkooi-time* to create, explore and contribute to open source projects.
* To grow professionally, a software developer at TOPdesk can spend 10% of their time on projects unrelated to their daily job.
> Lombok mentioned as one of the fantastic four in 2016 on this blog!
Popular postsTime to redefine: How DevOps is taking us from chasing waterfalls to continuous delivery
Viele unterschiedliche Kollegen = viele Ideen
Get the most out of open sourcing your software!
Test Team ≠ Testing Community
Deine Bewerbung bei TOPdesk
Meet TOPdesk Development
TOPdesk third place in Best Employer survey 2015
“Apekooien” at Development (10% time)
Sharing knowledge at International Development Meeting
Build a high-quality product