I don't see how any business except Google could rationalize using it. Maybe if a company hopes to someday be acquired by Google they might use it to impress some Google execs. Even if it could rapidly evolve, which it probably wont being an ivory tower project, Google won't put the same resources behind it that Microsoft did with visual studio, .net, and c#. It will become what Objective c is to developers, an annoying language they occasionally have to deal with.

The Security Rule has a general security standard, some documentation/retention rules, and three sections of safeguards. They are:

1. Administrative Safeguards

2. Physical Safeguards

3. Technical Safeguards

Some of the safeguards are mandatory. Some are "addressable," meaning if you don't implement them you must document why you chose not to and what other safeguards you applied instead.

Most likely, you're going to start with something like the following for your servers:

1. Sign a BAA with any service provider who is going to touch PHI for you.

2. Restrict physical and logical server access to authorized individuals. Document how you restrict access and why the methods chosen are reasonable and appropriate given the risk posture of your organization. (There's a LOT packed into this step.)

3. Log all access and data modification events. If you use a logging service that isn't HIPAA-compliant, make sure you're not including PHI data you send them.

4. Encrypt data at rest and in transit, including inside the network perimeter. Document your network topology and access points.

There are a few options if you want HIPAA compliance. Note that "HIPAA compliance" is somewhat of a loaded term in that there aren't many super-technical benchmarks to meet, but a general "do-good" attitude including (but not limited to) some of the following points:

- Physical server isolation: you cannot have other instances sniffing around in your deallocated garbage memory.

- Encrypted data stores: physical theft of the server should not provide access to your data.

- Server providers who can sign a Business Associate Agreement: many hospitals and firms with medical data require this in their stipulations.

- Audit trails for database modifications, access, etc. Basically, log everything, and this has to be encrypted too if it contains protected health information (PHI).

Again, this is not an exhaustive list. You really need to check with a lawyer who knows this stuff. The fines are enormous (read: business-ending) if you break the rules.

How do you work to implement these? Well, find a host who is willing to sign a BAA. Here are the two major contenders I'm aware of:

- Use Amazon AWS; they're willing to sign a BAA with you and provide you the physical server isolation you need. However, this doesn't come cheap. Expect >$2,000/mo in costs to keep this configuration. Also, you'd better be a network pro or willing to learn how to manage VPCs correctly to provide proper network-level isolation for the databases.

- Use aptible.com (they happen to be a YC company, and I don't know of anyone else doing this). Frank & Chas (the founders) are very responsive and aim to provide a comprehensive package, including backups, audit trails, and even employee training. The Docker-based and heroku-like interface is very appealing:

This option is still expensive. They host on AWS as well, so you're paying for the server costs + premium. However, this will still be a lot cheaper than hiring a competent sysadmin to make sure the execution is flawless.

It's not just the server - it's the storage, accessibility (compartmentalization), and transmission of sensitive data (PHI and PII) at all levels. There is a lot more to HIPAA/HITECH than just server configuration - there are legal agreements you have to enter into as well (BAA's), insurance requirements, and potentially a lot more.

I'd suggest you work with a company that has a lot of experience in this area before you inadvertently find yourself fined (or sued) into bankruptcy.

As some people have mentioned here, there are other issues to think of besides the IT aspect. There is employee training, risk assessment, policy development, and the business account agreements. Accountable is a company that focuses on these type of issues to make them easier by providing things like employee training, ready to use policies and procedures, and business association agreements. I found them while learning about HIPPA compliance, and I have not actually tried the product but it looks like it could be useful for you, so I thought I would mention it here. http://accountablehq.com/index.html

@USNetizen -- You're right...I should have clarified that I want to know how to get an entire stack up and running, although I don't trust myself to do this unassisted.

I'm just surprised at how few resources there are that explain what it takes, and I hope that someday soon, healthcare startup CTO's will be referred to clearly documented open source solutions that are fairly fool-proof, rather than paid-for services (@sebst). Amazon's compliance page is unfortunately uninformative (@byoung2).

Thanks for all of your comments so far. Synopsis is...it's complicated. There are basically no straightforward guides and no reliable, tried-and-true open source solutions that can be deployed with minimal security expertise, at least with respect to the technical setup.

Options are to go with a service company like Aptible or TrueVault, or fumble through vast amounts of obtuse technical and legal documentation, then hire a security expert to audit your homemade system and hope that everything goes OK. Both options, as they currently exist, require a fair amount of $$$.

If you are trying to set up a service for processing or storing PHI, you may be interested in DNAnexus (https://dnanexus.com/), which focuses on compliant high throughput data analysis and storage for genome information, but can be used to store other types of PHI data. (Full disclosure, I work at DNAnexus). Email in profile if you want to go into specifics.

One missing point in this thread: there is no such thing as HIPAA compliant. There is no government organization that will sanction your set up as "compliant". The HIPAA legislation imposes fines if you leak data, but does not prescribe how you prevent that.

That said, the thread does have some great safe guards and industry best practices you should look at.

If one big customer is demanding you be HIPAA compliant then they probably want to see a certification, and depending on size of customer they may be willing to provide funding for that certification. It takes months but the certifying service will provide consulting and training. Essentially it all about tight access controls, encrypting data at rest, and documenting everything and everyone who has access to the internals.

I did mobile contract work for 2 years and built most of my products on Parse.

The free tier goes a long way. In my experience, if you are thoughtful with the quantity of requests you send from the clients, it will take over 1000 users to push you into the paid tier. This really depends on the nature of your application though.

As for development, there are a few nuances that you have to get right to use Parse at full capacity. First, delegate as many operations to CloudCode as you can. I do this for separation of concerns (clients should focus on displaying data, not retrieving and formatting it) and more importantly, to make cross platform applications consistent and easier to write. Also, you can change behavior on the fly instead of creating new builds of your client when you just want to change a small detail, like the number of results to return.When using CloudCode, take advantage of Parss's implementation of JavaScript promises. And avoid mixing promises with the "backbone-like" callbacks. There's a bug I've found when mixing the two that will occasionally cause the operation to finish before executing all the callbacks.

And speaking of bugs- the biggest drawback of Parse is the documentation and support. Some entries in the docs will actually be a one sentence reiteration of the title of a method. It's mind blowing how shitty some parts of the docs are. The support is even worse. Looking through the help archives (they've now given up on internal support and moved their entire support platform to stack overflow) you will frequently find smug answers from the Parse team. It's common to see a Parse support teams response get tens of downvotes. It's bad.I once found a bug in Parse's method to save multiple objects at once (if the first request failed, all subsequent requests would fail too) and getting a fix implemented was a huge pain. I had to go through Facebooks bureaucratic big reporting process only to be told the bug was a 'feature' weeks later. I resubmitted the bug with all kinds of proof and demo projects, and finally after a few months I got the email saying the big was fixed. Huge pain.

Overall, if a prototype backend will suit your needs, I highly recommend Parse. It's certainly not the pie in the sky it could've been, but it gets the job done and lets you quickly get to market.

The free push notifications, data dashboard, and analytics are some nice sugar on top too.

I will probably continue to build my products on Parse, unless I know I will need immediate scale, or a client requests a specific backend configuration.

Been wanting to try Firebase too. It's a Parse like BaaS where everything is done in realtime. Very cool, but still somewhat unproven and new. Has anyone used Firebase?

I have had tons of problems with parse. Our app has both the iOS and website backends using it. While it is useful, and a lot of stuff is well done, when you operate at any kind of scale you keep running into all kinds of hidden limitations. We have ~30k+ weekly actives.

For example - Horrible limitations on queries. You can only get 1000 total objects at any time, batch requests are limited to 50 objects, limit of 100 count requests a minute (not sure the exact number but it's really close). Not just for each client, for your ENTIRE APP.

No good backup solution. They say they back up their servers, but backing up your own data is left to you. Which is a pain in the ass because of point one.

Awful support. I get that they have a lot of people and can't support everyone well, but I have always gotten the feeing that Parse just doesn't care that much about users. Maybe they do if you pay them a bunch of money, but until then you're on your own. Half the time my support requests go unanswered, sometimes the rep just stops responding midway through the conversation. Only recently did I ever have a good experience with Parse support (thanks Christine!)

To top it all off, apparently they silently changed the way batch API requests were counted and never told anyone. Instead of a batch request counting as 1 request, apparently it now counts as each individual object inside the request. So batching 10 objects is one http request but 10 Parse API requests. Sketchy. When you reach over 30 requests per second, they just start dropping requests.

The iPhone client was really good and really solid. Unfortunately we had to migrate off of Parse though because of pretty consistent downtime and really slow speeds. It wasn't unlikely for Parse to go down for at least minutes at a time once a day. Migrating off of it is not easy because you have to then replace the really solid client which can take some time to reproduce some of the features you have ended up relying on.

The dashboard also left a lot to be desired. It limits how many tables it shows on the left so you end up having to hack the URL. I believe they finally offered a "fullscreen" mode rather than having a fixed width and height which is nice. Basically we would have to drop down to the Ruby client to audit the data often which isn't the worst.

Parse was really good to prototype on which was nice, but it is extremely likely if you want to launch anything to the app store and don't want to deal with downtime you have no control over you will need to rewrite it. For this reason I would suggest with just using something home grown.

With a 100 active users at any one time? No it's not expensive since over the course of the month you would have hundreds of thousands of users. If you have 100 active users for your app you most likely could use the free/$100 option as it looks like it scales to requests per second which to be at 800 requests per second you would need a LOT of traffic. Highest I've worked with was 500 requests per second on a site handling 250,000 users a day and they only had that at peak times when they got 50% of their traffic in two hours.

I think you would need to look at your http logs to see how many request per second you're currently getting, I highly suspect it'll be nowhere near what you think it is.

The annoying thing is the documentation states: "It's easy to get the progress of both uploads and downloads using ParseFile by passing a ProgressCallback to saveInBackground and getDataInBackground." and provides a code snippet that doesn't work and hasn't worked for two years. Please fix the bug or change the documentation!

As some people mentioned, you're over estimating the number of requests per second for the number of users you have. I would recommend writing a small application to get a feel how it feels to develop on the platform.

I personally found it to be incredibly valuable to be only writing client side code. It let me focus on my end users experience and iterate mich faster. After writing an application on parse, I found myself missing it on non parse projects. I used the parse js SDK to create a SPA.

I did think the on boarding experience could be a bit better. The docs are good, not great. I haven't had any issues with down time but my app is probably much smaller. I would definitely use it again.

From an Android devs perspective, I will say that the Parse Android SDK is really well made. The API allows for idiomatic, fairly concise, and consistently patterned code. It also adheres to a lot of the coding conventions that android devs are used to like callback functions for asynchronous operations. Set up is super easy too. The offline caching feature is really easy and useful.

That being said, if you have the skill set and time as a developer to be able to implement all of those features and a server/db component, I would. It may not be as robust or clean as the Parse API but hey if its your code it shouldn't be terrible to work with. If you do it yourself, then you get the added benefit of just having to pay for hosting of your server and db.

I have been prototyping an app on parse over the last month, I've been pretty disappointed. Mainly with regards to their database system. As others have pointed out there's insane limits on things like count queries. There is 1000 record limit on queries in general. The performance of cloudcode between the db is awful, you have to batch everything into tiny operations or risk timeouts. Skip has a 10k record limit. Their web based data browser tool seems unfinished, for instance you can't even insert into relational columns and deleting 100 records at a time locks up my browser.

It may be okay for very simple applications but for anything non trivial or with a large db I would not recommend it. Any time saved by having a PAAS out of the box is lost trying to work around all the weird data access limitations.

I have been using Parse for a couple of years now. Some of my clients are currently on it and is being used in production. The most compelling part of the offering is a well thought out SDK which helps in time to market by reducing the development time. Parse has a lot of potential but unfortunately they will need improve in some areas pretty soon. The first issue is documentation, it is bad. What makes it worse is not being able to build a large enough developer community around the product. If Parse would only listen to the developers using their platform, take constructive feedback and improve their offering it will go long way. The response from Parse when things are bought to attention is much to be desired. Part of the problem is Parse needs to solve is to partner with companies/developers to help out their customers with the common issues that people face when using their platform and concentrate on the real issues of the platform. This should also help them with their support as well, which is bad even for paying customers. I really think Parse can learn from companies before them like Microsoft, Salesforce, Apple on how to go about building a strong developer community around a platform. I also think Parse can help a wider range of customers, like make a serious play in the enterprise market if these issues are looked into.

The new pricing is very good, and you shouldn't need to pay until you're running a lot of traffic.

I find the iOS SDK to be pretty solid. Push notifications also work really well.

I have also noticed requests fail from time to time, but it hasn't been too much of an issue.

What I don't like is the query system. What would be trivial in SQL is sometimes difficult or impossible.

I also just don't like that cloud code queries are all asynchronous. Promises help, but complex operations end up as a huge nest of promises. I just have no need for server-side code to be asynchronous.

The console has been slightly improved, but the data browser is still a bit painful. They like to break the back button quite a bit too.

I have one large app using Parse as a back-end, but otherwise I just use it for push.

I'm wrapping up an iOS project using Parse and wrote a Core Data <-> Parse "offline mode" / sync engine for it. From a development perspective I'd say it's relatively painless.

I did encounter a "bug" wherein certain queries can't be cached effectively which I solved by using vanilla arrays instead of Parse's PFRelation. No downsides to doing it that way (for this project) but it felt awkward. It would be better to have more consistent caching behavior.

I encountered other issues but that one is top of mind at the moment.

I have seen downtime during development. It's usually short-lived but it's there nevertheless.

Parse gets you up and running crazy fast. So it's extremely useful in that way. If you're making a mobile app the speed the SDK gives you in working with a pre-built backend cannot be underestimated.

Recently I started a project with Parse but eventually moved off it ( with some pain ). The pain points for me were random requests timing out or randomly taking 20+ seconds to respond. Also the SDK wasn't as flexible as I needed it to be ( which is typically the case with any ORM ). The forums/support isn't great so if you run into a showstopper, you're pretty much on your own.

I tried out their PHP SDK, intentionally willing to try out Parse on the backend side of things. I intended to use it as an ORM layer, abstracting out the data structures. However, my experience was that making multiple queries (even 3-4) would make the app appear slow. This is in no way a fault of Parse, just how it is.

So, I'd recommend using Parse with any of the frontend SDKs (JS/Android/iOS), but would warn you against trying it on the backend side of things (where PHP is the only offering so far).

I can't comment on anything but the Push notification service, but we've been super impressed; it's so much easier having our backend just call the Parse REST API and have our iOS clients register PFInstallation objects and assign themselves to channels than it was to setup enduring TLS sessions to APNS on App Engine.

I'm in the process of helping a client migrate a large data set (5m users) off parse due to the issues they've had. They had a fairly consistent rate of 1 in 100 requests return a ECONNRESET error in node. After over a year of haggling with the parse support team the errors finally disappeared about a month ago. They needed at least 10 fetches so you can imagine that 1 in 100 not returning doesn't bode well.

I don't have all of the specifics as to how or why the errors went away, but no changes in the client's codebase were made that relate to this.

Summary: seems brittle, tech support was useless, customer wrote huge checks to parse every month and didn't get traction fixing the problem. Even though things have improved we're continuing with the effort to help migrate the client away from parse.

Same as what everybody else is saying. Solid SDK, but downtime is a major issue. Worse, some partial downtime scenarios or bugs get next to no attention for days. It may not be a "site down" situation, but it may be critical for your app. And yes, documentation is extremely sparse, with few real world examples if any.

I've used XEmacs all day every day ever since it was Lucid Emacs. I probably could switch to GNU Emacs if I really wanted, but I'm used to XEmacs, and I have a lot of personal customizations that would have to be changed. I don't really know how hard that would be, but I'm very glad that XEmacs continues to be maintained nonetheless.

Having used XEmacs for a very long time, I recently tried switching to GNU Emacs just to gain access to one particular Emacs-only feature that seemed supremely useful to me. I spent a couple of days hacking my .emacs file to get GNU Emacs configured more less the same as my XEmacs config, but even then things weren't quite the same. In the end, the "one feature" proved not to be as useful as I thought it would be, and I went back to XEmacs. Reason: call it a combination of my old habits and the silly but nigglingly painful differences between the two.

The same way you could ask why GNU Emacs still exists. Because there are people who for various tiny (rational or irrational) reasons dont want to switch the editor they've been using the last 20 years.

It is the same thing as asking why German is still used, now that English is a world language.

For example, it's possible to construct a perfectly valid image file, served with the correct image/gif MIME type that contains malicious a Javascript payload, and older versions of Internet Explorer might still execute that Javascript. If it is served from your web apps main domain or a subdomain, then this Javascript can access users' sessions.

I don't work at Netflix, but from talking to someone there they use FRP in both Java servers and JavaScript apps. Being that the creator of Elm works at Prezi, I'm sure they would be interested in sharing practices.

I think it's a bad idea, if i'm not mistaking... You are going to contact suppliers / authors of Amazon and say: hey, i have a buyer for your book for 9$ instead of the 9,99 on Amazon.

The author will just delete your email, why would he spend one minute on confirming the deal for a lousy 9 dollar, he doesn't care and he already has his lowest price on Amazon. If he agrees with you, then Amazon will also want a lower price (and then it will cost him a lot of money)

I get the impression that writeup could be condensed down to a single paragraph. I wound up seven or so several introductory paragraphs.

That said, I think the idea of keeping prices personal and private is great for boutique services, but generally sucks otherwise. When searching for products and services, I'm usually looking for price first and reputation, etc. later, since that's nearly impossible to prove in a depersonalized internet service.

In other words, anyone can put up a website proclaiming that they are the most awesome at whatever they do so they can justify a price point, but there's no way to prove it objectively.

So it's like a dark pool (in the capital markets sense) for retail, in which you try to undercut the market maker's (Amazon) spread by narrowing it yourself and not telling anyone about how narrow it is? It's an interesting idea, but I don't think it would work because (as many commenters here have already said) Amazon's spread is already quite narrow.

Unless one has an original product or one of a kind product there is no way to charge less than Amazon. Well, there is one way and that is if Amazon runs out of the product you happen to have then you will be allowed to sell yours.

Amazon monitors the trend and has the purchasing power to buy trending items and sell at a low price. Amazon does not allow you to set your prices lower than theirs.

You say this could make you more competitive and that might be the case - but ultimately I get the impression you're less likely to be acquired (fair enough, maybe you definitely don't want that) and/or/thus more likely to shut down.

Realistically your pledge means nothing if you go bankrupt and shut down. Your startup could still fail and nobody really has any recourse in general. You could probably find ways around that but forcing liability on founders will probably make this less likely to catch on.

An acquirer is going to be held to these presumably, and they probably can't just go bankrupt to avoid them - so that's less likely to happen. Maybe that's what you want but it cuts a big exit path out for founders - and acquisitions aren't always terrible for users. I wouldn't be surprised if there exist acquirers for some startup that would keep users happy for >X years but not commit legally to doing so for X years.

I guess there's a bit of a cycle and it really leads to the pledge being worthless. Less likely to be acquired + can't pivot for X years -> keep doing the same product -> but it's losing money -> no viable exit, no pivot -> shut down.

1) You've got to stop calling yourself a "freelance developer". Start using "consultant" (and then read lots about what that means and behave accordingly). You are not a hammer.

2) You seem jealous of younger project managers. Are they paid better? Have they more prestige? More control? More influence? What specifically bothers you? And then

3) Stop just coding. It's a great skill to have but you and me can be coded under the table by a 22yo who costs less, drinks more Red Bull, has more energy and fewer commitments/distractions.

