81

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
      • 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.
          • 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.

            • 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.

                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