At this point the Eve project is so far out in left-field it's astounding. If you start with Lighttable and move on through Aurora and Eve you see the same patter over and over.
1) say X is broken we should fix it
2) we will fix X in a way that we don't have time to explain in detail now
3) please send money!
4) ....
5) we didn't solve X but we worked on Y and Z!
6) Y is broken we should fix it.
7) don't have details on how we will solve Y but please send money.
8) ....
9) we didn't solve Y but we worked on Z and Z'
What started as a Lighttable eventually got set-aside for Aurora. What then started as a Excel like environment, morphed several times into databases, temporal stores, and who knows what else. The even started building Eve in Rust and Typescript! Can't see those anymore on the github, but hey! I can see Lua and JS!
Our work is all open source, we've published our bibliography, and we've talked about all the prototypes and what we've learned from them here [1]. The only time we asked for money was the Kickstarter, which was only done because HN community specifically asked us to. Is there something specific you're particularly upset about?
You honored my rant with a reply, so I will honor it with a reply as well :)
The problem is this...when software is designed it is critical to know what is being solved. I don't think the problem set or the way they will be solved has been nailed down, or if it is, it has never been properly explained. In two years of work, and 2mil in funding I would have expected at least a usable alpha (80% complete prototype) in this amount of time. Perhaps that's a wrong expectation, but without even a problem statement and a roadmap, how am I to know?
I have yet to see a rationale for Eve. I'd love to see a 1 paragraph description of what the problem is Eve is trying to solve. Then a bullet point list of goals and non-goals. After that I would love to see a list of architectural decisions (is Eve distributed or not, what size of datasets is Eve aiming for, etc.). After that I'd love to see a list of tradeoffs (because we are distributed, we have these problems. 1GB datasets will require optimizations around ingestion, etc).
Without all of this, all I see is two years of vaporware and a few developers spending investor money hacking on pet projects.
The expectations for research and the expectations for engineering are different, and I suspect that's where a lot of this comes from. We've kept our burn insanely low (we still have a full startup's worth of runway left), because we knew we didn't have a handle on exactly what the problems were or exactly how to solve them. We're not naive enough to think we can waltz in and do something very smart people have been trying to do for 50 years - we needed to take our time and explore the space. We've tried to communicate that in several ways: always talking about experiments, posting bibliographies, doing a few talks on the crazy ideas we tried, etc. All in all, I'm really proud of what we managed to do in two years - it's easily several PhDs worth of work (our full bibliography is over 300 papers!).
We've had a rationale up for a while [1] and our first post on incidental complexity also went over a lot of that [2]. But given the above it's certainly not as explicit as you're wanting, because until very recently we hadn't figured out the exact what or how. The plan for the fall release is to present a real system for people to use as well as a ton of content to lay all of that out in detail. We'll be drawing lines between all the various things we've done and all the papers we've read to the real working system - tradeoffs and all. We're actually really excited about it - it's been tough figuring out how all this is meant to fit together and we have the opportunity to present things in a very exploratory way, where people can dig as deep as they want (there'll be weeks worth of stuff). Once we pull a first draft of that together, I'd love to send it to you to get your thoughts.
4 comments
[ 4.1 ms ] story [ 37.4 ms ] thread1) say X is broken we should fix it 2) we will fix X in a way that we don't have time to explain in detail now 3) please send money! 4) .... 5) we didn't solve X but we worked on Y and Z! 6) Y is broken we should fix it. 7) don't have details on how we will solve Y but please send money. 8) .... 9) we didn't solve Y but we worked on Z and Z'
What started as a Lighttable eventually got set-aside for Aurora. What then started as a Excel like environment, morphed several times into databases, temporal stores, and who knows what else. The even started building Eve in Rust and Typescript! Can't see those anymore on the github, but hey! I can see Lua and JS!
All our experiments have been moved to here: https://github.com/witheve/eve-experiments, which has the complete history of all the versions we've built.
Our work is all open source, we've published our bibliography, and we've talked about all the prototypes and what we've learned from them here [1]. The only time we asked for money was the Kickstarter, which was only done because HN community specifically asked us to. Is there something specific you're particularly upset about?
[1]: http://incidentalcomplexity.com/
The problem is this...when software is designed it is critical to know what is being solved. I don't think the problem set or the way they will be solved has been nailed down, or if it is, it has never been properly explained. In two years of work, and 2mil in funding I would have expected at least a usable alpha (80% complete prototype) in this amount of time. Perhaps that's a wrong expectation, but without even a problem statement and a roadmap, how am I to know?
I have yet to see a rationale for Eve. I'd love to see a 1 paragraph description of what the problem is Eve is trying to solve. Then a bullet point list of goals and non-goals. After that I would love to see a list of architectural decisions (is Eve distributed or not, what size of datasets is Eve aiming for, etc.). After that I'd love to see a list of tradeoffs (because we are distributed, we have these problems. 1GB datasets will require optimizations around ingestion, etc).
Without all of this, all I see is two years of vaporware and a few developers spending investor money hacking on pet projects.
We've had a rationale up for a while [1] and our first post on incidental complexity also went over a lot of that [2]. But given the above it's certainly not as explicit as you're wanting, because until very recently we hadn't figured out the exact what or how. The plan for the fall release is to present a real system for people to use as well as a ton of content to lay all of that out in detail. We'll be drawing lines between all the various things we've done and all the papers we've read to the real working system - tradeoffs and all. We're actually really excited about it - it's been tough figuring out how all this is meant to fit together and we have the opportunity to present things in a very exploratory way, where people can dig as deep as they want (there'll be weeks worth of stuff). Once we pull a first draft of that together, I'd love to send it to you to get your thoughts.
[1]: https://github.com/witheve/eve-experiments/blob/master/desig...
[2]: http://incidentalcomplexity.com/2014/10/16/retrospective/