4) We can keep learning new technical things but there's far more value in learning how to apply our existing skills to specific domains. Get closer to the "business". Learning more about marketing. Understand sales. Use your coding skills in those areas and you can side-step comparison to younger developers and the typical software project hierarchy.

Probably I'm just an old spoiled fart having an early midlife crisis. I know exactly what I don't want and I know more-or-less what I want:

* I'm used to working remotely from home and flexible hours and that works super for me

* I love responsibility and independence: I don't want to be part of a team where a couple of people do the same thing. I can do the whole solution on my own OR I can be a part of a team with clear responsiblity separation, where for example someone does the backend, I do the frontend etc.

* I could come back to management only when I'd succeed with my own product and had to handle company growth.

* So essentially, in the end I would prefer to end up with my own product, but for the time being, I'm seeking opportunities that allow me to work independently (or semi-), take reponsibility and work from home. Freelancing does that, but as I said: most PMs are in their twenties, and finding well paying client that wants to invest in a quality remote developer is hard.

I am very much in the same position (same age, Europe, nearly two decades experiences in the tech industry, both in management and engineering, turned freelance three years ago).

Here is what I did in the last months: I trimmed down my consulting revenues to 2 workdays a week and am now building a lifestyle software business. After a couple of false starts I picked a product that a.) would bring me immediate benefit once it is built b.) already has competitors out there. That second part is important to me: It minimises my risk picking a product idea without market. If there is enough demand for my variant of this product is a hypothesis to be proven, but I am willing to take that risk.

