anchor.diff:  
   When I think of the Kafka and Debezium ecosystem, the next steps I consider important are the ones which will make it more accessible. Although there's a lot of content and examples online, there's still a big gap between reading those and getting to a production ready implementation.
   
  -What I mean by that is abstracting the individual pieces away and giving them more meaning. The Outbox pattern is a good example, it was not natural for people to think of CDC and know that it was such a good match to it, there are plenty of more use cases to be explored in this ecosystem.
  +What I mean by that is abstracting the individual pieces away and giving them more meaning. The outbox pattern is a good example, it was not natural for people to think of CDC and know that it was such a good match to it, there are plenty of more use cases to be explored in this ecosystem.
   
   What if you could have everything out-of-the-box? An outbox implementation in your favorite framework, which knows how to integrate with the ORM, handle the transaction part, then, how to shape the messages and events? How to adopt the schema for it and how an evolution of it looks like. After that, getting closer to the consumer implementation, how can I handle the messages idempotently, respect the semantics, do retries and project them to a database if need be?
   
  
positive.code: *Figure 1. The configuration file in LDS; a developer will open a PR adding a new line, the rest will be taken care of.*
  ====
  
  Upon merging the PR, our project will provision the whole configuration to Kafka Connect, ensures the snapshot is executed, metrics and presents and etc; We've done the same thing for the Outbox pattern and I talk a little bit more about it in this https://twitter.com/renatomefi/status/1185098904745992197[tweet thread].
  
  Self-servicing the teams was a great way to remove resistance for adoption, no Jira tickets were necessary, no advanced ops knowledge or anything else to get it running. The other factors I consider to have contributed to Debezium's success in our platform is its reliability and straight forward value perception, in those 2 years we never had major outages or critical problems of any kind!
  
  
negative.code: 
  I want to take the opportunity here to mention how helpful the Debezium community was for getting me started with contributing. As I showed the intent to work on this, they were super welcoming and we had a call about it, so I quickly felt productive working on the code base
  
  Almost immediately after the conversation I started a technical draft (which you can see https://issues.jboss.org/browse/DBZ-1169[here]) and soon after the first implementation was done. I can almost certainly say we were the first ones to run the transactional outbox pattern powered by Debezium. I was running a custom build on our platform, which then finally became the official https://debezium.io/documentation/reference/1.2/configuration/outbox-event-router.html[outbox event router] you see in the Debezium docs today.
  I was lucky to be there at the right time and with the right people, so thanks again to the Debezium team for helping me throughout the whole process of drafting and making it happen!
  
  Will I do more open source? Yes, but I must say most of my open source activity is "selfish", I'm developing solutions to problems I face at work but I'm happy to take the extra step and make them to the OSS world, but it also makes it seasonal. One of the advantages to that is if I'm doing something for a project, be sure I'll make it to production and likely be able to find more corner cases!
  