It's in the post, but Martin will be continuing to work on jj itself as well as on our products, just as he did at Google, working on the open source jj but also their internal source control team.
As a side note, jj has rules around company representation in maintainership, and so when this initially happened a few months back, ERSC actually became over-represented in the maintainers group, as we also employ several other maintainers. The project decided to add more maintainers to keep the balance, rather than ask folks to step down.
We very much want to properly support the upstream project, and we want to make sure that it continues to be awesome for everyone, not just our customers.
That idea about keeping maintainer balance is pretty neat, interesting to see this kind of diligence in maintainership in the same project where legal ownership belongs to a single company, Google, via the Contributor License Agreement. My interest in jj cooled off a lot after seeing that, even though I realize in practice it's pretty unlikely to be of consequence - I just don't need even that kind of low probability Sword of Damocles hanging over my VCS, forks and drama in case Google decides to mess things up. (Good to see that the Readme has been changed to say it's not a Google-supported project btw, less misleading than the old claim that it's not a Google project at all.)
Legal ownership does not belong to a single company. All copyrights are still held by each individual contributor, and they're available to be used under the Apache 2 license.
The CLA means Google also has a license to the code to do what they will with it, but it does not do copyright assignment. They do not own your contributions.
We (East River Source Control) don't run Jujutsu, it does not "belong" to us -- it is a community project! Nothing has or is changed. Most of the contributors have nothing to do with us/Google/whoever. We get tons of great contributions from highly experienced and talented individuals. It's healthy, check it out: https://github.com/jj-vcs/jj/commits/main/
Most of the maintainer stuff is also overhyped in a way (OSS maintainer-heads know this). The maintainer group is largely structured to just keep things moving; not really a privilege but a responsibility -- making sure things get merged, doing technical reviews, ensure builds are unstuck, and hitting the green approval button. Our own community members also do code review, find bugs, triage things, answer questions, design features, help get users unstuck, etc. We are very much not alone, and I have great confidence in the constitution and strength of the community itself as someone who has been around the block a few times.
This is going to sound silly and "guy approves of himself" adjacent, but I've been doing OSS maintainer stuff for like 2 decades at this point, and jj is truly a gem as a project. It is vibrant, and the community is generally speaking insanely talented (huge number of git powerusers), and we have a weird dogfood advantage where people use the tool to contribute right back to it. Martin did an awesome job setting the tone of the project just through his behavior before many of us joined years ago. He's a naturally good project lead.
As I said elsewhere: I work for ERSC and I am a Jujutsu maintainer. This is just me speaking candidly on my own behalf.
Isn't defining what should not be done by anyone a problem that laws (as in legislation) are for? Though, it's not that I expect that those laws would come in time.
Amazon was founded in 1994, went public in 1997 and became profitable in 2001. So Anthropic is two years behind with the IPO but who knows, maybe they'll be profitable by 2028? OpenAI is even more behind schedule.
How much loss did they accumulate until 2001? Pretty sure it wasn't the 44 billion OpenAI has. And Amazon didn't have many direct competitors offering the same services.
Did Amazon really not turn a profit, or apply a bunch of tricks to make it appear like they didn't in order to avoid taxes? Given their history, I'd assume the later: https://en.wikipedia.org/wiki/Amazon_tax_avoidance
Anyway, this has nothing to do with whether inference is profitable.
Their price is not a signal of their costs, it is the result of competitive pressure. This shouldn't be so hard to understand. Companies have burned investor money for market share for quite some time in our world.
This is the expected, the normal, why are you so defensive?
Because you made stuff up, did not show any proof, and ignored my proof to the contrary.
You made the claim:
> Deepseek lies about costs systematically.
DeepSeek broke down their cost in great detail, yet you simply called it "lies", but did not even mention which specific number of theirs you claim is a lie, so your statement is difficult to falsify. You also ignored my request for clarification.
You’re citing deepseek unaudited numbers. This is not even close to a proof.
Unless proven otherwise it is propaganda.
Meanwhile we have several industry experts pointing not only towards DeepSeek ridiculous claims of efficiency, but also the lies from other labs.
That's not how valuations work. A company's valuation is typically based on an NPV (net present value) calculation, which is a power series of its time-discounted future cash flows. Depending on the company's strategy, it's often rational for it to not be profitable for quite a long while, as long as it can give investors the expectation of significant profitability down the line.
Having said that, I do think that there is an investment bubble in AI, but am just arguing that you're not looking at the right signal.
This sounds wrong, features have to be the value of your code. The required maintenance and slow down to build more features (technical debt) are the liability, which is how I understood the relationship to "lines of code" anyway.
I can sort of understand it if I squint: every feature is a maintenance burden, and a risk of looking bad in front of users when you break or remove it, even if those users didn't use this feature. It's really a burden to be avoided when the point of your product is to grow its user base, not to actually be useful. Which explains why even Fischer-Price toys look more feature-ful and ergonomic than most new software products.
Crux seems interesting to share app logic between platforms but I don't see how it helps actually render something. Don't you still need a gui framework that supports android or ios?
Having spent time around cross platform rollouts and development I think something like Crux is the best approach. Building a complete UI framework to rival what iOS and Android provide natively is a monumental task.