tldr: I would not look for something that has not been done before. I would take something you use everyday and make it better (for you). It sounds like a platitude but I think there is some truth in it.

Become a principal or senior software consultant or architect. Many enterprise consulting houses are looking for senior people with a lot of experience. Go the route of software architect - not just coder and you can earn a very nice salary. You can look at large orgs in Europe, eg: Amaazon Web services consulting arm.

If you want to do some % of your time as an experiment, working for a pre-launch very early startup for some future equity with no immediate payment, we are looking for people like you. drop me an email

Audio Technica ATH-M50XJust got it recently and they're awesome. They do not have active noise cancellation. Since they are over the ear, they cover the ear and with a good set of ear pads, they block out all office noise (unless you work in manufacturing ;) )

Based on reviews that I've read (not compared personally) they are much better than comparable beats.

The number one concern of substantially every company with more than 10 engineers right now is hiring additional engineers. You can't make a hiring manager who is looking for an engineer mad by offering to introduce him to an engineer.

I'd take time to customize the pitch and make it obvious that you're sending it to someone who may be or may know a good fit, as opposed to any routable inbox you can find from the Internet.

example one:

Dear sir,

I am a C# Java C++ engineer from $LOCATION with extensive experience in mobile applications, front-ends, ... <-- absolutely nothing in here suggests that they know who I am, and they're imposing on me because they're offering nothing of value to me.

