81

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:

  1. Increased trust and transparency, allowing users to verify zero-telemetry claims.
  2. Potential for community contributions, even if limited initially.
  3. Improved bug reporting and feature requests with direct reference to source code.
  4. Attraction of privacy-focused developers and potential future hires.
  5. 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 replied to this.

    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.

        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 10 people, I definitely think it can be manageable given the steps I outlined.

        • Vlad replied to this.

            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.

                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?

                • Vlad replied to this.

                    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.

                    Related: https://orionfeedback.org/d/7335-feature-freeze/3

                        7 days later

                        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):

                        1. 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.
                        2. 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.
                        3. 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.
                        4. 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.
                        5. 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.
                        6. 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! 🙂
                        7. 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.
                        8. Claim: Intellectual Property.
                          • My Response: IP concerns can be mitigated through careful licensing (MPL 2, AGPL, etc).
                        9. 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.
                        10. 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:

                        1. Open-sourcing can help build a stronger community around orion, potentially leading to more users, advocates, and eventually contributors.
                        2. In the privacy-focused browser market, being open-source can be a significant selling point, potentially giving Orion an edge over closed-source competitors.
                        3. More eyes on the code could lead to faster discovery and reporting of bugs, even if the community isn't actively contributing fixes.
                        4. Open-sourcing can ensure the project's longevity, as the community can potentially maintain it even if the original team can't.
                        5. 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.

                          2 months later

                          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.

                          3 months later

                          • Aahk

                            • Post #36
                            • Edited

                            Hackmodford

                            Hate to bring this up again, but two questions:

                            1. How can a user verify the zero telemetry claim?
                            2. @Vlad is there a way to verify that the scenario laid out by @Hackmodford where in telemetry is stored locally and and only transmitted when a testing tool is not being used, without sharing source code.

                            EDIT: clarified my question

                                ahk 1 and 2 can be verified by inspecting the source code and compiling the program locally.

                                • ahk replied to this.

                                    • Aahk

                                      • Post #38
                                      • Edited

                                      Hackmodford

                                      Right. I guess I should have said how can we clarify those without sharing source code.

                                      I should also note that I do think making the browser open source would be ideal, and I’m skeptical that zero telemetry can be verified without that. But I’m not an expert in privacy or security so I am genuinely curious if there’s a way to even do that without making the code public.

                                          • Vlad

                                          • Post #39
                                          • Edited

                                          ahk Anyone can install a network proxy (Proxyman, mitmproxy and Charles are good options on macOS). With Orion, you’ll see zero unexpected requests in your network traffic log by default. It takes 5 minutes to set this up vs going through millions lines of code.

                                          The outlined scenario is not realistic as Orion doesn't know when traffic is being monitored and doing something like this makes no sense.

                                              @Vlad If Orion uses SafariConverterLib, that's licensed under GPLv3, and so is AdGuard Scriptlets. Meaning any code Orion uses that is derived from those or uses those projects needs to be open source'd as well. The derived work is the combined entire program according to GPLv3. I mentioned this to @dino and he stated he would liaison with your legal team or the specialists at Kagi that deal with this stuff. I'm not an expert in copyright law, but under the terms of GPLv3, Orion or at least a part of it, needs to be open source. Not doing so would constitute a copyleft violation.

                                                • Vlad

                                                • Post #41

                                                Anatomy5803 We are aware and we will not be using a GPLv3 lib in Orion.

                                                    2 months later

                                                    In the Orion FAQ the question "Is Orion open-source?" is answered enthusiastically with "We're working on it!". (https://help.kagi.com/orion/faq/faq.html#oss)

                                                    I think I misinterpreted this to mean that the team is actively working on this and we can expect this soon. However, from the discussion here and on Discord I understand that for various (legitimate and understandable!) reasons this is currently not a priority. Should the FAQ be updated?

                                                    (I don't know if enough users feel this way, but if Kagi were to provide a concrete timeline for going OSS, I would definitely add Orion+ to my Kagi subscription.)

                                                    No one is typing