Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Project state? #1637

Closed
the-black-wolf opened this issue Mar 16, 2021 · 13 comments
Closed

Project state? #1637

the-black-wolf opened this issue Mar 16, 2021 · 13 comments

Comments

@the-black-wolf
Copy link

Guys and gals, is this project dead in the water?

There are over 400 issues not being resolved, some rather serious/annoying bugs and even when people contribute, there are 70 pending pull requests that hardly get checked. v3 thread, started 4+ years ago, barely got off the ground in that time with a few commits 4 years old now that never got merged. Most recent commits are just bindings and infrastructure to keep it buildable.

I am kind of getting worried here, given how many projects we weaned from the horrible EF into Dapper. Has StackExchange given up on improving this beyond their present needs?
@mgravell
Copy link
Member

mgravell commented Mar 17, 2021 via email

@the-black-wolf
Copy link
Author

@mgravell, of course, there are no expectations against anyone's free time. Actually, I was under the impression that Dapper is what makes StackExchange tick under the hood? Hence my impression (delusion?) that people working for SE maintain it because they use it themselves, thus that being some part of their full time job. Is that not the case?

@mgravell
Copy link
Member

It absolutely is what we use for the vast majority of our data access, but: it works just fine in those ways. If we were fixing a bug or adding a feature that was impacting us, then yes: we'd absolutely jump right on that and fix it. For things that aren't directly or indirectly impacting us - honestly, we have a ton of competing priorities, which means it is hard to find time for that; we do try and carve out time for OSS maintenance, but if we're talking about company time, then we need to schedule that and prioritise it against company priorities, and sometimes: that just isn't number one. And in that scenario, it mostly comes from our own spare time. Add a global pandemic into that, and speaking for myself: I've been focusing a lot more on family for the last year.

@Zubaloo
Copy link
Contributor

Zubaloo commented Mar 21, 2021

@mgravell, all what you wrote is completely understandable. But then maybe you guys transfer ownership on that project to someone who is enthusiastic about it? Supporting a fork to fix a bug that bothers me but does not bother you is not the same as making a pull request into original project.

I do realize that one needs quite a lot of time to build a good vision on a new version of the library, or that opened issues require time to investigate and prepare a fix, but leaving trivial pull requests (like correcting typos) unattended for months and having "contributions welcome!" on the home page, in my opinion, is a disrespect for the community.

@mgravell
Copy link
Member

mgravell commented Mar 21, 2021 •
edited
Loading

(takes a deep breath)

It is open source. You are free to fork it and make whatever changes you want. The main repo will wait on our availability.

If our voluntary effort on our own unpaid time isn't up to your satisfaction: that's OK, we're not making you use it. We'll get to it.

@the-black-wolf
Copy link
Author

@mgravell,

I agree with @mgravell here, I always implicitly give maintainers full rights awarded by their position, including decisions on where and how and if the project will move. In honesty SE did not have to share or open source this, I am (and I am sure you are) grateful for their effort which I am using on almost daily basis (without having to pay for it) and I did not start this thread to pass blame for anything. Open source is generally a best effort game dependent on good will. So, for what its worth, @mgravell and all SE staff involved in Dapper, Thank You very much! You have made my life easier.

It is also unrealistic to expect them to relinquish control and transfer project ownership given that this is a core library used by their business, exposing them to breaking changes which could hurt their business. So I do not really hold "contributions welcome" against them.

That being said, there is something to what you are both mentioning. It is becoming obvious that the needs of the community surpass the needs of the initial authors and maintainers and their company, which all are otherwise swamped with other demands on their time. Maybe it is indeed time for a proper re-branded fork and an independent roadmap, allowing people to migrate if they so desire.
It wouldn't be the first time I do this, so I am potentially interested in organizing this given how invested I am in this library and its stability on our code, but I doubt I have the time to be a sole maintainer of the project with this much accumulated community demands. Granted, this would be my first Apache2 licensed fork, so I might have to read up on it, but I don't foresee any problems. If there are other interested parties who are deeply familiar with Dapper (even better its internals), believe in quality though testing and have some free time to invest, comment here. I have some free cycles as of Apr 10 and I can kick this off.

@the-black-wolf
Copy link
Author

the-black-wolf commented Apr 13, 2021 •
edited
Loading

@mgravell, what is the state of branding and trademark for this project? Is the word Dapper trademarked or can it be used as part of fork branding name? (Dapper Community, New Dapper, NeoDapper, etc)

@mgravell
Copy link
Member

mgravell commented Apr 13, 2021 via email

@the-black-wolf
Copy link
Author

@mgravell ok, fair enough, although Dapper is pretty much a dictionary word, I'll respect your wishes on this matter.

@NickCraver
Copy link
Member

Marc and I have talked about this for some time: Dapper.Contrib specifically is not something we use at Stack Exchange, or in general. Therefore, it gets less love. The same is true for Dapper.Rainbow, and some others so they may split too, but please see #1658 for details (there are no comments there yet).

Note that Dapper vNext will be a major breaking change, using source generators, aligning async APIs, strong named, etc. - and it'll be some friction to upgrade as a result. That's pretty much all our free time effort (which is in flux - we'll see what the coming months hold) will be focused on, not the auxiliary libraries.

That being said: if the community loves these and wants to contribute: I invite you to step up :) https://github.com/DapperLib/Dapper.Contrib will need maintainers, and it won't be us.

It needs a lot of love: feature requests for generic insert methods, quirks with various providers, decisions and handling around whether column names are quoted, etc. It'll also need a lot of love for to be based on Dapper vNext where the intent is to move [Column] and [Table] attribute into the core lib (see #722).

The reason many PRs sat for so long is that we hate to shoot down work by new contributors especially, that's off-putting. I hate hate hate it. But at the same time, almost every change in queue was a breaking change in behavior or literal source/binary compat. I've started going through these and closing the loop so that they don't sit forever, because that's not fair either. Some need love and we'll merge the functionality into vNext (if not the literal PR - source generators will greatly change the codebase, and we had to wait until they were ready). Other bits that are breaking many methods (e.g. adding an optional parameter) will be approached differently via an IDapperConfig in the next release which we can modify and add to over time, coherently, without breaking people.

There is a mountain of work here. But to get out of that mountain requires us to stop adding ad-hoc changes and additions to an organic API that's past the point of sustainable (e.g. where almost all changes are breaking changes). That's the next step.

@Dzoukr Dzoukr mentioned this issue Jun 16, 2021
Open
@Ryanman
Copy link

Ryanman commented Jul 21, 2021

It needs a lot of love: feature requests for generic insert methods, quirks with various providers, decisions and handling around whether column names are quoted, etc. It'll also need a lot of love for to be based on Dapper vNext where the intent is to move [Column] and [Table] attribute into the core lib (see #722).

Awesome to hear this - it should really help with non-greenfield projects in particular that are moving to Dapper. Thanks for y'alls work & Excited for vNext.

@TroySchmidt
Copy link

The issue of PRs getting reviewed and accepted is still going to be an issue with Dapper.Contrib. There are improvements that could be made that would be dependent on the main library Dapper getting improvements to support them. So it's still in the same boat and tied to the future and cadence of improvements in Dapper whether it is picked up by new maintainers or not.

@mgravell
Copy link
Member

mgravell commented Jun 9, 2023

See #1909

@mgravell mgravell closed this as completed Jun 9, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@mgravell @NickCraver @Ryanman @TroySchmidt @Zubaloo @the-black-wolf