example two:

Hey Patrick!

I've read between the lines of some of your recent posts, and it seems like you are overwhelmed on Appointment Reminder. [Patrick notes: Someone literally wrote this to me last week. Got my attention in a hurry.] I'm an experienced Rails engineer with 6 years of experience working with legacy codebases. I think I could take the engineering work for AR off of your plate, so that you can focus on marketing/sales. Would you like to have a chat about what that could look like? I am open on next Monday and Tuesday from $TIME to $TIME -- what half-hour in there works best for you? <-- Even if I were not interested in this, I'd be interested in this. It is very respectful of my time, demonstrates unique understanding of my situation, etc.

I would be interested to hear any responses as well. I've followed a similar path. I dropped out of college at 18 and played traveling ski bum for a few years. Then I moved across two states and decided to get my life straight. I've since been working my way through college, but I feel like I'm in the exact same position. I have a rough idea of what I should be doing to become a better programmer and get into the industry, but after five years on this treadmill I feel like I'm missing something.

Th problem with EV (green bar) certs is the Browser usually ends up checking the certificate status via CRL or OCSP (URI is specified in the cert), which can add an additional .5 to 10+ seconds before the page is displayed. More so when the CA servers are down or the connection times out.

So if you do go for an EV cert, go for the one that has the best listed uptime on it's CRL or OCSP servers.

Having said that, I would never spend more than $10 on a cert, and just use the most standard/common "bundled" CA cert. No one will ever know. It will have faster page loads. And those fake stories that EV certs increase conversions are exactly that, fake, and misleading. No one will real world experience has ever claimed to see a positive difference with EV certs.

The only problem with cheaper certs is you have to bundle the intermediary CA certs...

How you feel about this probably centers around whether you view SSL more as a cryptographic means of securing a connection (stopping traffic snooping) or if you view the SSL+Browser iconography as a means of site identification (stopping phishing attacks).

1. DigiCert. They're not the cheapest, but they really have their stuff together. Their support is awesome (speedy, technically competent, and human). They're also proactive about identifying issues with your certs, they handled the heartbleed incident perfectly - reissued for free with no issues.

Check out my startup, SSLMate: https://sslmate.com. What sets SSLMate apart is that we're working on making SSL certificate management extremely easy on Linux servers. You buy certs from the command line in a single step that takes a minute or less and automates important details like bundling the chain certificate. You can set up a cron job for automatic renewals. Even well-run sites have been known to forget or botch cert renewals, and we want to put an end to that by automating everything. Many features are in the pipeline and will be announced in the coming weeks.

Regarding EV certs, they're not worth the extra money and inconvenience. They provide no additional security, and the assurance they provide visitors is highly questionable (e.g. see shiftpgdn's comment about how switching to a non-EV cert resulted in absolutely no change in order metrics: https://news.ycombinator.com/item?id=8344666).

I honestly don't think it matter much where you buy your certificates. In the end it the same product, plus or minus some service you may of may not care about.

Should your certificate provider do something stupid you can switch to a new provider in 30 minutes, assuming you don't pick EV.

The EV certificates look good, but that's about it. They do come with at least two disadvantages:

1. If your company name is different from the domain name it's going to look weird. We dropped having a EV because we're not interested in having the name of our parent/holding company in the address bar.

2. If you later switch back to a regular SSL certificate is going to look suspicious to your regular customers.

