Comment by talawahtech | Hacker News Reader

Comment by talawahtech | Hacker News Reader

The first two paragraphs of this post come across as unnecessarily defensive and combative. Amazon released a product and then released an open source preview project to make that product easier to use. They even mention other similar projects (including Zappa) in the project README.

To hint at malice "...it felt like their interface and even their presentation of the product was a direct rip-off of our efforts" and then say "I don't want to attribute any direct malice" seems disingenuous. I feel like those fist two paragraphs could just be cut.

Many people have found the Lambda + API Gateway combo useful, but cumbersome which is why so many different projects have sprouted up to fill that gap e.g. https://github.com/serverless/serverless and https://github.com/claudiajs/claudia

Even AWS themselves have multiple preview projects in the same vein. There is another one just for Node.js that is designed to work with existing apps that were built for the Express framework https://github.com/awslabs/aws-serverless-express, so less lock-in there I guess?

It fine to promote the benefits of Zappa vs Chalice, including the fact that it avoids lock-in, but honestly the way the author approaches the comparison leaves a bit of a bad taste in my mouth.

I can empathize with the author and am familiar with the history of his project. In my case, I created a Python framework for the Alexa Skills Kit https://github.com/johnwheeler/flask-ask and worked on a blog post with Amazon. My hope was they'd appreciate my energy and passion for the Echo and work with me, but I feel like I've been largely ignored by them aside from being labeled an "Alexa Champion" which is meaningless to me.

As my framework is becoming more popular, I wouldn't be surprised at all if they released a competing framework locked-in to their infrastructure (after seeing how they did Chalice), and it's their prerogative to do that. But as a developer who made a high quality product people want, of course I'd rather they recognized the value I've created and worked with me instead of against.

They have zero obligation to, but if you're going to build on open standards and encourage community involvement, provide incentives for the community's hardwork aside from labels. Definitely don't disincentivize by doing wait-and-copy.

It goes the other way too. Isn't boto now the official python AWS library?

Just want to say, I ran across your framework very quickly after getting an echo dot. I am looking forward to using your much-easier-to-use-and-not-tied-to-aws framework for quick skill development.

Thank you for providing such a useful library! It is better than the amazon version!

Thank you!

I also am using your framework and I really like it. The quick video and dead-simple implementation made it a no brainer as a weekend project that can actually be published. Thank you.

Thank you :D

I applaud your hard work. It's only natural that we seek reward.

However, from Amazon's point of view, they did not ask you to build it or have obligations to reward you. They did give you a good social credit but it seems you are interested in more that is not entitled to you.

Like you said they have zero obligations and that's where the conversation stops unless you actively ask to be rewarded. Talk to their community make a thread on their forums, make it known and carefully explain your vision and how they are falling short.

Oh, social credits don't matter at all to me. I do appreciate the person at Amazon who gave it to me though for thinking of me.

So what do you actually want them to do?

They wouldn't just start throwing money at every project that has reached 1000 stars on github.

Open source projects are always about social credits or doing something for the fun of doing it. In rare cases when they aren't it's always responsibility of the author to find funding or come up with a business model.

> So what do you actually want them to do?

Adopt my framework and put me on the same playing field as their engineers in terms of information and resources. Flask-Ask is just way better than anything they have for Python. Even their Python related tutorials are terrible. Also, they're so focused on JavaScript they neglect a lot of important languages like Python and Ruby.

I could see them building their own Flask-Ask on top of Chalice, but I think it's counterproductive they push Lambda so hard for Alexa. Cross pollination I guess. Lamdba doesn't support WSGI (which Flask relies on and Lambda doesn't do unless you use Zappa). Personally, I don't think serverless is a panacea. It's good for some use cases, but nothing beats a VPS with a database on it for the wide majority of things including Alexa.

Did you ask them or do you expect Amazon to read your mind?

Where do you get such sense of entitlement? Amazon didn't ask you to write it you volunteer your own time and resources and now you are telling Amazon what they should do.

No, no entitlement here. I hoped things would work out one way, but they worked out another. From looking at your comments, you have a history of putting words in peoples mouths. You're doing the same thing here.

What do you mean when you say you hoped they would "work with you" or that they ignored you?

They only added Zappa to the README after the nagging, but were kind enough to do so: https://github.com/awslabs/chalice/issues/27

I don't have any grudges against Amazon for doing this, but it's kind of a shitty feeling to work on something for free for a long time and then see a corporate giant widely publicize an inferior product without even acknowledging your efforts.

Imagine how the guys (I don't remember their name now) who sold hosted MySQL instances on EC2 felt when RDS came out!

That paragraph was just to get that off my chest, I guess. Now that I've written this to clear up the confusion (people were constantly me asking about the differences), I think I can move on.

I get where you are coming from, but things are often less Machiavellian than they seem, even if they feel that way. The Chalice team seems to have their own ideas about how to approach the project, some may overlap with yours and some may differ, from the conversation in the issue you mentioned (https://github.com/awslabs/chalice/issues/27) it seems like they were open to discussing ideas, but they wanted the freedom and control to experiment in their own project.

As with most ideas there is room for different projects and approaches and the landscape is constantly changing so it will be hard to tell which will survive. Even API Gateway's recent addition of the proxy integration feature makes things a lot simpler and probably made some code from all these frameworks less relevant.

So yes the internal AWS "team" has advantages in terms of being able to post to their blog and perhaps being privy to internal developments before you are, but that is just the way it is. Looking at GitHub the team appears to really just be one person https://github.com/awslabs/chalice/graphs/contributors. I just think we should have an open mind and allow for the possibility that they are trying to explore their own ideas and address what they perceive as their customers' needs rather than assume they are trying to crush all similar projects in the name of corporate greed.

You gotta remember they're just a very large corporation who doesn't care about you. It's business for them not personal.

I've partnered with Amazon on development projects before and it was really great for a while and then not great at all when no longer suited their needs.

It's not always fun but comes with the territory when you're a small team or company playing on the same field with giants.

I'm the primary contributor to one of the tools you mentioned (claudiajs), and I fully expect them to at some point offer something that replaces it. the september 20th release of API Gateway was a huge step towards simplifying APIG + Lambda integration, and we were able to drop a huge amount of code from Claudia as a result. The Serverless Application Model released a few days ago takes care of coordinated deployment of API Gateway, Lambda and DynamoDB resources through CloudFormation, which I assume is the most common case for people using the Serverless Framework (another tool you mentioned).

I think this is perfectly normal and expected. When the platform is immature, small teams especially with opensource tools can move faster than the platform and plug holes in it, but then the platform can catch up and offer a systematic solution to a wider number of customers.

For us, Claudia was a way to get our primary app running in Lambda faster and easier. If they replace our needs with a systematic tool, I can spend more time maintaining my primary product and not patching up the platform. Although it's fun to do opensource tools and get some community support and feedback, the money comes from other places.

For people building startups to patch up platforms, the situation is obviously completely different.

Reply on news.ycombinator.com