It’s officially Q3, and it is hard to know if Dgraph even is alive.
Nobody has done any PRs for years (outside of a few small ones that weren’t included in the v23 fork).
Why would they for a dead product? Think about this.
Could you guys just admit:
No new enhancements are coming outside of Vector support. DQL will not get constraints, cascade fixes, nor loops.
The GraphQL will not get the security fixes repaired, and there will not be a work-around with triggers, nested mutations, nor sort by nested aggregations etc.
None of the thousands of hours spent by actual users explaining the problems will be taken into account to fix any other problems or feature requests.
The headline is: we’re a small team doing our best to continue to improve and maintain a project that’s been loved/used by so many for so many years. I understand ya’ll would like to see more/faster from us-- honestly, so would we.
That said, with that small team we’ve got, we’re balancing adding more Global 2000 customers and their specific requirements (We grew revenue by 50% QoQ!) vs contributing things back to this community. The upside for you all is that the more customers we’re able to make successful, the more engineering capacity we’ll be able to subsidize for Dgraph’s open source projects.
In Q2 we shipped:
Vector Support
shipped alpha, RC, and GA builds with community participation
seeing strong interest in this functionality
Maintenance and Performance Updates
v24 brings 32% improvement in writes
v24 brings up to 1000x improvement in reads for customers with complex GraphQL schemas
v24 brought a major upgrade to Golang v1.22
Embrace External Contributions
v24 included 89 commits from 24 different contributors
We’ve put a focus on test speed and flakiness to shorten response times; more work to do but over the last 60 days:
run time is down 86%
failure rate is down 30%
We’ve heard resounding feedback from the community about the importance of the maintenance investments and intend to continue focusing there, notably:
further investment in testing
refactoring around complex and outdated components
Honest question, how many of these are old commits that were re-merged?
This is not balancing when there are no contributions outside of maintenance. There are security bugs that need to be fixed, which should be included in maintenance.
Adding even one feature the PSC team has requested would go a long way. Otherwise, you’re not showing you care what your current users want. You still have enterprise users that need things done.
This is extremely important, and without a doubt first priority. Maintenance should not be the only priority.
You basically do NOT have a plan to do anything outside of maintenance and “grow the business.”
Exception handling - more granular exceptions would be great, we end up parsing strings out of generic expectation messages to see what kind of exception it is.
Chunking - we’ve had to write a lot of not-great code to get below the 4mb grpc limit with chunking. It’d be great if the client handled this transparently.
Hey @rahst12,
Thank you for your feedback. We appreciate your suggestion for more granular exceptions. Could you please elaborate on your use case so we can get an idea of what kind of improvements we can make?
Regarding chunking, could you please share your code snippet with us? It would help us understand your approach better and inspire potential solutions.
@KVG … TBH it really sucks to see this update. I understand the team size is small. There is a strong open source community ready to contribute. The past leadership with @akon seemed to have had a good start. Then @akon left dgraph, and @gajanan was running the community sessions. The meetings with @gajanan lacked focus and needed experience in my opinion. Both these so called leaders have never contributed to open source projects nor did they understand how to drive a project to success.
Please don’t mistake my notes as a jab on past or current leadership. I have led 3 apache projects, and the way Dgraph was run is super poor. In a way ,I was happy when the leadership was changing with @akon’s exit. And now I learnt @gajanan has also left to do his own consultancy. Things change, people change, I get it. Nothing great came from the past leadership. It’s also 8months or so since you took over, the commits and stability to your codebase is still poor.
Please note, there are always serious risks when sales folks like yourself take over a company. You are talking to developers here. 50% QoQ growth is great. But most folks here don’t care. Engineers as you know are perfectionists, and product focused. Your messaging should be more focused on your target users, community and customers. The vector stuff you all talk about, is like lipstick on a pig. The benchmarks for your product is breaking, just like how @amaster507 has been screaming on top of his voice every time here.
I would love to help your team get a better handle here. Hit me up if you guys are serious about maintaining a community version of Dgraph. We can run it better than your current team. I hope you will try to trust the community. This may actually go somewhere if you give it a shot. Hit me up if you want to discuss seriously.
lol, thanks for the callout, that got me a DM on discord from the CEO. I don’t know if I am really feeling up to help/advise Dgraph’s direction. I got a lot going on in my life currently and have already had the same conversations a time or two already.
@amaster507 totally fair-- if you change your mind, just let me know.
I dm’ed @honeybadger as well. Going to try to take a more active role here.
I’m going to try not to make any promises about what we can/can’t deliver until we demonstrate some feature momentum. I’ve pinged a few other PSC folks to get feedback on what we’re thinking wrt to DQL/GraphQL investments.
