Personally, I have some software engineering skills. For me it’s about trust in your development team and product direction.

To be at least somewhat certain of the future, I want to own critical pieces of software, not rent it from someone no matter how benevolent-looking.

While things are well, I want to be able to contribute. There are myriads of minor things that your development teams would never get time to look into. If something is a wart, I might have skills to do it myself and - hopefully - ask you to incorporate my patches. I did that to a few pieces of software I trust and use, and I consider the ability to do this as fairly important, even though I do this very rarely.

And if things go sour, it could be impossible to keep up with long-term maintenance of this complex machinery but I still want that option open too. I want to know that if you folks decide to do something unpleasant to the browser, I’ll be able to begrudgingly take over and still fully own the software at least while I’m investigating the replacement options. Not be at someone’s else’s mercy.

To be persuaded otherwise, I need to be aware about your reasons for not providing users software freedoms and agree they’re serving our mutual interests.

(Needless to say, Orion is a very different product from Kagi Search, which is why I apply different set of requirements. I can switch search engines much more easily than user agent software.)

Browser handling is way more personal than any other piece of software. It need not be open source licensed but being able to compile and install it from source the exact binary (minus signing) is a huge plus is today's world. Otherwise is "not" doing much from chrome, brave, firefox etc of today. Open source would be cherry on top.

Trust of Kagi search is already there w.r.t both the tool and the company but it is not transferable to Trust to the Orion Browser.

It may not phone home now, but it can do it tomorrow, or it can in be enabled and immediately disabled in some minor releases. Even if people didn't catch those shenanigans immediately it will be evident from the commit history. I'd say opensource forces certain discipline.

Also there is point of rugpull, or the product is getting cancelled. Few people will step up to maintain it; atleast until most users migrate to a different product.

> it doesn't need to be open source to do that, nor would making it open source obviate auditig the final executable anyways

It doesn't need to be open source to do that, but it really helps. Ideally you'd publish source and have reproducible builds, so that users could look at the code to see that it's not doing anything objectionable and a handful of people could make sure that that code matched the official binaries.

> You can audit the application's behavior with standard tools to verify that it isn't "phoning home", etc.

Can you? Practically? Lots of programs are easy: You put them in a sandbox with zero network access, or very carefully restricted access, and that eliminates 90% of likely problems. But this is a web browser; it's purpose is to connect over the network, all day every day, to arbitrary, dynamic domains in large numbers, such that I would seriously question whether it is in fact practical to audit in a black-box approach.

I think Kagi / Orion should go down the independent auditor route like TrailOfBits, Cure53 and others.

That way the software would be audited and it doesn't have to be open source.

It's relatively hard to audit a binary. You can audit the behavior of single runs, you can't nearly as easily audit the behavior of the program itself though. What if it pings only on Tuesdays, what if it does some sort of dns reach out that's a false positive for something else you didn't realize the browser was doing, what if there are platform specific differences in behavior.

The same goes for auditing the final executable. Open source gives two options on that: build it, trust it. The latter may seem 0 gain but, again, it is actually a big difference trying to audit a blackbox for every possible behavior vs seeing what the baseline behavior is supposed to be and looking if any differences occur in the premade binaries. There is a 3rd option: reproducible builds... but I doubt that's a reasonable goal in this case.

I'm not saying Kagi/Orion should necessarily care about providing that level of audibility, just that the response a pre-made binary is as trustable as a binary with its source code falls quite flat.

>Orion doesn't have any telemetry, doesn't force any updates on you, doesn't require any account.

Source: "Trust me".

As another person mentioned, telemetry could be sent out Sundays @ 2:00am, so my use of standard tools to verify that it isn't phoning home on a Tuesday afternoon is useless. This is just one isolated example.

>it doesn't need to be open source to do that, nor would making it open source obviate auditig the final executable anyways.

Trust is not a single bit that is flipped from "Fully trust" to "Fully distrust". Things become more trustworthy when the source can be reviewed, and less trustworthy when an employee says "We don't do this, trust us, but we're keeping the box closed because ~reasons~".

In my eyes, Kagi has a lot of trust-building to do, despite being the darling child that can do no wrong in many HNers eyes (for whatever reason).

Also trust that it won't be abandoned like Opera was.

I'm assuming the people who are asking for Orion to be open source are not paying for it.

I think a blog post on Orion's transparency is enough. The fact that there is Orion+ is enough to warrant no need to have tracking or 'enshittification'.

If you like Kagi and Orion, supporting development by paying for it makes sense.

Open sourcing everything of Orion means that Orion+ will be open source which defeats the point of supporting development of Orion directly.

I've seen projects start open source, change to closed source and then add in the enshittification later. It doesn't matter if the code is 'open' the source code would eventually be unmaintained and have security holes which there is no time in the world for anyone else to maintain.

By pushing back on someone over trust, you’ve eliminated the interest I briefly held in evaluating Orion. It would’ve been far better to acknowledge the concern than nitpick it.

This is true, and this is where trusted repositories come in.

I don't necessarily have to trust each individual app on fdroid or in the Debian repos. I have trust the maintainers are building them properly, and those people are not the same people developing the core app.

Practically every platform has multiple software stores these days and many FOSS stores make their build logs available. Some take it a step further and provide reproducible builds, which is more or less there as far as source to binary traceability and binary trustworthiness is concerned. These are good enough reasons to open up the source, ignoring the other advantages just this once.

The ability to do so provides some protection. If someone pulls and builds and cannot reproduce the binaries, they can at least try to get the word out. Closed-source prevents even the opportunity. Even source-available is better than closed.

??? why does any company do it? Money?