Directed towards LSPDFR team & contributors

 

From the few threads I've seen mentioning the issue, none have received a straight answer as to why LSPDFR (not LCPDFR) is closed-sourced (proprietary). It seems like the perfect software that could benefit from community contributors. With a wide range of performance issues and to-do features, allowing the rather large existing developer community (any C# developer with a little RagePluginHook knowledge) to make pull-requests or fork the software (if the added features don't align with the official vision) would only benefit everyone.

 

For example, the official team rejects the suggestion of natively implementing some of the heavily requested features from the no longer supported StopThePed. If open sourced, any random C# developer could come along and create a fork for anybody who wants those features. Having more people look at (and diagnose) the code will also help spot performance weak-spots. Similar to how some hacker found a way to reduce GTA5 load times by 70% 8 years after the game released. Even with the resources of a multi-million dollar company, having more random developers look at the code can still vastly benefit.

 

Unless I'm missing something, I see no reason for the community-driven software to remain proprietary. Open-sourcing would garnish more donations, better performance, and overall help advance the software. Licensing it under something of a GPL/AGPL license could prevent people from selling forks and taking credibility away from the official project.

 

Similar threads that don't actually address the issue:

 

Please note that my response does not represent G17 Media as a whole and are PURELY my own thoughts!

 

5 hours ago, Cowz said:

none have received a straight answer as to why LSPDFR (not LCPDFR) is closed-sourced (proprietary)

While I cannot answer this directly as this would be up to the Founders to provide a clear answer. I do believe that G17 have provided the proper API to people to expand upon the base version of LSPDFR and make their whole content that builds the community up and provides diversity. 
 

5 hours ago, Cowz said:

With a wide range of performance issues and to-do features

Any performance issues that are encountered are most likely attributed, but not limited, to one of the following: mods, additional plugins, graphics enhancements. LSPDFR on its own is fairly stable if you have the right PC to run GTA V comfortably.
 

5 hours ago, Cowz said:

For example, the official team rejects the suggestion of natively implementing some of the heavily requested features from the no longer supported StopThePed.

Which specific features? The ones I have heard of the most (tow truck and coroner) may make sense from a user standpoint. But on the other hand, not including features gives the community a chance to contribute their own work and make the mod feel more like a community effort and less like just LSPDFR implementing the features and the community hoping their content will get added in some future version. Its power to the players!
 

5 hours ago, Cowz said:

I see no reason for the community-driven software to remain proprietary

It's as you say here, it's community-driven by allowing people to use the API to make a variety of different things! It just isn't the level of community-driven that you are seeking.

Appreciate your time reading and have a good day!

Edited April 9, 20233 yr by UnknownBastion

Here is how I see it, they made it, they own it, and they don't have to even provide us with it.
It would be interesting to see it opened up, but I imagine a lot problems doing so.

One issue, say people make forks that just don't work well or cause issues, imagine the cluster fuck of reports that would come here blaming the original devs. I can foresee a lot of problems with that.

As for not implementing features that exist as external plugins, I can see why. Don't fix what aint broke. It doesn't make anything run better just because it's built in and frankly it would probably break the plugins that provide these feature pissing off the plugin devs. The API works really well, and if it's missing something important LMS or whoever will most likely add it in a future version. They are pretty good at helping out plugin devs.

On top of that, LMS stated
"would also need a clean up in some areas (server communication, authentication) to remove sensitive stuff."

There are pros and cons to it. I really think they are on the right track by providing a good API allowing us to add features as neatly packed files for it VS having people release different forks with different feature sets that are not compatible. "Hmm should I choose the fork with tow trucks, or the fork with better ped interactions?" In the current state they're just plugins so they can be added as needed.

3 hours ago, SuperPyroManiac said:

Here is how I see it, they made it, they own it, and they don't have to even provide us with it.
It would be interesting to see it opened up, but I imagine a lot problems doing so.

One issue, say people make forks that just don't work well or cause issues, imagine the cluster fuck of reports that would come here blaming the original devs. I can foresee a lot of problems with that.

As for not implementing features that exist as external plugins, I can see why. Don't fix what aint broke. It doesn't make anything run better just because it's built in and frankly it would probably break the plugins that provide these feature pissing off the plugin devs. The API works really well, and if it's missing something important LMS or whoever will most likely add it in a future version. They are pretty good at helping out plugin devs.

On top of that, LMS stated
"would also need a clean up in some areas (server communication, authentication) to remove sensitive stuff."

There are pros and cons to it. I really think they are on the right track by providing a good API allowing us to add features as neatly packed files for it VS having people release different forks with different feature sets that are not compatible. "Hmm should I choose the fork with tow trucks, or the fork with better ped interactions?" In the current state they're just plugins so they can be added as needed.

