Consider Open Source way?

Was auch immer nicht in die anderen Themenbereiche passt.
Oshino
Beiträge: 10
Registriert: Di 18. Aug 2020, 22:16
Hat sich bedankt: 4 Mal
Danksagung erhalten: 0

Re: Consider Open Source way?

Beitrag von Oshino »

Thanks for the consideration and open discussion of this topic!
May I ask, what are the reasons speaking against becoming a MF Bot developer?
I wouldn't exactly say that I'm not interested in becoming a MF developer, but it feels a bit over the top to "join a team" just to contribute some minor patches. The developers I know are rather like free folk that does not like too many chains - but given an open code base they can figure most things out themselfes and create a PR.

Furthermore I believe that most of the problems that occur when open sourcing the project can be solved or reduced to an inconvenience. Let me add a different view to those problems:
1) Mushroom and Ad bots - Our concern is that once our bot code is Open Source, there will be mushroom and ad bots again. While we believe that Playa is condoning our bot as we enable a good part of traffic on their server, we do not think that they will tolerate any kind of harm that that could affect their users (mushroom bots) and especially their income (ad bots)
This is a very important and most likely true statement - as long as MFB does not reduce the income of Playa Games, everything should be fine.
But: Your current implementation does not include any code that infers with their monetizion strategy. As far as I'm concerened, the only way to exploit it at the moment would be automatically watching the "Flimmerkiste" - this cannot be archived using the REST/JSON -API of S&F, so your code base should be of no help for a potentially malicious party.
2) Licencing - As we use a lot of images from Playa, I don't think we are allowed to share them publicly
To play the devils advocate: Aren't you already sharing them publicly? :-)
You could tackle this problem by simply not shipping assets as part of your repository. The default build process could be adjusted that it downloads all assets directly from S&F - so you don't distribute it yourself. This is a "standard practice" for many similar projects.

I really don't want to _push_ you to make this project open source, just lower the barriers for it :-)
Cheers!
Benutzeravatar
Robin
Administrator
Beiträge: 1723
Registriert: So 30. Jun 2013, 18:12
Wohnort: Rheinland-Pfalz
Hat sich bedankt: 303 Mal
Danksagung erhalten: 354 Mal

Re: Consider Open Source way?

Beitrag von Robin »

Hi there!
At this point, I'd also like to respond to a few things to keep the discussion going - in general, I actually really like open source projects and contributing to them, this project however is a bit different especially because of the amount of people that worked for it over the years.

The thing is: A project can grow and evolve a lot if it's open source, but if there are not enough contributors/activity, repositories tend to grow their own legs - in other words: they will just get forked, developed separately and thus aren't really controllable in any sense anymore.
As Forest already wrote, that would eventually lead to possibly worse written bots that not only could increase the load on the game servers, but also probably wouldn't consider the fact that bot users are right now only tolerated because they are not really harmful.
Additionally, there was in fact someone in the past that tried to sell the bot. If now someone would add malicious code to the open source base, compile and sell the bot, that could reflect really badly on the MFBot and in the end on the bot users themselves.
it feels a bit over the top to "join a team" just to contribute some minor patches
I understand the problem of wanting to contribute freely but not in a team-sense - I think I wouldn't have made a lot of contributions if I would have had to join a team first.
Your current implementation does not include any code that infers with their monetizion strategy [...] so your code base should be of no help for a potentially malicious party.
That is actually not wrong, I hadn't thought about that. On the contrary, it wouldn't be that simple to even integrate that in our code base since it's not built for the kind of interface the Flimmerkiste seems to use.
To play the devils advocate: Aren't you already sharing them publicly? :-)
In short: Yes, and we really, really hope that this doesn't cause a problem in the future. :D
Technically, we use/show them and we don't distribute them in a way for others to copy/share, but the main point of copyright law is the usage of copyrighted material, so that would be a problem nonetheless if someone decided to sue me.
You could tackle this problem by simply not shipping assets as part of your repository.
That would be possible, but..
The default build process could be adjusted that it downloads all assets directly from S&F
.. this wouldn't be quite that simple. At the moment, the assets we use have mostly been extracted from the old (SF 2.0) client, so an automatic download would at the moment technically be more or less possible for the most part (and actually was planned a few years ago), but we can't really know how long the resources are still available.

With this point, that brings us to another problem: If we can't make the whole repository public, we also complicate things for our development as we would have to use another repository or get the missing stuff by adding another step to the check-out process.
Also: Maybe I haven't got enough experience with this type of project, but if the repository doesn't contain everything you need to build, nobody can really build the bot and test their changes - a possibility I think is critical for good code change requests.
The only thing holding me back is the closed-source (and non-git) nature of it.
Just a remark here: Internally, we use git and with Gitlab we also use the whole package around it - Issues, Pull Requests etc., therefore it would technically not be that big a problem to migrate to GitHub or another git-based platform in a VCS sense. It might take time and the build process might even be a more difficult topic, but in general it wouldn't be impossible.

Additional to the above mentioned points, I also see a problem with the code base itself:
1. We haven't really got a documentation of the code. Methods, classes etc. do in general have documentation comments and the code itself does also have explanatory comments, but that's it. Without any proper documentation, I'd rather not make anything public.
2. At the moment, we are kind of in a "split state" in our code.
There are two main development branches: One that is used for the current releases (v5.x) and another one that is being developed in parallel (v6.x) because we want the second one to take over.
At the moment, the second one can't take over because in that branch we made the mistake of mixing general code cleanup with a rewrite of some of the bot's mechanics which doesn't seem to work as efficient as the implementation in the v5.x series yet.
If someone would contribute code, we would have to do some work to integrate it in both version branches as the 6.x one has some largely rewritten areas and code can therefore not simply be merged between them.

V6.x was supposed to have a good documentation and a much cleaner code base - and we've come far with that, but due to the lack of time it'll still take a while to finish it.

I hope I was able to bring some additional light into why we didn't open source the code yet.

Regards,
Robin
MFBot-VersionCode-Zeilen*In Dateien*Letzte Version
MFBot 1.5.x64851Juli 2013
MFBot 2.x1436316März 2014
MFBot 3.x2209536März 2015
MFBot 4.x55242241Juli 2018
MFBot 5.x66000440Tbc
*Ohne automatisch generierten Designer-Code
Oshino
Beiträge: 10
Registriert: Di 18. Aug 2020, 22:16
Hat sich bedankt: 4 Mal
Danksagung erhalten: 0

Re: Consider Open Source way?

Beitrag von Oshino »

Hi Robin, thanks for joining the discussion!

Reading through your views made it clear to me that there can't be a clear "yes" or "no" to this topic as it is always a consideration of pro and contra arguments.
Thank you very much for giving us these valuable insights! Given the situation, I understand why it is held privately.

Now - given the current situation - it happens that I've got some spare time myself and would like to add some contributions, be it OS or not!
As a day-to-day developer I'm comfortable with cherry-picking changes between two diverging branches, so I think that would not be too much of an issue.

Do you need a hand on some issue or feature? :-)

Best,
Oshino
Antworten

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast