Open Sourcing Resonite: Difference between revisions

From Resonite Wiki
No edit summary
No edit summary
Line 1: Line 1:
{{stub}}
We often get requests or questions as to why Resonite isn't open source. To clarify our stance on this, you can read this page.
We often get requests or questions as to why Resonite isn't open source. To clarify our stance on this, you can read this page.


Line 43: Line 44:
== Financial ==
== Financial ==
* Are there financial implications?
* Are there financial implications?
{stub}

Revision as of 02:09, 18 September 2024

This article or section is a Stub. You can help the Resonite Wiki by expanding it.


We often get requests or questions as to why Resonite isn't open source. To clarify our stance on this, you can read this page.

There are a number of key areas or categories of problems that make open sourcing Resonite hard. We may add to this list over time as items are added in response to questions.

Management

Open Source, is a lot of work. Once a repository is open source, community contributions would flood in. Community contributions require:

  • Code Review from YDMS for technical issues
    • Is this code good?
    • Does this code work?
    • Is this code malicious?
  • Design Review from YDMS for functional issues
    • Does this item fit Resonite's overall design?
    • Does this item break any existing functionality?
    • What about backwards compatibility.
  • General Communication
    • Ideally we'd have a dedicated person to handle this.
  • How do we handle disagreements?
    • A user makes a great PR but there's an issue and we disagree?
  • How do we handle forks?
    • How many forks will be created. What's our stance on those.

Without all of these items cleared and established, open sourcing would slow down development rather than speeding it up.

Workflow

  • Workflow Upgrades
    • We're working on items such as getting off of Unity and upgrading .NET. Until those items are complete the workflow of Resonite is a little rough. Its difficult to build and manage.
  • Time
    • The time to process, review, compile etc third-party contributions would take away from other items.

Legal

This is not, the primary reason for not open sourcing. But It must also be mentioned.

There are some legal issues to solve:

  • We'd need to decide on a license.
    • Licensing Froox Engine would need to be handled careful with a lawyer giving a review.
    • The goal here would be to ensure that the goals, ideas and business which rely on FrooxEngine can continue to exist.
  • Dependencies
    • There are some issues, with a couple of our dependencies that we'd need to re-work to open source.
    • Unity is not included in this, as open sourcing Resonite, does not require open sourcing Unity.
  • Protection
    • How can we ensure that Yellow Dog Man Studios, continues to exist when we do this?

Financial

  • Are there financial implications?