Attribution
siegesmund opened this issue · 3 comments
So, I am the author of SwiftDDP, now archived on Github. I had a look at the library you announced and found that it was mostly my code - sometimes with files renamed or rearranged, but always with the copyright stripped. Note that the MIT license notice beneath the copyright that you removed forbids removal of the copyright. What you are announcing is a fork of SwiftDDP, not a new library. You do note that it's a new version of SwiftDDP in the readme, but that's it.
I want to let you know that this is a bad way to contribute to open source. It's taking others work and presenting it as your own and it's a sure way to generate bad will among fellow developers. Perhaps more importantly, muddling the license situation means that the software is less likely to be adopted commercially. Presumably, by trying to create an open source library, you want others to adopt it and contribute to it. This hinders that.
I stopped working on SwiftDDP for a variety of reasons. One of the reasons was that the connection to the server can be frustratingly unstable in real-world use. Sometimes, this didn't show up in casual use, or in the simulator, but it was enough of an issue that I could never have used it in a production application. A look at your code (my code) suggests that package you have published will share this issue. I suggest you look into that.
I'm sure that there are people who would welcome an updated Swift language Meteor client. The correct way to do this is to present it as an updated fork of SwiftDDP, with proper attribution, not as a new piece of software that you have authored.
@siegesmund Thanks very much for your concern.
To avoid this inconsistency, I have edited the readme file and remove that "newer" term for this library. My intention is not as you assumed, but I was just maintaining this library as its been archived on your repo and no pull requests or issues can be made to maintain that library. I truly appreciate your efforts and the code (although I just rearranged according to my understanding, as I expect future enhancements in this library in the same repo), yet I mentioned clearly the reference where I took it originally.
Being an open-source contributor is not like to have a newer code from scratch to put in the opensource market every time, but even to extend/modify the existing codes with new approaches and allow them to remain compatible with upcoming versions of tools.
Hence, when I will put new functionalities in this library, the original author's credits would remain in the history of this library.
Thank you once again to have this concern and feel free to chat me on email if you still having some concerns related to this library. Wish you all the best!
One of the reasons was that the connection to the server can be frustratingly unstable in real-world use.
what is this mean? is this problem caused by ios?
we're trying to experience swift MeteorDDP, how unstable for example?
I also would like to use it, but am now concerned about its stability.
@siegesmund Did you ever find out why the library was so unstable? I had already improved an existing DDP library for C# in the past, to make DDP work in Unity. In my experience, the biggest problem was the WebSocket connection that broke up as soon as the app is being put in the background. So I had to workaround this by reconnecting. Apart from that, that library ended up being pretty stable.
I am now looking for a native Swift alternative, as I want to implement a connection to a Meteor server on visionOS. Would be cool if you could share your insights / experiences. Thanks.