Project members

[mbauerdev]

Hey there,

After a few months as a heavy user of this client implementation including contribution to this awesome project, I realized that there is one big issue with the project organization: Pull requests take way too long to be reviewed.

I know, its an open-source project maintained by @object who does all the work in his spare time. I really appreciate that, thanks for all your efforts.

But may it be an option to involve other devs into that project? If so, they could review small PR's and reduce the cycle until a new version is baked. As an example, I started a PR yesterday (#834) which is a tiny change - but the bug (introduced by myself btw) leads to serious production issues. Now, we need to invest time to develop a work-around, track the PR and if approved, throw away the previously developed solution.

@object What do you think?

[object]

Hi @mbauerdev

I appreciated you taking the initiative to improve the situation with the library. As I stated few times before, I haven't been using OData in my own projects for years (I believe more for than 5 years), moreover I am no longer using C# much. Doing F# development most of the time. So with complete change of focus and lack of time it's been really difficult for me to be the library maintainer. And the libraray with a few milllion downloads of its Nuget packages and great contributors really deserve a better maintainability.

I believe the best would be if we find a person or a group that is willing to continue maintaining and further development of the library so I can tranfer full code and Nuget package ownership to them.

Open for suggestions.

[mbauerdev]

Hi @object

Wow, very big move from your side, I'm impressed! Developing and maintaining a code-base of this size over several years must be a huge emotional investment. Therefore, it must be a big step to change the setup of the project and maybe let other contributors join the party.

As you may have noticed, there was a recent discussion about this topic inside this pull request: #833

It seems as there are some companies out there willing to contribute more. They're asking if its time to fork now, but in my opinion, this would be a bad move. I'd love to see this repository as the one and only Simple.OData.Client, but with more project members.

I know, its difficult to find a good co-maintainer, but I hope there will be some of them...

[ysmoradi]

Count on me! I'll do whatever I can to make this project even better. The maintainers group on this project is far better than the fork idea

[davidnmbond]

I would be very happy to help.

We (Panoramic Data) rely heavily on it, so I have already updated all the source to latest language standards, nuget packages etc. over at:

• https://www.nuget.org/packages?q=PanoramicData.OData
• https://github.com/panoramicdata/PanoramicData.OData.Client

We are using this now for our own purposes, but we would rather not hard fork. I would be happy to help keep this project up to date (you can review my coding standards etc. over here: https://github.com/panoramicdata/PanoramicData.OData.Client ) and will merge all those (non-functional) changes back in (and remove the other repository, nuget listings etc.).

Anyway... for your consideration!

[mbauerdev]

@object: Can we (community) expect an initiative on this topic from your side? Did you think about who you want to nominate as maintainer? It seems to me as there are some motivated people around here (@davidnmbond, @ysmoradi) that would be happy to help out. Also, there are some contributors known from recent pull requests that may also be good maintainers (@robertmclaws, @zivillian, @nsarris, @NetTecture and maybe more)...

[NetTecture]

Well, at least if you talk of me - right now I am barely maintaining some code bases I have inhouse by updating them. In the planning stage for some major projects, including a heavily odata based rework of some codebase.... but right now... I spent the best part of this year planning things and am in the middle of a major move (like literally - changing continents). If things go as planned, I may be more involved at some point next year, but it really is all in the cloud now. I had severe burnout for nearly a year and am getting out of it and my main focus right now is not on IT anymore. That said, again, some major things there are planned.... just need to get so much lined up.

So, please ignore me for anything more than very occasional input at the moment.

@davidnmbond This does really not look bad - if you think you can muster the official bandwidth to step in as maintainer, then... you would have my backing for whatever it is worth.

[mbauerdev]

@NetTecture Very sorry to hear that, hope you find time to relax! Mentioning you was not a nomination at all, I just went through some PR's to see who actively contributed high-quality content 😁

[object]

@mbauerdev I'd love to nominate a maintainer (ideally a group), and I have in fact been waiting for this to happen. But I can't just nominate somebody without them expressing their wish and will to become one. I believe I made it clear that I don't have capacity to actively maintain this project, so hopefully we will sort it out.

[NetTecture]

@mbauerdev You have no idea ;) I totally refocused - and on the 10th I officially relocate to Dubai. My current situation is extremely nice. One thing I do know now is that whatever happens, I will never ever do either classical product development or client IT projects ever again. Never felt better... time next year to move back into expanding what turns out to be an very interesting little niche I now live in.

