I'm officially stopping development for my SabreAMF and Dropbox php library. I'm using neither myself anymore, which is detrimental for my interest and time I devote. So I felt like it's better to make it official.
I'm hoping for both projects they get forked and picked up by other people. I'm happy to transfer control of the sites to a different developer, if he or she can show good coding skills and some dedication. Dropbox-php has a mercurial repository so it's easy to clone / fork, and I just migrated SabreAMF from svn to git(hub).
Dropbox
Dropbox was a short ride. When the API first came out I had some projects in mind I wanted to write for it. Since there wasn't a PHP library yet, I took it upon myself to write one. My interests quickly moved to different subjects though. Bugs are there, and left unrepaired for too long. If you know of a good replacement library, post it in the comments.
SabreAMF
While the Dropbox lib is from pretty recent, SabreAMF is from somewhere early 2006. It was my first open source project, and it has been quite a ride. It's interesting to think back to where I was in life back then.
It kind of went downhill when Zend_AMF got released in late 2008. Originally I was helping the (paid) developer with the implementation, but then communication went silent. I only heard about it again when it was announced with much fanfare as the Adobe/Zend partnership.
This left me with a bit of a sour taste. The developer at the time was struggling with decoding the AMF0/3 bits, which was just released as an open spec at the time. Originally the AMF0/3 specification was closed, and as far as I know, there were no open source implementations. It took me several months of reverse engineering to figure it out exactly. This was probably also largely due to the fact that I had little experience in this field and never seen a variable width binary-encoded 29-bit integer before. So I was mostly doing it blindly (with help from the excellent Karl Von Randow and Kevin Langdon). Having a working implementation after that time felt like a great achievement.
After checking out Zend_AMF, I found that the developer didn't bother trying decoding himself, but effectively just took my design and renamed a few methods. Mind you, these were only a couple of classes, but they were the core of the project and my blood sweat and tears. I wouldn't have minded this if I could have been a part of it (which I thought I did for a bit), but it wasn't handled very decently. Since then the Zend_AMF library has greately improved, so the evidence is stowed away in much older subversion revisions.
I hope this doesn't come across bitter. I mean no harm to said developer, his perspective may well be very different from mine. I just wanted to write this out as therapy, as this has been bugging me personally for several years.
However,
I had tons of fun and learned even more. Very much a thanks to the users, and the people that helped me out in various occasions. I still believe there's room for a 'SabreAMF', as the main message I've always heard from people was that the alternatives are too heavy.
I've since then moved away from flash-work as much as possible, with the exception of the occasional feature that flash provides well, but browsers don't yet (video). If you're thinking you need an 'AMF'-like solution, I would first highly recommend to see if JSON does not already fit your needs. There are some benefits to the binary protocol, but they only tend to apply with large scale. Most people don't fit in that category. If you do, check out Zend_AMF.
Interesting how things went with Zend_AMF. In a way I feel its good news that they took your code, because their CLA kind of causes one way open source. Aka they cannot build on other peoples work. Then again this it sounds like this means that the contributor probably misrepresented things when he made the contribution. Meaning that if Zend is serious about their CLA, they need to pull the code or work out a deal with you to fix the situation.
From my perspective the CLA implies that if somebody gets sued over using unlicensed code, the contributor is effectively liable, and not Zend or ZF users.
But yea the code and structure changed quite a bit, so I don't know if that's very relevant.
Hi Evert,
just a quick line to say I still use SabreAMF a lot and prefer it any day over Zend_AMF.
It has taught me a lot about good OO design.
Thanks a million for a great library!
Marijn
Hi Evert,
My understanding of the CLA is that if a contributor used your original code without permission, and without having you sign it over under a CLA, then distributing that code would be illegal. I, for one, would have raised a sh** storm with Zend. Was there any particular mitigating circumstance why Zend are allowed to distribute a derivative of your original work?
Paddy
@Evert: right .. with the CLA Zend and all ZF users are "safe" from damages. However once alerted they need to fix the infraction (which I did via twitter http://twitter.com/weierophinney/statuses/55801354018492416). But yes the guy who did sign the CLA and contribute the code without permission would be liable though I would guess that even if you would go all out most courts will just say "you gave the code away for free anyway" leaving the only angle with "lost opportunity to be famous" or getting a chunk of the money they guy was paid by Adobe or Zend or whoever commissioned Zend_AMF.
@Padriac,
The reason they were allowed/able to distribute was because I haven't made a fuss out of it.
My guess is that the developer found himself in a tight spot when he found out he wasn't able to deliver exactly. That's something I can relate to, although not how he handled it.
Evert,
thanks for a great library. Maybe you'll appreciate the irony in me using sabre to unittest a zend implementation (by using sabre as a client).
take care