That being said, we use Trustzone (http://www.trustzone.com). They provide GlobalSign SSL certificates at a reasonable price. I like that they email us, or call if we don't react, a few months before our certificates expire. We also have our own account manager who helps with new certificates and renewals. It's extremely nice just be able to call someone.

Just to address point 2. No. Those who say yes probably do not understand what EV certs actually do.

You get the exact same level of security from EV and non-EV certs. The whole "extended validation" criteria is pretty handwavy and varies from CA to CA. Paying more for that warm, fuzzy feeling isn't worth it.

Don't EV certs create a net increase in security risk (if any web users understood what they were supposed to mean)? I'm not expert in these issues, but I've always doubted their security value:

EV certs are supposed to communicate certainty[1] to typical web users about identity, confidentiality, and integrity. But, if I understand correctly, obtaining EV certs in someone else's name (or something close enough to fool web users) is possible without great cost, and so that message of high security is misleading. If EV certs were believed by end users, wouldn't we merely be creating a social engineering security hole? Competent thieves also would use EV certs and increase trust in their websites too.

Thankfully, I've never met an end user without technical knowledge who understood what an EV cert was. I do know what they are and I don't trust them more than regular certs (which is not much for identity, but I do as protection against low-cost confidentiality and integrity attacks).

[1] Re: "certainty": I know EV certs are supposed to be more secure and not perfectly secure, and that there is no perfect or 'certain' security. However, few end users understand the latter, and of the ones that do few would take the time to learn the degree of increased security EV provides. We shouldn't say, 'trust the green bar' unless we expect people to do it.

startssl.com gives out free certs to individuals. This is great for personal projects, blogs, etc. Otherwise I use Namecheap and their $9 certs. I have not found a great wildcard cert provider yet (why all certs are not wildcard by default is beyond me).

Hard to beat http://gogetssl.com price wise. I'd get a Comodo Positive SSL Wildcard so you can use it for the main site and the static sub-domain. That way one cheap cert covers everything and it's SHA-2.

FF, and chrome and IE are totally ok with login/pass passing in clear over http, which is wrong. But when you don't have a certificate signed with by one of the root certificate in your wallet it screams to death. (Which is totally in hierarchy of risk WTF).

Your wallet contains organization that should have been shut down according to the rules of SSL: we normally cannot trust any authority that even once or for good reasons emitted a joker certificate to make a MITM (or helped people doing so).https://news.ycombinator.com/item?id=2138565

In your web browser default certificates list you find microsoft. in 2007, they put in IE for the Ben Ali gvt a special certificate to be able to do a MITM on the tunisian opponents. (ofc those using ff would see a warning).

MS did not emit the certificate, but for them who can issue SSL certificates that's clear not right to provide a SSL joker root certificate in its web browser used for MITM (without your nice little icon you care about to get red).

MS is still in my list of trustful SSL certificates. How can you trust them. If they could betray once for a few money (tunisia had less money as a state than MS, google, whatever country) they have incentive to redo it again.

Knowing MS has gone through the death penalty, other SSL issuers can now have an incentive to do the same.

SSL central certificate are NOT to be trusted anymore. We have proofed once a company in our "trustfull" wallets betrayed without consequence. So betraying is OK.

My recommandations: - Ever dane (but that is a combinat) or the new technology google is secretly working on (maybe mozilla too),- set a cookie on http landing page ssl_cert_on=bool- if not present redirect to http://www/my_cert- give a link to your self signed certificate on your domain so that your user add it its wallet securely (must be a js or a MIME extension to set so that IE/FF/google open at the "add this certificate to your wallet page"- correct the world and FF/Chrome/IE mess by providing a way for the user to read the mess of the X509 certificate (for which domain this cert is valid, the fingerprint)- correct the world another time by explaining to your customers it is normal they should not trust this special web page or this certificate and give them links for them to check your allegation, (knowledge and tools) - provide another secured way to access your cert fingerprint (DNS SEC TXT record for instance, snail mails, flying carrier, PGP mails...)- and make a rant on how much security UI/UX is so much sucking and poorly thought that it is the major security hole nowadays and how all security guru giving us advice on how to code to "secure" code should be regarded as cons that should be imprisoned.

Then, now that you corrected the whole "what gone wrong with central authoriy"'s mess, you can very easily make your free self signed cert secure certificates and sleep on your 2 ears because your customers are now understanding security the right way.

If you understood nothing of the text above, just buy a normal certificate to whoever you want. You will be "safe" according to the green icon, and this is all that matters in the real world.

Could be, but also it might be the Apple/Akamai/LimeLight CDN have capacity constraints tied with their router interconnect with Verizon. By going via Amazon, you are likely connecting via a different router port.

First of all: Despite not being in your target audience, I really like your landing page. It looks fresh and professional to me. Maybe a nice key visual (e.g. a screenshot of an actual survey) in the hero section would make it even more compelling and help understanding what polljoy does in the very first moment.

Regarding marketing the app, here are a few (unsorted) ideas off the top of my head:

* You said that you developed the app in order to scratch your own itch. So basically, you need to find more people like you (or rather your co-founding developers) that are in need for such a solution. Where do these people "hang around"? Where are they looking for help with their work, where would they look for such a tool? How can you get in touch with them?

* Contacting developers directly would be one of my first ideas, too. How many developers did you contact? Did you get any feedback at all? Did you add tracking to your mails so that you can estimate open/click rates? Maybe you need to improve your cold pitch mail...

* Are there any conferences or game development meetups in your area where you could spread the word about your service?

Checked out your product. It looks like a really good implementation of a "poll and survey SDK for mobile developers".

There are tens of thousands of mobile developers building all kinds of apps, which group of devs actually need to add different polls / survey in their app every week ?

You made it to scratch your own itch.. but what exactly was your itch ? And how frequently did you want to switch the poll, survey that you conduct ?

When a user has a pain-point then we need to evaluate the following as well i.e. a user with a pain-point by itself is not sufficient, we have to check for problem-solution fit as well ~1. What are the alternative solutions and what do they lack in and how much more value does our offering create in comparison to the alternative ?2. How often do users face the pain-point ?3. When do users face the pain-point ?

A method of marketing I would use is to join an online community where your target audiences (mobile developers, stakeholders, usability testers, etc) hang out. I would then engage with the community and just once in a while, talk about your service. Make sure you are a member that gives out lots of value to the community.

Even better, I would start writing related educational content on your blog, and at the end of each articles, ask for your reader's email addresses.

I think one of your biggest marketing goals right now should be to grow a mailing list! It's great for repeat visitors and relationship building. Subscribers convert to buyers really well too.

It would depend on your definition of "succeeded", but Docker (formally dotCloud) made a great transition after releasing docker and just raised a very nice round of funding.

"In 2013, recognizing the need for flexible, PaaS-like environments inside enterprises and across clouds, the company released much of its PaaS container technology as the open source Docker project. Docker is an open source engine for deploying any application as a lightweight, portable, self-sufficient container that will run virtually anywhere. By delivering on the promise Build OnceRun Anywhere, Docker has seen explosive growth, and its impact is being seen across devops, PaaS, and hybrid cloud environments.

The success of the Docker project led the company to change its name from "dotCloud, Inc." to "Docker, Inc." in October 2013 in order to reflect its focus on the new product. Docker, Inc. continues to run the dotCloud Platform, supporting thousands of containers running applications for a wide variety of businesses."[0]

Your product is already succeeding. Why do you think open sourcing it will make it more successful? Are you sure you can make an open source project bigger than your company?

Why do you think these competitors matter if their own customers are telling you they're shit and you're great?

Why does HN matter to your startup? Are you sure it matters to theirs? One simple way to tell - do your competitors get on HN with stories about being a startup/engineer, or is their product itself interesting to HN? If HN isn't the best source of your customers then it shouldn't be a factor in any decisions or marketing/pr.

What about these conferences - are they closing deals and making money at these things, or are they just spending on them?

How about leveraging their marketing? Let them find unsatisfied customers and poach them straight from hn/twitter/linkedin/facebook/anything you can find.

Anecdote time. The last open source company I dealt with worked in the big data space. They messaged themselves as a product company and listed 3 products on their page.

I was working for a company providing client tools and we were teamed together by a larger System Integrator on a contract proposal.

While working with them I got curious about their product (hey, maybe someplace cool to go work someday).

The conversation went something like this:

Me: So you guys have some impressive software, you must have a heck of a dev shop Them: We do. The good news is that we got a nice head start using some open source stuff, hadoop, etc. Me: Oh. So what bits did you guys make? Them: Well we made this (points to web accessible management console) and did the glue work to pull together the open source bits Me: Oh. So is your value proposition then that you guys have tightly integrated this technology stack and... Them: *Right* and provide the technical expertise to run it. (sits up proudly) and all the work *we* did has been open sourced as well (goes to their github page). Me: so....if I were a customer and I bought x amount of product A from you, what exactly am I getting? Them: you're getting the integrated stack and our expertise and support. Me: Support available by contract? Them: Right. Me: So let's say I'm the customer...what's to prevent me from just downloading and compiling all the source code for your stack and your glue and just poaching a couple of your guys and saving myself a few million dollars in FTE hours? Them:Well that's highly unethical...poaching our people Me:okay, or I find a couple really good guys on most of this stack and give them 3 or 4 months to come to grips with it and your glue...same thing...what's your guys' value proposition to go with your company instead of just doing that? Them:...

They sold to another company a few months later and I've heard it was mostly for the customer contracts they already had in place. I'm not aware they were ever profitable or on a path to profit. Great success?

My point is, you have to really consider this kind of line-of-questioning and put together a rock solid value proposition to have a chance at succeeding. Because why pay you for whatever when I can get it free as in beer and use my own people who I'm already paying for?

>Open sourcing will make the product better, will make it well known and might even speed up our growth.

Open source by itself won't do any of those things.

The question is, what advantages would being open source give you over remaining closed source? Whether it is open or closed, you still have to do the promotion to make it well known. If you go open source, does that automatically mean you will open the development process as well, and if so, you'll have to consider the process by which you accept changes into your product, IE: will there be an open level and then a supported "commercial" one, for example? how will you build a team of community supporters?

Yes, there are obviously examples of open-source success in the world, but it isn't clear from your posting whether there is a strategic advantage or not.

To echo some sentiments already voiced, open sourcing a product is about more than simply publishing your source to Github. It is about building a community around that source code to evolve the product. Contributions can take many forms such as code, defect submissions, documentation, testing, etc. This community drives conference attendance, on-going media attention, and, most importantly, your company actually gaining market position from an open source strategy. Building such a community takes a fair amount of time and effort. Very few spring up like Docker. If you are committed to the long haul of building such a community then you could gain a tremendous amount. If you are expecting to simply publish the code and get immediate and long-term PR from the act of your company working in a public repository, then I think open sourcing will not only fail to meet that expectation, but likely be a critical distraction for your company.

At the moment, no examples of start ups which started as closed source and went open, come to my mind.

However, there are a few open source startups out there which started open from the beginning, such as Drupal or WordPress. You could also have a look at NewsBlur which got some traction after Google shut down Reader.

Whether or not being successful depends on a few things:

First, will open sourcing really make the product better? From my experience people tend to overestimate the capabilities of the open source community. This community does not translate to "legion of free developers at your disposal" but require an proactive engagement and community management. Are you well prepared for that?

Second, the nature of the product and the audience: If you're selling server software, for example, such like RedHat, there will be those "private" and "small" users which take your product and use it on their own. But there are also corporate users who will buy SLAs and first and foremost want someone to blame for things that are not working. Second, there are products who benefit from centralization. NewsBlur for example may less valuable for individuals if it would not provide a "hosted service". The same goes for Facebook. Their asset is more the user base than the technology (even if that's, of course, also a huge stack).