Did not take it as a nomination -. just wanted to say. The sad, imho really sad part about Odata is that it falls on the wayside although it has the potential to be the best way to do things. gRPC is just not there - not sure how active Odata spec development is these days (4.01 is not exactly new), but I think it still is the best that there is. Sadly, less and less people seem to understand what OData actually means.

If anything, Simple.OData seriously deserves to survive as long as possible. If there would be a benefit I may be able to allocate some funds from one of the budgets I am managing for clients now for maintenance - just not sure how much manpower personally I can contribute.

[mbauerdev]

@object Sounds good... I guess we have two candidates here (@davidnmbond, @ysmoradi) - let's see what they answer to this thread.

If you are wondering why I did not nominate myself so far:

1. I'm using the library in one customer project only and I have no clue how long they keep me on the project
2. My spare-time is very limited due two main time-intense hobbies (lecturer at an university / father of 3 small kids)

If you are fine with that, I'd love to be a maintainer investing a small amount of time... If not, I can absolutely understand it 🙂

@NetTecture I'm very glad to hear, that the change in your life made you happier than ever before! And I agree with everything you posted...

[phatcher]

Hi, I will be more active next year, dropped out as I haven't used OData for the past 3 years but my major project next year will need to adopt this so happy to be part of maintainer group

[robertmclaws]

@object My company is HEAVILY invested in OData, and we actively maintain the OData Restier project for Microsoft. Happy to also have @caldwell0414 any myself contribute to maintenance (and potentially new feature updates) wherever possible.

[davidnmbond]

Thanks to those that have offered support. My pitch:

My company @panor is invested in OData - we use it for our own ReportMagic system, and we use this project for talking to Microsoft Dynamics 365 and others. We maintain a number of nuget packages (MIT licensed, open source in Github here) for well-known systems including Cisco, Meraki, AutoTask, LogicMonitor, ServiceNow, Microsoft Dynamics, MapBox, Toggl, Certify and others. We are strong believers in Open Source and nuget. Where we can re-use code between projects as nuget packages, we generally publish on nuget. As an example, check out our Blazor File Explorer, part of our PanoramicData.Blazor library here.

What we can offer:

• coding to the quality demonstrated in our fork (and all our other packages)
• an open approach to building a team of contributors, with teams invites naturally following from high quality pull requests
• time where we can
• the humility to know that we can't do everything, and the sense to bring good devs into the fold (presumably including the other nominees)
• an understanding of the Nuget release process
• version control with Nerdbank
• automated CI, unit testing and nuget publishing
• an understanding of just. how. good. OData is, why it's needed and the value of this project!

[object]

@robertmclaws @davidnmbond @phatcher @ysmoradi Thank you for the initiative. Paul already had write access to the repo, I invited Robert, Yaser and David. Ideally I would like a group of people to maintain the project, so if you three don't mind you can get this role. You can then manage people as you will. I can stay for a while as a maintainer too but as I said earlier I have been far away from OData for many years, so I can't expect an active contribution from myself. I can still participate in discussions.

If this is fine for you, I can also grant you access to NuGet packages so you can manage package releases.

And thank you @mbauerdev for inviting people to this discussion.

[davidnmbond]

Thanks @object - this is a hugely valuable project and we all appreciate this move. Yes, please do grant nuget release privileges. I am david_n_m_bond on nuget.

For people waiting on the various pull requests, until we accept any of these, let's:

• take @object's comments as definitive
• require ALL unit tests to pass (normally unaltered) before the PR is accepted
• stick with the principle of exposing no more as public than is currently exposed

Right now, I'm working to get a full set of passing unit tests on master and will update as soon as I can on each PR thread.

[object]

Great! I am going through a few of PRs now. Will grant you access to NuGet.

[robertmclaws]

David, would love to see your modernization changes make it into the codebase.

We should also turn on Discussions so that we can work as a group separate from Issues.

I'm sure our first contribution will be some non-breaking constructor additions that will make it easier to subclass the Client.

[davidnmbond]

@robertmclaws - discussions switched on

[object]

@davidnmbond I've sent you ownership request on 3 Simple.OData.Client packages

[nsarris]

Like I said on the v6 issue we are using this library heavily and we started working on a v6 modernization with the proposed changes on that thread https://github.com/simple-odata-client/Simple.OData.Client/issues/817

Unfortunatley our priorities switched half way through due and we paused it till end of year. I will start working on it again after the holidays so anyone interested please join that issue and let's start discussing on upcoming changes.

Most of the work I've dont was to create an abstraction layer over the different versions of the EDM model to provide caching and v3/v4 support transaprently. The other large part is restructuring dependencies in a more clear way, you can check out the details. And another major area is name match resolution which currently has performance and logic issues.