Don't do it obligatorily (for me, at least, that makes it a chore and it looms over me)
Avoid commitment (the idea of releasing an open source thing is exciting, but maintaining it over time is high cost, low appreciation -- even abuse, and doesn't stand to offer you much).
The simple obvious thing you would have done when you were brand new, that thing is actually a pretty good solution. If it's not good enough, introduce complexity as needed. But don't start with complexity, so much effort has been spent and so many simple easy projects turned into failures because people were trying to do it the "Right Way". But the right way has a scope, and that scope is typically medium to large projects. Don't start there, you'll spin your wheels and fail and burn out.
If you do those things, then you can have the option to get excited enough to do a small several hour to several day project, learn a lesson from it, and then set it aside to never be looked at again. Those projects are fun, and they don't cost you some permanent investment that is hard to get back.
Also, if you're doing this for work: Then know that estimates are bullshit, so don't commit to some estimate, and don't feel bad for blowing one (do reflect on why, though). And don't get attached to your code or some idea you suggested. You'll enjoy work so much more if you have better code that other people suggested, and if you don't feel obligated to double down on an opinion that as you think about it, is probably wrong.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Don't do it obligatorily (for me, at least, that makes it a chore and it looms over me)
Avoid commitment (the idea of releasing an open source thing is exciting, but maintaining it over time is high cost, low appreciation -- even abuse, and doesn't stand to offer you much).
The simple obvious thing you would have done when you were brand new, that thing is actually a pretty good solution. If it's not good enough, introduce complexity as needed. But don't start with complexity, so much effort has been spent and so many simple easy projects turned into failures because people were trying to do it the "Right Way". But the right way has a scope, and that scope is typically medium to large projects. Don't start there, you'll spin your wheels and fail and burn out.
If you do those things, then you can have the option to get excited enough to do a small several hour to several day project, learn a lesson from it, and then set it aside to never be looked at again. Those projects are fun, and they don't cost you some permanent investment that is hard to get back.
Also, if you're doing this for work: Then know that estimates are bullshit, so don't commit to some estimate, and don't feel bad for blowing one (do reflect on why, though). And don't get attached to your code or some idea you suggested. You'll enjoy work so much more if you have better code that other people suggested, and if you don't feel obligated to double down on an opinion that as you think about it, is probably wrong.