Open source the browser

Vlad

Hackmodford You can absolutelty verify it is zero telemetry, all you need is a network proxy.

Hackmodford

Vlad Orion could be sharing telemetry in short bursts on a specific day at a specific time randomly. Or only sending telemetry if the known sniffer tools are not running. (Just a couple examples that come to mind) There are examples of this in the wild. The only way to be sure is to see the source code and compile it ourselves.

As a compromise you could share the source, but disable public PRs if you don’t have enough staff to manage it.

DR

SerViette I think the benefit of this would be to allow users to find fixes themselves and contribute indirectly to the project. Even if the resources aren't available to fully opensource and allow for community contribution, users would then be able to point out where an issue might be in the code when making a post on this feedback forum, or even submit a potential fix!

Not quite as good as hosting it on github or something, but I feel like it's a good in between for now where you wouldn't need more staffing to start with, and users could still contribute to some degree (or create their own patches for features they aren't a fan of)

Vlad

DR Kagi already has 12 open source projects, all of them are much easier to contribute to than to a web browser, and we rarely get any contributions, if at all. We can not even get people to contribute to Orion, even when we offer to pay them to do so. I am afraid we do not just see the benefit of allocating resources this way.

Anatomy5803

Vlad @Vlad you certainly can get people to contribute to Orion, just look at Ladybird. If anything Ladybird would be harder because its a new engine from scratch. Again, Orion doesn't even need to be OSI-defined open source, it just has to be source available (initially) if you're worried about managing a large open source project. If you have any more concerns about open sourcing the browser, please list as many as you have. I'd be more than happy to address each one. I genuinely believe open source (or even source available) would benefit Orion more than not.

With that said, you can open source things as much as you want, but a solid community with a culture of contributing needs to be there as well (SerenityOS, Ladybird, Zig, etc)

Anatomy5803

Here is a more detailed proposal/FR that incorporates some elements of the discussion above:
I propose a phased approach to open-sourcing the Orion browser, balancing the benefits of transparency and community involvement with the current resource constraints of the Kagi team. This approach aims to address user concerns about privacy verification, potential security audits, and the ability for users to contribute to the project, while minimising the immediate burden on the small development team.

Phase 1: Source Code Publication

Publish the source code of Orion as a downloadable archive (e.g., tarball) with each major release.
Include build instructions to allow interested users to compile the browser themselves.
Disable public contributions initially to manage workload.

Phase 2: Documentation and Transparency

Develop and publish comprehensive documentation, including:
- Project overview (architecture, components, design philosophy)
- Development guide (setup, coding style)
- Roadmap for future development

Phase 3: Limited Community Involvement

Set up a public repository (e.g., on GitHub) with issue tracking enabled.
Allow users to report bugs and suggest improvements through issues.
Consider enabling pull requests for small, non-critical components or documentation.

Phase 4: Full Open-Source Transition

To be implemented when the team reaches a sustainable size (e.g., 10 developers).
Hire or designate an open-source community manager to act as a liaison between the community and the core development team.
Enable full public contributions, including pull requests for all components.

Benefits:

Increased trust and transparency, allowing users to verify zero-telemetry claims.
Potential for community contributions, even if limited initially.
Improved bug reporting and feature requests with direct reference to source code.
Attraction of privacy-focused developers and potential future hires.
Competitive advantage against other privacy-focused browsers.

Considerations:

Choose an appropriate license that protects Kagi's interests while allowing for transparency.
Implement a code review process that doesn't overwhelm the current team.
Clearly communicate the phased approach and current limitations to manage community expectations.

This phased approach allows Orion to move towards open-source status gradually, addressing user concerns while working within current resource (time, people) constraints. It provides a clear path forward that can be adjusted based on team growth and community engagement.

DR

Anatomy5803 Parts of this seem to add extra complexity for the development team that could be avoided or streamlined. For instance, adding full documentation so early on in the process is unnecessary, especially when that is something fairly simple for community contributors to add. Any internal documentation already in use (e.g. to dictate code organization) could easily be released at this stage while the rest can sit on the back burner. Furthermore, while releasing zip files initially and switching to github after documentation is fairly easy to do, this process could be moved forward much faster by just releasing the github with community pull requests disabled, and simply link here for bug reports. If few people seem interested in contributing, as Vlad mentioned, then it wouldn’t be a problem to open pull requests either… there wouldn’t be much to manage at first by the sounds of it anyway! That last bit is what really gets me. If so few people are going to contribute, then there really is no need for management, and it’s an easy option to open source. If a large number of people are going to contribute, then it would be… but the argument against open sourcing seems to be an issue of not having enough people wanting to contribute, but also needing more community management if you were going to. That logic doesn’t follow.

Anatomy5803

DR
Your response was very compelling. I respectfully disagree in part, and agree in part.

Parts of this seem to add extra complexity for the development team that could be avoided or streamlined. [...] If few people seem interested in contributing, as Vlad mentioned, then it wouldn’t be a problem to open pull requests either… there wouldn’t be much to manage at first by the sounds of it anyway!

The ultimate goal is to fully open source the browser, given that the team is so small, and the Orion codebase is so large, it seems natural that any external contribution would add extra stress to the team. Providing up to date documentation after source code publication is critical, since a browser is a huge project. The WebKit browser, for instance, doesn't have that much documentation or info on its internal workings as good as Firefox or Chromium, and this limits the number of contributors.

Furthermore, while releasing zip files initially and switching to github after documentation is fairly easy to do, this process could be moved forward much faster by just releasing the github with community pull requests disabled, and simply link here for bug reports

I agree with this.

If so few people are going to contribute, then there really is no need for management.

I can see arguments for and against this. On one hand, yes, if few people are going to contribute, then there is less to review, and will make it easier for the team to manage it, compared to a larger amount of PRs. On the other hand, given the small team, it might add more stress to them even if the contributions are little. But I don't know the inner workings of the dev team.

argument against open sourcing seems to be an issue of not having enough people wanting to contribute, but also needing more community management if you were going to.

I agree that those are two opposing things.

So I think, yes, the browser should be at least open sourced on GitHub with PRs and Issues disabled, with issues being redirected here. I do still think documentation should come before opening to Github Issue Tracker, and small PRs. @Vlad how many engineers are working on Orion (full time/part time)? Ladybird has 6 engineers and they're maintaining an entire browser engine. If the dev team is ₁₀ people, I definitely think it can be manageable given the steps I outlined.

Vlad

Anatomy5803 Orion is 3 full time people. Orion + WebKit codebase is several orders of magnitude larger than LadyBird. We have over 2000 open issues, dev team is working on those vs trying to document Orion and manage open source project. As I said before, expectation that someone will contribute is pretty low at this point. I am afraid we are just not equipped for this move at this time.

Anatomy5803

Vlad I hate to be insistent, but I have to be precise. What about just publishing the source on GitHub with PRs & issues disabled, with no documentation? (step 1, source code publication). Then when the team expands (however long that may take), they can move on to the other steps when ready, which I reiterate is not right now. What are the downsides of just source code publication with no contributions/documentation?

Anatomy5803

Vlad

Orion + WebKit codebase

With what I was following, I mean no disrespect to the dev team, they have done a lot and so much with so little, and I appreciate their work immensely, I sincerely mean that. With that said, if you're making a browser that uses another browser engine (WebKit, Chromium) you should not be modifying the codebase directly. You can use patches to modify them externally. You should not be having the maintain the WebKit codebase.

Vlad

Anatomy5803 The risk is obviously Orion's IP being lost to a competitor before Orion can stand it's own ground.

Anatomy5803

Vlad There are open source, fair code, & other source available licenses & restrictions that protect IP, and can be enforced in court. Respectfully, I don't see many arguments against open sourcing. Your arguments are essentially (with my counterarguments/rebuttals):

Claim: Limited Resources.
- My Response: Open-sourcing doesn't necessarily require immediate active management. Starting with a read-only repository could increase transparency without significantly increasing workload.
Claim: Management Overhead.
- My Response: This can be remedied by adopting a phased approached like the one discussed above. Start with publishing code, then gradually open up to contributions as resources allow. Many successful open-source projects started small.
Claim: Large Codebase.
- My Response: The size of the codebase doesn't prevent open-sourcing. WebKit is already open source, so the focus would be on Orion-specific code.
Claim: Lack of Qualified Contributors.
- My Response: On the contrary, open-sourcing could actually attract qualified contributors who are interested in working on a WebKit-based browser but haven't had the opportunity. Additionally PRs will be disabled for the time being, so there won't be anything to contribute in terms of code.
Claim: Limited Benefit.
- My Response: I personally think the benefits outweigh the drawbacks. Benefits include increased trust from privacy-conscious users, potential for third-party security audits, and possibly attracting talent or contributions in the long run.
Claim: Low Expectation of Contributions.
- My Response: Even if contributions are low, the transparency itself is valuable. Plus, you can't get contributions if you don't open up the possibility! 🙂
Claim: Distracted Dev Team.
- My Response: Open-sourcing aligns with Orion's focus on privacy and could be seen as an extension of current development efforts, not a distraction from them.
Claim: Intellectual Property.
- My Response: IP concerns can be mitigated through careful licensing (MPL 2, AGPL, etc).
Claim: Lack of Readiness.
- My Response: Open-sourcing can be a gradual process. Starting with code publication doesn't require being fully "equipped" for managing a large open-source community immediately.
Claim: There's Already Privacy Verification (LittleSnitch).
- My Response: While zero-telemetry is great, open-sourcing allows for independent verification and validation of the source code, which builds even more trust in the privacy-conscious community.

Other Ideas:

Open-sourcing can help build a stronger community around orion, potentially leading to more users, advocates, and eventually contributors.
In the privacy-focused browser market, being open-source can be a significant selling point, potentially giving Orion an edge over closed-source competitors.
More eyes on the code could lead to faster discovery and reporting of bugs, even if the community isn't actively contributing fixes.
Open-sourcing can ensure the project's longevity, as the community can potentially maintain it even if the original team can't.
Many of your concerns can be addressed by adopting a gradual, phased approach to open sourcing, starting with simple code publishing/publication and slowly opening up more as the project and team grow.

I'd like to gather your thoughts on open-sourcing Orion. I believe this could be a significant step forward for the project and the product as a whole. I’d like to gently ping @eirk , @gp , @laiz , @TheOtherKai . As active contributors to the project, your input would be invaluable in shaping this decision. Open-sourcing Orion would be a significant step forward for the project, and I believe your perspectives would help inform this move. Additionally, as contributors who are already engaged with the community, your insights on the potential benefits and challenges of open-sourcing would be particularly constructive. I'd also like to gently ping @dino , who appears to be the senior software engineer for Orion, to share his expertise on this matter, especially given the concerns around management and team resources that Vlad mentioned. Your collective input would help ensure that we make an informed decision about open-sourcing Orion. Open-sourcing Orion (eventually) would likely require contributions in various forms, including code and other areas such as documentation. Given your active roles within the community, I believe your opinions on this topic would be both prudent and constructive.

Skye

I'd like to add on to @Anatomy5803 above with some more notes

Open sourcing Orion, from a management point of view, would move the existing teams manhours from active coding to vetting code submissions.

In the time it would take one coder to write one feature, they can review the work of multiples more coders. Even if you assume that 80% of pull requests do not meet the standard of the project, it would take the same amount of time to get the work done with significantly less cognitive load from your team.

Through a process of interacting with open source contributors, you can utilize your trusted team to create more trusted contributors. It is true that there might be a dearth of talent initially, but as this grows - you will effectively be training contributors in WebKit.

Secondly, the increased visibility that comes with open-sourcing the project will open new avenues towards donations/funding. Contributors to open source projects tend to be zealous advocates once they get going.

Further, IP can be protected through several means. I'm sure Kagi inc has already trademarked the Orion branding - but one can go further and patent the implementation of the browser itself. If the project becomes open source & key aspects of the browser are patented there is little risk of IP theft.

To add onto this, it is very important to license the project under something like the FUTO license that aims to be copy left for the source code, but restrictive on the monetization (which is the ultimate goal anyway). Perhaps a custom license modelled on an existing license like the AGPL could be useful.

Lastly, security vulnerabilities can occur in systems that are extremely well designed even. A browser being the gateway to the modern world should require security at the same level as an operating system - especially given how complex it is. More eyes here the better.

Some of the largest open source code bases that exist today started out as projects by a single person in a basement. The biggest failures have been because of failures in resource management and funding to keep the project going.

« Previous Page