Rosie Purpose and Future
With the recent release of version 1.2.2, it seems like a good moment to talk about the future. We are making plans for a version 1.3 and, eventually a “Rosie 2.0”. In this post, we’ll first look at the use cases for Rosie/RPL and then what’s coming in Rosie v1.3. We’ll save the topic of “Rosie 2.0” for a future post.
The Rosie Project, and the RPL language, were initially developed at IBM. After roles in product architecture, technical strategy, and technical standards, I found myself on what we called an advanced technology team. That was a fancy name for a fun job: looking at tech trends and building prototypes of whatever we thought might be important to IBM’s software business over a 1-3 year time frame.
Our research division often focused on longer time horizons, and of course product development teams had very short term goals. An advanced tech team was a way to bridge the gap. For instance, when Docker was new, I figured out how to package some of our WebSphere products in Docker containers. By doing this well before any customer asked for it, we could consult with other IBM business units about how their products would or wouldn’t work in a container, as well as advise Tivoli (IBM’s system management brand) on how to manage container deployments.
Back to Rosie! Around 2015 or so, my advanced technology team was building a prototype product for IBM cloud, which would (ideally) give actionable feedback to development teams about their process. Our aim was to use machine learning to generate suggestions about what code should be reviewed, where team agility or communication was suffering, and even where future bugs were likely to arise.
