Oskar Dudycz

Pragmatic about programming

I'm no longer Marten maintainer

2024-03-29 oskar dudyczEvent Sourcing

cover

Folks, I’d like to inform you that I’m no longer a Marten maintainer. As you know, sometimes in the project’s lifetime, there’s a moment when either you need to settle things or make hard decisions. Unfortunately, the latter occurred here.

I’m not happy that this is ending not as I hoped. Marten was a big part of my life: over 6 years as a contributor and over 5 years as a co-maintainer. Still, I’d like to thank Jeremy Miller and Babu Annamalai for our past collaboration. I think that we managed to build a unique tool. I’d also like to say big kudos to the Marten community. I always said that’s one of the big reasons that motivated me on this path.

For various reasons, I already wasn’t active in the final push for the v7 version, which is a significant milestone. I think that shows that the team is motivated to keep it going.

I’m not leaving the Event Sourcing and Event-Driven space. I’m planning to continue what I was doing, so if you need any help from me, feel free to reach out to me.

The closest goals are the workshops on Techorama and DDD Europe. Then, I’ll think about what’s next and how much I need to adjust my course.

This blog is also a chronicle of my journey, I will finish it with a few stats and dates.

As mentioned, I was Marten’s:

  • User for over 7 years. I’m not sure of the exact date, but I started my EventSourcing .NET samples to learn Event Sourcing and Marten. First commit was on 28th January 2017, so it had to be a bit earlier than that.
  • Contributor for over 6 years. I opened my first pull request to Marten (and in general to OSS ever) on the 6th of August 2017. We were missing asynchronous apply methods in projections, so I thought, “let’s try to do this OSS-thing”. It was merged on the 1st September 2017. Funnily enough, eventually, we didn’t use this change in our project as we were using it to load additional data while updating read models, which is not a great practice in general. But, well, we all need to start somewhere.
  • Maintainer for over 5 years. It happened officially on Jeremy’s blog on 27th September 2018. I was already active on our Gitter, so I am sending more Pull Requests. Jeremy invited Babu and me to join the core team, and we agreed.

During that time, I’ve made:

  • 146 Pull Requests,
  • 592 Commits,
  • 214724 Additions,
  • 149,399 Removals

Plus also work on Weasel, spinoff for schema management:

  • 23 Pull Requests,
  • 90 Commits,
  • 12051 Additions,
  • 10010 Removals.

Being 2nd most active contributor (both in this period and in general).

screen

If we exclude the last three months when I wasn’t very active code-wise, then even on 1st. Of course, those are just code output stats; they don’t show the quality or importance of contribution, just activity. Ultimately, they’re just fun/dumb statistics for a chronicle like this.

screen

We’ve built the Discord community for 1235 members (at the time of writing).

We joined as one of the first .NET Foundation in March 2020. And we left it as one of the first in February 2022.

I’m not happy about the ending, but I don’t regret the journey.

Something is ending, something is starting. Off we go to the next chapter.

Cheers

Oskar

p.s. Ukraine is still under brutal Russian invasion. A lot of Ukrainian people are hurt, without shelter and need help. You can help in various ways, for instance, directly helping refugees, spreading awareness, putting pressure on your local government or companies. You can also support Ukraine by donating e.g. to Red Cross, Ukraine humanitarian organisation or donate Ambulances for Ukraine.

👋 If you found this article helpful and want to get notification about the next one, subscribe to Architecture Weekly.

✉️ Join over 11500 subscribers, get the best resources to boost your skills, and stay updated with Software Architecture trends!

Loading...
Event-Driven by Oskar Dudycz

cover

Through my window, I see the result of good plans but poor execution. Opposite my flat, there is a partially completed construction place. Buildings were supposed to be eye-catching Mediterranean style apartments. Delivery date? Two years ago. Actual? More and more unknown.

Some time ago, I heard that using Event Sourcing makes creating Event-Driven Architecture easier. The arguments were correct, that if we’re already publishing events to trigger business workflows, then at some point, we may want to also store events to not lose information. Agreed. However, I also heard that keeping the state as events will simplify things. We’ll have a source of truth with a record of the system behaviour. This will allow, e.g. to confront the results of the operations with the recorded state. I’d agree with that, with one distinction. It’s easier as long as you already know Event Sourcing.

Many people in the DDD community claim that the essential is to properly break down the system into autonomous parts called bounded contexts. Once we have it, the rest is secondary and will sort itself out. For sure.

Many seasoned programmers speak similarly about new technologies. They claim that they can translate past experience into new technologies. That’s true that by analogy, they can catch the big picture quicker. But isn’t it a bold assumption to say that Win.Forms specialist will learn Angular quickly?

The end result may differ a lot from the initial ideas. I saw the plan of those buildings next to me. Now I can see the effects of the execution. Or actually, the lack.

I believe that we should carefully acknowledge not only the point of view of our authorities but also their seating point. If we want to find out how to form a wall, do we ask an architect or a foreman? An architect may know the theory, but the practice is what we’re looking for. On the other hand, if you want to know where to put the wall, you prefer the architect to do measurements. At least if you don’t want to have the roof falling to your head.

After I had torn a ligament in my knee, I went to two qualified orthopedists. One said I should have surgery and do a reconstruction. The second stated that there is no need for that; rehabilitation should be enough. Guess which one had a specialization in surgery and which in rehabilitation?

People usually give us advice from the point where they’re currently standing. They are entitled to a biased view. An architect who rarely does programming will tend to downplay the value of implementation and tactical patterns. Midlevel developers will focus on technicalities instead of the global system impact. The team manager or consultant will emphasize the importance of soft skills (or esoteric techniques known only to them).

The truth is that we need all of them. The excellent plan will fall on the bad execution. The best execution for the wrong case will be just a waste of time. We should carefully evaluate the advice considering what we need and what an expert can give us.

Therefore, when we’re reading an article, watching a talk, let’s also pay attention to the place where the person is standing. The perspective from there may be much different from where we are right now. That can be good, as it may push us in the right direction. But it may also be misleading, as we accidentally take biases of this person without understanding the tradeoffs. Personally, I prefer to follow not only people from pedestal but also those that are closer to my position. A bit further in the journey, but not too far. That helps me to calibrate my view as those people are more relative to my daily struggles.

Polish historical leader Józef Piłsudzki reportedly used to say: “Right is like an ass, everyone has its own”.

Cheers!

Oskar

Event modelling anti-patterns explained

Testing Event Sourcing, Emmett edition