I’m pleased to announce that Guillaume Laforge, well-known Java Rock Star, and project manager for Groovy, has joined Restlet to help accelerate the evolution of API tools that are critically needed by software developers.
The Groovy ecosystem and community are extremely vibrant. In 2014, Groovy was downloaded 4.5 million times. Restlet plans to use Groovy technology to improve our API development tools, including APISpark, Restlet Studio, and Restlet Framework. Guillaume’s experience with the open source development community will also benefit the active community around Restlet Framework.
With the explosion in the number of REST APIs in the cloud, we’re seeing rapid change to both API tools and API languages such as Swagger, RAML, and API Blueprint. We expect even more rapid change in the future, including a stronger connection between API languages and programming languages for different roles.
I’ve known Guillaume for about 10 years and have been highly impressed by his technical achievements in the open source world as well as his ability to grow a vibrant developers community. He has already been very helpful to the Restlet community in the past, initiating our discussions with Manning that led to the publication of the “Restlet in Action” book.
Of course, there are many questions from the community about Groovy and the role that Guillaume will have at Restlet. He’s responded to a some of these questions below. If there are any additional questions, comments or feedback, please Tweet them to @restlet.
Welcome on-board Guillaume!
Jerome Louvel, Chief Geek
Guillaume Laforge, Restlet’s new Product & Developer Ninja
Q: Why did you join Restlet?
With Pivotal divesting in the Groovy and Grails technologies, I started thinking about big, new challenges I could tackle. I wanted to apply Groovy to concrete use cases and sharpen new skills. The world of APIs is active and promising. I’ve always been interested in that topic. When Jerome Louvel invited me to join Restlet, I thought it was a great opportunity.
There are some interesting ideas to experiment with at the border of API languages and technologies, where Groovy could be put to good use within the Restlet Framework, Restlet Studio and APISpark.
To add a bit more depth to the link between the world of APIs and languages, I’ve in particular seen Groovy used in situations where a programming language needs to be used to orchestrate the APIs programmatically. For instance, that’s what Alcatel-Lucent’s PaaS is doing, or what PayPal does too. Netflix are also a big fan of Groovy for their APIs, as demonstrated with their recently open sourced Nicobar project, or their dynamic scripting platform.
Q: What will your responsibilities be at Restlet?
There are different topics I’ll be working on, including product leadership (setting the roadmap for our projects, interfacing between marketing, engineering, our thought leader, etc), as well as taking advantage of my long developer advocacy experience to foster a nice and lively community and ecosystem around our projects and products.
Q: With your new role at Restlet, what will happen to the Groovy project? What will your involvement be?
I’ll continue to contribute to Groovy, although not full time as I used to do, as I’ll have a lot to work on at Restlet.
Q: Do you think API languages like RAML, Swagger, API Blueprint need to evolve in order to gain wider use?
I think there’s common ground between all these API languages. They all have pros and cons. These days, I often hear more about Swagger perhaps than the others, and it’s a compelling solution.
Ultimately, my gut feeling, with my experience in languages, makes me think that perhaps it’s still a bit of a too static a view of the world. Perhaps a bit of a programmatic approach to those API languages could bring them functionality that mere declarative approaches can’t. But on the other hand, that’s already beyond the 90% or more of the most common use cases.
But with my language hat, it’s definitely a topic I’ll be thinking about more thoroughly in the future.
Q: What is the size of the Groovy community?
The indicators I tend to follow more closely is the number of downloads: with 1.7 million downloads in 2012, 3 million downloads in 2013, and 4.5 million in 2014, that’s a pretty healthy and active project, used in tons of various and interesting contexts.
It’s always difficult to give the size of the community of an Open Source project.
I think there are about half a million Groovy developers out there.