HN user

Josh2600hz

27 karma
Posts1
Comments12
View on HN

The graph here doesn't prove causality (or even really a correlation).

On the one hand, PG argues that funding is not a good indicator of success, and on the other hand, the author here is saying look how successful all of these funded companies are! It's a false equivalency.

The author is doing exactly what PG talked about, glossing back over history with 20/20 hindsight. As indicated, even the prestigious YC has ~75% of returns from 2 startups.

The article doesn't talk about how many companies failed, spectacularly, in order for those other organizations to succeed. Cuil flamed out $100M+, and there are countless other examples.

I'm not saying the author is wrong, only that this didn't prove causality to me; ergo funding=success.

I don't work at Plivo, but I have a lot of respect for those guys because of their open-source roots. I might bicker with them here or there online, but I only do out of admiration.

Plivo is an XML ---> infrastructure play. Their bait is to developers to come in and use their Twilio-ish code and then realize that what's under the hood is pretty badass and build bigger apps.

From what I can tell, Profig is a hosted VoIP play with black box infrastructure. I'd love to know what's under the hood, but I don't see any infos. They're more like a RingCentral or a Packet8 than a Twilio.

Does that help? I think Plivo is a lot more innovative than Profig, but I've learned not to judge startups by their first forays into the wild. I'm interested to see where they'll go from here.

(Disclaimer: I write thepbxblog.com and I work at 2600hz, a communications infrastructure company).

Looks like from the comment below me that Profig runs on Plivo.

Most of the traffic tracking on the web involves plugins (generally in the form of a toolbar). I don't know about you guys, but I haven't had a 3rd party toolbar in my browser interface in a long time.

Compete, Alexa, etc. they're all tracking people who don't understand technology.

This is a terrible article written without any grasp of the underlying realities of delivering the services the author discusses.

Applauding Verizon for instituting Draconian bandwidth practices may increase value for shareholders, but it is antithetical to the nature of development on the web and in the world. Can you imagine how development of the Internet might've fared if caps had been instituted in the 80's?

Capping wireless isn't the answer, and the author is ignorant to pursue justification through the lens of progression. Capped data plans are not an evolution, they are a regression.

Look, the 2882020 # is not special... That's the main AT&T customer service number.

You're wrong. If you call AT&T, inside of their systems, they can only group dsl orders based on phone numbers. So even if they tell you you're not getting dial tone, in their system, you are getting dial tone.

This has to do with very interesting regulations from the FCC which I don't care to dive into now.

The special rate you got is the same rate you'd get by walking into an AT&T store...

Hey,

I'm Josh, I run Biz Dev for 2600hz. We've built a carrier application switch in Erlang, and we have two sets of APIs (REST and direct AMQP) to allow you to do big things.

This isn't Twilio because it's open-source, massively scalable and does handset registration via API.

This isn't just another boring PBX.

This is a set of powerful APIs backed up by lots of built-in software redundancy.

If you'd like to deploy this to your servers, it's really as simple as creating an account, clicking on the cluster manager and pointing the cluster manager to your servers. Our platform handles all the setup for you.

In short, if you want to build big things in Telecom, we can help, or you can use our tools to deliver this service.

Do what makes you happy :).

How do you deliver DSL without a phone line in the US?

Even AT&T delivers a phone line on their "direct DSL", they just hide the costs of regulation in the rate.

This, to me, isn't a case where sonic is to blame. This has more to do with restrictive FCC requirements than it does with Dane.

Phones are due for a regulatory rework.