Third, what is your "open source strategy". There are companies like Pentaho or Alfresco which offer an "open core" and sell additional features for that. I would consider that more as closed than as open source, in some way it is a bit like a "demo version".

I would love to hear what you've build so far, because open source in a commercial environment is a topic of interest for me.

I am a bit biased, being the founder of a startup whose products are all Open Source. BUT... nonetheless, I'll say that I don't necessarily think that going Open Source is going to be a magic cure-all for you. And it could make things worse, depending on may details.

Remember, Open Source really is more of a development methodology than a business model. And being Open Source doesn't obviate the need to think about marketing, advertising, sales, etc.

If you wanted to go the OSS route because you believe in OSS ideologically, or because you think it's a way to make the world a better place, I'd wholeheartedly say "go for it". But if you want to do it just because you don't like marketing, I'd say you should consider giving the whole thing some more thought.

Sounds like you should sell the product to someone that wants to do the business side of things, and stay on as the head of product development.

It is doubtful to me that open sourcing it will make it well known unless it is a technical product and your customers are developers. Do your customers care if it is open source? Most people selling Asterisk installations never explained to the customers that technically the software was free. All that will be accomplished is that someone who likes marketing & PR can pickup your work and create competitor D, that has everything you have, but with someone that likes to sell. Better to get that person on your team after they pay you some money.

> To really really beat them, we will need to inject some cash and start the PR channels, conference attending and spend a lot of time in marketing. I hate doing that. I am happy to develop the product. Very happy to meet customers and present the product, and strongly convinced the world deserve to know about our product.

