80

I also agree in open sourcing the browser, at least eventually. While it may seem hard managing an open source project, many software projects eventually make it possible to work. We can look to other software projects (especially those with small teams) who have done it before for inspiration. I echo domderen's idea that perhaps an open source community manager could alleviate some burdens of management. The benefits of open sourcing can outweigh the drawbacks of not.

Open sourcing the browser can be a controlled roll-out, using an interative approach (open sourcing each component by importance/priority over time).

Some other ideas for a good open source project:

  • Modular codebase
  • Suitable license (perhaps even fair code not fl/oss)
  • sufficient code documentation
  • project overview documents (architecture, components, design philosophy)
  • development guide documents (setup, coding style, contribution guidelines)
  • clear roadmap
  • rigorous code review process

All of this can also help the team currently (minus the license part)

In the future, one thing could help (with either Orion being closed or open source) would be delegating certain parts of the code base to a certain person (perhaps like Linux does).

5 days later

Lenni-builder yup there is a difference between publishing the source + build steps (so anyone can reproduce the build check & source code) and making it a community project (which may indeed involve some contributor management skills and effort). Please just publish the code. The community side can come later.

      4 months later

      It would be quite useful for you to at least open-source the WebExtension support, and possibly collaborate with Epiphany's WebExtension project (also WebKit-based). I also would like to reiterate that even publishing sources without taking contributions would be useful for other WebKit developers.

      20 days later

      Come on, Man! My main man! Why not tho? Ok an actual point. The Brave Browser already has the advantage of being open-source as well as its ability to offline download. Due to these things people may be more interested in using the Brave Browser over Orion. As well as for Safari, there already are Ad-Blockers that work for Safari as well as that SponsorBlock works much better on Safari, there may be people that think, if I am going to use a Browser that is proprietary and I don’t know what is being done with the code and Safari already has Ad-Blocker extensions and a more seamlessly working SponsorBlock extension, why would I download another app to do that and not use the one already provided to me on my phone that has it’s extensions work better than the way it is on Orion. I hope the people upstairs with Orion will take this into consideration.

      If this app became open-source, Firefox Focus would automatically no longer be competition to Orion and its only competition would be the Brave Browser. Which is open-source and has the ability to do offline video downloads. I really hope this is taken into consideration.

        Merged 2 posts from Open-Source.
          7 days later

          mightysashiman Why do you want them to publish the code?

          I can understand wanting to make it a community project, but just the source code published..?

          The browser is verifiably zero-telemetry which means it is impossible to not be 100% privacy focused.

              8 days later
              6 days later

              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 replied to this.

                  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.

                  • ahk replied to this.

                      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.

                          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)

                              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