Blaming original devs for issues caused by a fork can be easily prevented by adding a popup and ignoring anyone who isn't using the official branch. The API works great, I've used it myself to create some things but it doesn't provide the amount of flexibility that source code has. Try taking a look at Minecraft, specifically Spigot which is a similar software with core features as well as plugin support. It's open source and has been forked numerous times for more specific use cases (PaperMC) and has over 500 contributors with performance enhancements and other QOL features that would've otherwise been overlooked. Even though more people use forks of their software than the official branch, there are barely any issues with plugin incompatibility or bug reports going to original developers. The people know that it's the responsibility of the fork to ensure plugin support and fix any issues.

 

More than anything, I think the largest benefit would come to performance. You seem to underestimate the impact that leaving the code open for a year or so will do. When developers go to study parts of the software for their own reasons, any imperfections in the code will be hoisted. Even having a multi-million dollar software engineering team won't get you the same performance as open-source with a large community (LSPDFR already has, just isn't using it to it's full advantage). 

 

4 hours ago, UnknownBastion said:

Any performance issues that are encountered are most likely attributed, but not limited, to one of the following: mods, additional plugins, graphics enhancements. LSPDFR on its own is fairly stable if you have the right PC to run GTA V comfortably.

LSPDFR is a massive performance killer, running it solo (no other mods) with very high texture quality will 10/10 times cause texture loss within an hour. It also halves my FPS (from about ~140 to ~80). I'm sure the developers have looked into it extraneously, but so did the 6-figure GTA5 developers with multiplayer load times. 

7 hours ago, Cowz said:

Blaming original devs for issues caused by a fork can be easily prevented by adding a popup and ignoring anyone who isn't using the official branch. The API works great, I've used it myself to create some things but it doesn't provide the amount of flexibility that source code has. Try taking a look at Minecraft, specifically Spigot which is a similar software with core features as well as plugin support. It's open source and has been forked numerous times for more specific use cases (PaperMC) and has over 500 contributors with performance enhancements and other QOL features that would've otherwise been overlooked. Even though more people use forks of their software than the official branch, there are barely any issues with plugin incompatibility or bug reports going to original developers. The people know that it's the responsibility of the fork to ensure plugin support and fix any issues.

 

More than anything, I think the largest benefit would come to performance. You seem to underestimate the impact that leaving the code open for a year or so will do. When developers go to study parts of the software for their own reasons, any imperfections in the code will be hoisted. Even having a multi-million dollar software engineering team won't get you the same performance as open-source with a large community (LSPDFR already has, just isn't using it to it's full advantage). 

 

LSPDFR is a massive performance killer, running it solo (no other mods) with very high texture quality will 10/10 times cause texture loss within an hour. It also halves my FPS (from about ~140 to ~80). I'm sure the developers have looked into it extraneously, but so did the 6-figure GTA5 developers with multiplayer load times. 

You can't really compare Bukkit/Spigot/Paper to LSPDFR. They get access to the Minecraft Server source code. MC can be easily decompiled which gives a lot of power to modders. GTA is very against modders and made it clear in the past. They also tried to DMCA OpenIV in the past.

As for performance, the game itself love to hog 1 CPU core, and the mods for it also live there. That's just a flaw with how GTA is made. Putting a lot of scripts into 1 core on a heavy game tends to make the CPU go brrrrrrrrr.

It would be cool to see an open source LSPDFR but from what I have personally seen with this community I doubt we would see anything crazy come from it.

Edited April 9, 20233 yr by SuperPyroManiac

3 hours ago, SuperPyroManiac said:

You can't really compare Bukkit/Spigot/Paper to LSPDFR. They get access to the Minecraft Server source code. MC can be easily decompiled which gives a lot of power to modders. GTA is very against modders and made it clear in the past. They also tried to DMCA OpenIV in the past.

As for performance, the game itself love to hog 1 CPU core, and the mods for it also live there. That's just a flaw with how GTA is made. Putting a lot of scripts into 1 core on a heavy game tends to make the CPU go brrrrrrrrr.

It would be cool to see an open source LSPDFR but from what I have personally seen with this community I doubt we would see anything crazy come from it.

Minecraft is not easily decompiled and Mojang has also tried to DMCA Bukkit in the past. Spigot has also had the issue of single-core performance and it the issue was largely ameliorated by Paper (a fork). The two are much more similar than you think. I really do think you'd be surprised what the community can do with source code. I think there'd be lots more QOL/performance improvements added to main branch and we'd be able to see large spin-off branches with different visions as well.