What's unfair is SM's treatment of a developer that is working on a solution for free for the number 7 feature request that SM faces from its customers.
I know that SM has supported SE from the get go. It's one of the reasons I bought a license. And I believe that if there was an issue of similar magnitude, while the application would be suspended in a similar fashion, that Nikolai and the SE users would not be shut out as coldly as Liangzan and smugftp users have. Like I said, I don't know the reason as it doesn't make sense, but I'm convinced there is one beyond the technical issues.
I mean, if there's a technical issue on BETA software, you keep going back and forth and get it to work, not just shut it off and be done with it. Unless you really don't want it to work in the first place. If that's the case, be straightforward about it and quit wasting everyone's time.
What's unfair is SM's treatment of a developer that is working on a solution for free for the number 7 feature request that SM faces from its customers.
I would like to remind you that in Mikka's message, he offered to re-visit their decision should the situation with smugftp change. That seems pretty fair to me.
I could make some more comments on product development in a production environment but I won't. I think it's safe to say we disagree and leave it at that.
Moderator Journeys/Sports/Big Picture :: Need some help with dgrin?
I would like to remind you that in Mikka's message, he offered to re-visit their decision should the situation with smugftp change. That seems pretty fair to me.
Per my conversation with the author, the situation has changed, but this decision by SM still stands. It's one thing if there was communication, but it just seems as if SM simply slammed the door on smugftp.
I could make some more comments on product development in a production environment but I won't. I think it's safe to say we disagree and leave it at that.
I don't doubt that there are development factors involved. But my experience with SM has shown that there's also a lot of 'just because' decisions being made too.
I agree that we disagree. And I appreciate that we are able to have this civil discussion on the matter even though we both passionately stand behind our positions.
We all ding SmugMug when uploads are slow or they go down, sometimes pretty hard.
I'm assuming that at one point SmugFTP had some kind of effect on overall upload performance. Once that happens it's pretty easy for me to see why SmugMug would be incredibly skittish, even reactionary, about letting that app run, until they were 100% confident the slow down would not happen again.
Per my conversation with the author, the situation has changed, but this decision by SM still stands. It's one thing if there was communication, but it just seems as if SM simply slammed the door on smugftp.
I don't doubt that there are development factors involved. But my experience with SM has shown that there's also a lot of 'just because' decisions being made too.
I agree that we disagree. And I appreciate that we are able to have this civil discussion on the matter even though we both passionately stand behind our positions.
We all ding SmugMug when uploads are slow or they go down, sometimes pretty hard.
I'm assuming that at one point SmugFTP had some kind of effect on overall upload performance. Once that happens it's pretty easy for me to see why SmugMug would be incredibly skittish, even reactionary, about letting that app run, until they were 100% confident the slow down would not happen again.
I understand that as well, but to not want to cooperate on helping debug a BETA software just shows a lack of interest on SM's part on making smugftp a reality.
It's ultimately up to SM as far as what will work with their API, but they should be more overt about it if they don't want such a feature. Don't waste the developer and users' time.
With a heavy heart, I've decided to shut SmugFTP down. The main reason
is Smugmug has suspended me. I feel a need to give my side of the
story.
What happened is a mistake in the app resulted in SmugFTP pounding
Smugmug's servers on 2 separate occasions. As a result, Smugmug has
decided that SmugFTP is not stable enough. And they decided to
suspend. The mistake in the code is my fault. But as we know, SmugFTP
is still in beta. I'm human. I make mistakes too. I can only try my
best. I already apologised and patched the code(while on vacation).
But the decision to suspend still stands.
I doubt I can continue with Smugmug being unsupportive. Thanks for the
support everyone! I suppose I'll simply move on to build other stuff.
Not on smugmug next time though
--
Wong Liang Zan
liangzan.net
Unfortunately, this is a different story from what SM is saying, and confirms what I suspected.
Regardless, it seems as FTP is still a demand without a supply. And with this precedent of SM treatment towards a FTP developer, I feel another developer will be hesitant to take on the task of a third party application that supports FTP. This is not good.
Unfortunately, this is a different story from what SM is saying, and confirms what I suspected.
Regardless, it seems as FTP is still a demand without a supply. And with this precedent of SM treatment towards a FTP developer, I feel another developer will be hesitant to take on the task of a third party application that supports FTP. This is not good.
What was Smugmug's actual response? What did they say when he offered to fix the issue and make sure his code was well-behaved?
Comments
I know that SM has supported SE from the get go. It's one of the reasons I bought a license. And I believe that if there was an issue of similar magnitude, while the application would be suspended in a similar fashion, that Nikolai and the SE users would not be shut out as coldly as Liangzan and smugftp users have. Like I said, I don't know the reason as it doesn't make sense, but I'm convinced there is one beyond the technical issues.
I mean, if there's a technical issue on BETA software, you keep going back and forth and get it to work, not just shut it off and be done with it.
Want faster uploading? Vote for FTP!
I would like to remind you that in Mikka's message, he offered to re-visit their decision should the situation with smugftp change. That seems pretty fair to me.
I could make some more comments on product development in a production environment but I won't. I think it's safe to say we disagree and leave it at that.
I agree that we disagree. And I appreciate that we are able to have this civil discussion on the matter even though we both passionately stand behind our positions.
Want faster uploading? Vote for FTP!
I'm assuming that at one point SmugFTP had some kind of effect on overall upload performance. Once that happens it's pretty easy for me to see why SmugMug would be incredibly skittish, even reactionary, about letting that app run, until they were 100% confident the slow down would not happen again.
http://www.danalphotos.com
http://www.pluralsight.com
http://twitter.com/d114
It's ultimately up to SM as far as what will work with their API, but they should be more overt about it if they don't want such a feature. Don't waste the developer and users' time.
Want faster uploading? Vote for FTP!
We cooperate plenty, and Markham and Miikka will be and have been in touch with the developer.
Portfolio • Workshops • Facebook • Twitter
http://www.dgrin.com/showpost.php?p=1631237&postcount=31
Unfortunately, this is a different story from what SM is saying, and confirms what I suspected.
Regardless, it seems as FTP is still a demand without a supply. And with this precedent of SM treatment towards a FTP developer, I feel another developer will be hesitant to take on the task of a third party application that supports FTP. This is not good.
Want faster uploading? Vote for FTP!
Homepage • Popular
JFriend's javascript customizations • Secrets for getting fast answers on Dgrin
Always include a link to your site when posting a question
Want faster uploading? Vote for FTP!
Want faster uploading? Vote for FTP!
This is great...hope it works out this time......
Keep up the great work Liangzan