Why would you compete directly against their strengths? It doesn't sound like you can outspend them. Play by different rules. Focus on being more creative, more targeted in your customer acquisition, more focused in your messaging, more good.

I'd also consider ways you can outsource components of your codebase instead of the full thing.

Open sourcing doesn't necessarily mean the product will get better. There are often "fights" in the open source community, and you could spend a lot of time discussing what features to add or not add instead of implementing them. (This of course all depends upon the method in which you open source the project/product.)

If you like developing and dislike marketing, use some of that $50K and hire a marketer. You don't necessarily need lots of money to market, it just makes it easier. For example, you probably missed a good free marketing opportunity by not mentioning the name of your company or your site in this post. Try and find someone to help you become a bit more clever and tactical in your marketing efforts, and it will probably pay off much better than open sourcing. My $0.02...

Sleepy Cat Software, the makers of Berkeley DB, went on with a fully open-source model for 10 years until getting acquired by Oracle in 2006. They however started the company around an existing open-source product, so it may or may not be relevant to your case.

Open source is a different business model - you won't be able to do SaaS and open source at the same time. You could try open core where open source would be your marketing channel, this one works - e.g. Talend or RedHat.

it seems to me open sourcing means more risks than upsides. Can't you raise funds based on your growth/customers and hire someone who will make the PR you hate?Sorry for not answering your question :-)+1 for the Docker example below

Something to think about: a proprietary program can be delivered to its users such that they have the source code. It is "open" to the licensed users who purchased the program, but not redistributable. The license can allow those users to form a community for sharing modifications to the program with each other. "Open source" doesn't necessarily mean slapping a GPL or BSD on it and blowing it out the door.

In The Mythical Man Month, I seem to recall that Fred Brooks called a program without source code to be "incompletely delivered"!

The idea that proprietary programs are only given to users in some hard-to-modify mangled code, byte code or machine language form is not some axiom of the proprietary software business.

Companies will gradually start selling services piecemeal at what will be promoted as a "discount", where you buy a tiered package of sites. "Obviously, you only need Facebook, Google, and Buzzfeed. Why are you paying for that shitty internet you don't need?"

Public praises the lower bills, talk shows argue incessantly, and nobody grasps either the tech or the economics: the price of the discount is that large tech/infra companies no longer have to worry about competition, and can levy arbitrary entry fees.

Gradually the big companies open up walled app stores that let you run your internet applications within their parameters, rules, and fees. Since this is the only way to reach anyone, smaller upstarts/devlopers grudgingly accept the new way of things, until the whole shenanigan is disrupted by a little guy meeting an unmet, undervalued need out of left field.

It would be nice if NN advocates focused on improving competition in the ISP space instead of using this as a reason to give the FCC control over yet another communication medium. Mesh networks and more ISP choice would "enforce" net neutrality via consumer signals instead of the "just make it happen" solution being proposed.

Right now most of non-neutral networks exist specially outside of the US in cellular networks. They allow Spotify or other media streaming services deliver content to the user without charging user's data plan. Most of the companies competing in media streaming space, specially those with paid subscribers are big enough to pay the ISP for the fast lane (Beats, Netflix, Rdio etc). One exception is the fast lane (or maybe VIP lane in this case) for Facebook in developing countries. I've seen Facebook let users with no data plan whatsoever use the service in Trkie. You can see how this makes it hard for other social networks to catch up.

I don't think US cable companies make a tier system for websites. It doesn't make sense. All the non-media traffic isn't much that worth the discrimination. Most of the un-neutrality will be in cellular networks and media delivery.

-- "net neutrality" -- you probably mean the currently popular version of this, which is "don't let ISPs create fast and slow lanes, and charge for the fast lanes." Or, even less precisely, "Don't let ISPs slow down the Internet."

The problem with this is, the FCC is actually not proposing to let ISPs create "slow lanes". It is proposing to allow ISPs to charge fees for better quality of service, not to degrade the service that's already provided. In fact the proposals quite specifically forbid this.

-- "if ... fails"

The problem with this is, net neutrality is not in effect now. And has not been at all in history, except for a brief period before the courts shot it down (because the FCC was overstepping its authority). And, nothing like the "fast/slow lanes" version of the predicted net-neutrality-copalypse has happened.

So to say "what if net neutrality fails" has it exactly backwards. We already know what the no-net-neutrality world looks like, we are in it now. The real question is, what if it succeeds? What will happen then?

