An update on our 2020-2021 roadmap
Exactly one year ago, we announced our plans for the upcoming year. Let’s look back and see how we’re doing.
When we announced the roadmap, we focused on a few key areas that we wanted to improve. While on some of these, we’ve managed to deliver, on others we’re not there yet.
- We’ve done a ton of work when it comes to Documentation. Our technical writer Andrey Aksenov deserves a lot of credit for mostly single-handedly not only rewriting many parts of the documentation, but also working on restructuring, and addressing new issues as they come in. Documentation however is an ongoing task, and we know we still have tons to do, especially documenting the API itself.
- We’ve done quite a bit of work on simplifying the API, both for usage and extensibility. Most of these changes will be apparent in 2.x, as they imply breaking changes.
- We’re currently working on improving testing to allow for better coverage of real-world scenarios.
For 2.0 we expect to have all the above ready, pending two main areas which still need addressing: client/server parity, and deployment. We aim to get these mostly done before the end of the year. Remember, if you want to try some of these things out, you can already under our EAP program.
Ending this roadmap in December does mean that we’ll be about 5 months behind schedule, but we believe all these areas are very important and the building blocks for what’s to come. As such we don’t have plans to change focus. The silver lining is that our next roadmap will align with the natural year, which believe it or not, makes things somewhat easier!
Commitment and Stability
We adopted semantic versioning, and by and large it seems we have not messed up much in this area, except the occasional bug that may have creeped in and broken some backwards compatibility. In regard to our commitment of frequent releases, we have been releasing at a minimum a patch fix every month, as well as two minor (1.5 and 1.6) releases since August 2020. We’re aiming to release 2.0 hopefully by October.
We also hired a full-time support engineer that continues to provide support via our official channel which is StackOverflow. By the way, either via comments or the survey, do let us know if you think a different channel is needed.
In terms of tooling, we seem to be on course. We have completely rewritten the plugin from scratch, providing a smoother experience for setting up new projects. We have already started adding more functionality such as intentions, navigation, et al. to the plugin, and recently launched the new revamped project generator.
The plugin is now released with the new EAPs of IntelliJ IDEA and moving forward will be bundled with the product .
We’d also like to say a few words on our decision to provide support for IntelliJ IDEA Ultimate. When we announced the new plugin, we also highlighted that it would be available exclusively for IntelliJ IDEA Ultimate. While the vast majority of folks were fine with the decision, there were a few people that were somewhat upset by this move. We understand their opposition, but we want to reiterate the reasons for it; firstly, it is consistent with other frameworks we provide support for, such as Spring (Boot), Micronaut, et al. Secondly, we believe that OSS needs to be sustainable. Ktor will remain open source and free, but for us to be able to do this, we need to find a revenue model which works. For us, this is tooling.
Ktor Annual Survey and Job Openings
Last year we ran the first annual survey, which helped us greatly shape (and validate) our roadmap. It also highlighted the issues folks had and allowed us to concentrate on addressing them. Yesterday we launched our second Ktor Annual Survey. We’d really appreciate it if you could take 5-10 minutes to fill it in.
Lastly, if you like Ktor and want to help, we have a few positions open. We’d love to have you join the team!