America would be seen as less competitive. There would eventually be a brain drain in the mid-term as developers either did not emigrate, or did immigrate out of the country as other markets offer better value. Developers will start creating programs so that all traffic is masked and can not be differentiated, things like usenet will proliferate. Hardware entrepreneurs will created localized meshnets in major cities. Also, people could actually flip out. It is the dumbest thing to do from a political standpoint. Ancient Rome placated the people with panem and circus. Poverty is already pretty widespread so many people live for entertainment. If you knock this out people will wake up a bit when they have to pay a fuckton of money (that they don't have working minimum wage) for netflix.

As someone who ran a wireless ISP for 3 years, there is the possibility of new competition. Wired networks are crazy expensive, but we were able to build a profitable infrastructure by renting rooftop space on tall buildings and doing directv style installations. Consumers weren't willing to pay much, so we ended up focusing on business customers. If enough people are willing to pay for neutral pipes, it might reinvigorate competition in the space--at least in dense urban areas. Our big fear at the time was fiber rollouts. Neutral nets would be a competitive advantage against big players we didn't have back then.

You need to realize packet filtering is not without costs. Nor is negotiating with most companies. Finally, you can't get blood out of stone. Altogether meaning -- the ISPs will go after the largest of traffic producers with a threat of pay or be throttled. Some evidence, beyond what Netflix says for eg. https://twitter.com/msonnabaum/status/504073659124703232 suggests something like this is already happening. But I can't see Verizon putting up an online shop saying "Buy X TB of VIP traffic for your domain". In the long run -- perhaps even that will happen. And then? And the you will pay...

At first nothing. Most of the change will be behind the scenes where ISPs will start charging content provides more and more to deliver their content. They'll leave the little guys alone, and on the slow lanes, for now. But if your site gets popular plan to pay the piper! After a while, say 5 to 10 years the ISPs will lick their lips and start offering competing services. They will keep these services at arms length so it doesn't look so much like a competing service, e.g. NBC (which is Comcast). They'll squeeze the various third party players and buy some of them up in the end.

So the future looks a lot like the past: ABC, CBS and NBC with a smattering of a few others, e.g. Google.

Quality of service will remain, at worst, as it currently is, and no one will notice a difference.

Netflix et al. will continue to host cache devices with ISPs, torrents will still work, video chat will still work, and chances are no startup will ever be forced to pay ISPs to deliver their packets.

No one will ever be presented with the option to purchase a "Social Media/Streaming/whatever Internet Package," but maybe they'll be offered the option to upgrade to a more explicit SLA with bandwidth/latency guarantees.

Americans have swallowed second rate telecommunications services, extortionate prices and lack of competition for ages and will continue to do so, because the alternative is evil socialist government regulation.

Do you need them online for any particular reason? At 50GB, I'm assuming it's all your raw camera data, so obviously not all of it needs to be shared with friends?

If so, buy yourself a small NAS with two 500GB or 1TB drives in it (it'll cost you less than $200), and configure them as RAID-0. This will give you redundancy (not backup), and availability on your network. Get another 500GB or 1TB portable drive, and backup your NAS to that once a week, or once a month, depending on how often you add photos. Ideally store this drive offsite, or in a safe or similar, because this is your backup drive. Most NAS drives will also allow you to share the content, but due to security concerns I would probably not recommend that. If you need access to them away from home, setup a machine with SSH access to your home network, and access the drive that way via VPN (although this is a completely different topic).

Generally, with technology being cheap, I'm anti storing any valuable personal data in the cloud. If you do need or want to share some of the photos, find a service that allows that (there are plenty), but definitely don't use it as your primary storage or backup service.

Note that the above is pretty much my setup, and it's been serving me well for a few years now (with a similar amount/size of photos).

Flickr is actually not a bad option. It's been around the longest and Yahoo is actually finally putting some weight behind it. Compared to general file storage services like Dropbox, Flickr offers 1 TB of space. You don't have to worry about hitting the ceiling on limits. Also, although many people associate Flickr with professional & public photos, it is very easy to make pictures private by default.

Dropbox just upped the "Pro" account from 100GB to 1000GB. That's more than enough to store all the pictures you'll take in the next few decades. The benefit of something like Dropbox or its various copycats is that the file is stored on each of your computers as well as being stored in the cloud. So you really aren't putting all your eggs in one basket either locally or remotely.

The way I am reading this, even if you went paid you'd barely cover your costs (given how time consuming it is for you to bug fix). Plus without the free "trial" you'd struggle to attract paid customers, but while the paid "trial" exists people can just re-register to get all their files or otherwise only needed one page anyway so won't pay.

So my question is this: How much does running the service cost? If it is fairly inexpensive to run you could go a mixed "ad supported" and freemium model, with zero more bug fixes. Just sell what you have.

The vast majority of your revenue would come from adverts, and while it might never be a screaming success, it might at least make a little profit year upon year and eventually pay for the effort you put into it.

But if it is expensive to run as is then I have nothing. You'll just have to try to make the paid model work.

We regularly perform PDF extractions at my startup. For each new client, we'll run batches of several thousand at a time.

A more attractive monetization model for a customer like us would be $0.01-0.03/conversion ($100-$300 per 10,000). A low per-conversion cost would easily allow us to test for a given group of PDFs if the conversion service was a good candidate for that batch, and if not, chose an alternative up-front (but allow us to test again the next batch easily at low cost). Also with a low start-up cost, its much easier to tell customers you won't make any specific fixes (take it or leave it, and test it first). Then you'd have the flexibility to work on broad classes of problems/improvements more at your leisure.

Ditch the free plan and make it a subscription service. Make it clear that some data can't be automatically extracted, and charge a per-page premium for manual extraction. If you don't want to do that work yourself, farm those jobs out to people on mechanical turk.

Sounds like a fairly niche product. Have you given any thought to that aspect? I've build a few too many products that are too niche. When eventually I woke up to that I just abandoned the projects. What's the point of building something for a handful of people.

I suspect what is driving your question is that you're mystified how you can be paid to produce work which isn't meeting some need, or being tangibly important in some way. If you're working on stuff which never reaches production or is immediately retired or restarted then it probably seems to you like a bad way to run a business.

I can sympathize. I worked for a bank in a role doing tasks which, to me, clearly did not meaningful add to the companies bottom line. In my estimation, my (and my department's) existence was a drag on the bottom line. I constantly found myself amazed that the company spent so much money in inefficient counterproductive ways. So I wasn't honestly all that surprised when my department was wiped out last week and I was laid off.

I think ultimately you're right: when it's all vapor then there will likely come a day or reckoning. But you never know how soon they day will come. Maybe it's a proactive restructuring of the company and they downsize and cut because they realize the error of their ways (and pivot to producing more value), or maybe it happens when the economy tanks and money gets tight.

I think you'd just be smart to continue to diversify your options however long you work in your current position. Play your cards in such a way that if you ever wanted to leave or had to leave, you would be able to frictionlessly pivot to something else. If you can do that then I say don't sweat making a buck off your employer's vapor production. When and if the gravy train comes to a halt, you'll be ready to do other things.

On the other hand, if you're not happy in your job--i.e., if you don't like your work, your colleagues, the environment, or your boss then consider staying there just long enough to make it legit (probably about a year) and then go looking for something else.

I currently work for an MLM business. It literally is a pyramid scheme.

I'm shopping around for something better, but the pay is decent.

Standard Advice for your situation. Do the best you can in your current job, while looking for something better. You already have a job, so you can be somewhat picky about your next project. Knowing that you will have an new job in 1-12 months means that it's easier for you to put up with their foolishness for now.

I got accepted but I've to travel a long way -- from India, is it worth it? I do have plans to set up a bunch of meetings pre and post event, though. (oh and how difficult is it to get a meeting scheduled with big names? I know it's a naive question but still...)

I'll be renting a car from SF. For folks wanting to carpool with me, sign up here with "techtivist". Others with a car, feel free to add yourself here as well. http://www.groupcarpool.com/t/97khv4 First come first serve. It should come to around $20 each (including gas and rental) per head, against $80-90 Uber ONE WAY! I'll be leaving from Richmond, but can pick up from anywhere within SF or a short diversion from 101.

Dumb question from an out-of-towner: Does it make sense to stay in a hotel somewhere in the Mountain View / Sunnyvale / Cupertino area and use Uber to get around? I'm not a fan of bay area traffic, so I'd prefer to Caltrain from the airport to a hotel and use Uber after that if it's feasible.

Got accepted, not sure whether to be excited or not. Could be one of those things where most everyone who applies gets accepted because most people don't end up coming. (anyone know numbers on that?) Pretty sure I will go...2000 miles isn't really that far...