The NY Times open sourced a very cool tool "streamtools" that was built in Go: https://source.opennews.org/en-US/articles/introducing-strea...
Your question also reminds me of an interesting talk I saw at RICON: https://speakerdeck.com/al3x/nobody-ever-got-fired-for-picki...
As long as it increases developer happiness; I'm game with whatever language. :D
As noted in other comments, most of HIPAA is not technical. Most of the requirements relate to risk assessment, policies, training, incident response, etc.
With that in mind, I'm going to quickly run down all of the major moving parts and then cover some of the technical considerations for setting up a server.
HIPAA has three main rules you need to comply with:
1. The Privacy Rule - Governs the use and disclosure of PHI (protected health information). Applies to all forms of PHI (verbal, written, electronic, etc.).
2. The Security Rule - Governs safeguards for electronic PHI
3. The Breach Notification Rule - Governs your responsibilities during a security or privacy incident
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.
5. Implement backups according to your organization's HIPAA contingency/disaster recovery plan. Document the backup scheme.
A few caveats:
- I haven't addressed application-level security. The same requirements apply, but the implementation differs.
- Your customers will demand additional safeguards that aren't in HIPAA.
At Aptible, we help with all of this, plus all of the other requirements (risk assessment, policies, training, etc.), so you can get a complete handle on your compliance status.
- 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).
- All PHI over HTTPS if you have a webapp. NO PHI OVER EMAIL OR HTTP.
- "Soft" guidelines such as password complexity measures, auto session expiration, disallowed multi-sessions.
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.
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.
However, you may want to have a look at TrueVault which has been featured on HN.
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).
training-hipaa.net provides Server Disaster Recovery Plan Template which is the part of HIPAA Compliance.
This Server Recovery Plan documents the strategies, personnel, procedures and resources necessary to recover the server following any type of short or long term disruption. You can find more information about this over here http://www.training-hipaa.net/template_suite/Server_recovery...
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 $$$.
I believe that rackspace has a pretty program around compliance.
That said, the thread does have some great safe guards and industry best practices you should look at.
We sell cloud but focused on security, compliance, and performance. Check us out.
Check out TrueVault - HIPAA-compliant data store that is a YC grad.
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.
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?
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 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 would also just write random blank rows all the time whenever we did concurrent writes (this is a known bug https://www.parse.com/questions/duplicated-empty-objects-cre...). They have just moved over to the Facebook Developer bug tracking which is pretty awful as well.
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.
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.
One that I have encountered is when uploading files, the progress callback jumps from 0% to 100%. https://www.parse.com/questions/parsefile-progresscallback
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!
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.
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.
Beyond that, there are some good use cases for apps to be built upon Parse and bad ones. It turns out that the thing I'm building is one of those bad use cases.
Parse appears to frown upon background processes. They have very tight restrictions on what can be done in the background and how fast it must be done.
If you have a social-esque app, at any kind of scale, fanning things out becomes a problem.
We're in the middle of packing up our toys and heading over to GAE.
This guy has compiled a good list of limitations: http://profi.co/all-the-limits-of-parse/
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 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 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.
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.
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 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.
But now GNU Emacs has them, so the only people still using XEmacs are approximately the people who got set up on it 20 years ago and don't feel like changing.
It still exists because things don't pop out of existence when their main reasons for having been created long ago go away.
It is the same thing as asking why German is still used, now that English is a world language.
It sort of reads like "A customer comes to my website and asks me what's the best price I can do on a pair of Beats Headphones." Is that right?
Why would a customer enter a bartering phase with you, rather than just seeing that Amazon sells them for x?
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)
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, we're left with cost. The rest is just what you can stomach.
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.
What sort of encryption? Hardware? Software? If software, what platform?
If you use hardware encryption, it will work independent of OS platform.
You can buy removable flash drives and rotational media both with built-in encryption: http://www.wired.com/2012/07/reviews_secure_hard_drives/?vie... and http://www.pcworld.com/article/254816/the_best_encrypted_fla... for example.
You can also buy hardware encryption enclosures for rotational media (or I guess SSDs) of your own provision, as well as use hardware encryption pass-through adapters for USB flash drives (or any USB media, I suppose): http://www.zdnet.com/encrypt-all-your-usb-storage-media-with...
TrueCrypt was (and perhaps still is) the best cross-platform option.
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.
Off the top of my head:
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.
* Maybe I'm just whining.
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.
Everyone wants to "make something people want" (you can do the "make" part for sure) and "be relentlessly resourceful".
Another thought is that if you're comfortable as a manager, and are already freelancing, then perhaps you could explore replicating yourself and building a consulting/services business.
No one want to buy a software, they are looking for solutions. Solutions that saves them time or money or both.
Based on reviews that I've read (not compared personally) they are much better than comparable beats.
These cans are a tad on the expensive side but worth it
Very comfortable, Have neutral frequency curve. And have enough bass, just the right amount of base.
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.
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.
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.
Not sure if it's helpful.
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...
The faster the web moves away from SHA-1 the better, and rewarding companies that are already abstaining from SHA-1 contributes to our collective security, in the case of HTTPS.
You should also do it for purely selfish reasons. Chrome is sunsetting SHA-1 for use in certificate signatures, and Chrome will eventually show SHA-1 certificates as insecure. See the link below.
Here's a visual comparison I put together:
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).
Our homepage is https://certly.io, shoot me an email at email@example.com
they are good with price and service, you may give them a try.
2 Years wildcard for $59.90
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).
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.
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.
EV certs are supposed to communicate certainty 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).
 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.
2. No. An EV cert is nice little warm fuzzies, but the absence of it doesn't really tell me anything useful that would dissuade me from making a purchase.
3. 2. 1. Go!
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.
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?
* Did you think about performance marketing, e.g. AdWords?
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 ?
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.
So far so good, standard business stuff.
>> I hate doing that.
Here lies the problem IMHO. To make your business a success, you need to do stuff you don't necessarily like, enjoy or are familiar with.
You think of "open sourcing" as a lazy marketing channel that will keep you in your comfort zone. It doesn't work like that.
You could either find a co-founder or hire someone to handle that stuff. Or, you could suck it up and do it yourself.
"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."
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:...
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 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.
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.
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.
Basically, what d0m said is pretty much dead-on, IMO.
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.
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.
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...
http://waxy.org/random/arsdigita/ might be the best textual source on the web, but if you can rustle it up (download link not working for me), Greenspun's IT Conversations interview is a good listen:
You say that your competitors are better at PR. Have you analyzed your growth and PR strategies?
What is your competitive positioning? Are you cheaper? Are there fundamental technological advances that you have that make you innately better?
Here is a cheat sheet that is sort of the standard when it comes to competitive strategy: http://en.wikipedia.org/wiki/Porter_five_forces_analysis
Also, if you've stolen customers, and your marketing is non existent, then maybe you should just fix your marketing and not radically change your business model.
Open-sourcing the product is only going to help it grow in very specific niches, and open source projects often succeed because someone behind the project is very good at marketing and PR.
If you are shipping software that runs on client hardware (e.g. a database) it might make sense.
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.
Do everything that isn't work.
Then maybe go on a day trip or a vacation. Just enjoy having time off.
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.
And the cycle repeats.
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.
Consequently, Youtube is pretty slow on this ISP.
"If net neutrality fails"
-- "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?
It will likely lead to a massive decline in American supremecy.
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.
Maybe some kids will DDoS an ISP or two, but the effect will be nil.
That's my prediction.
e.g. ISPs like CBS or AOL?
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).
But you should also curate and print out some of your photos. This was discussed on HN just a couple of weeks ago: (https://news.ycombinator.com/item?id=8129457). The linked article (http://commandcenter.blogspot.com/2014/08/prints.html) reminds us that we're living in a "digital dark age" that's likely to leave few traces in history. Furthermore, even if your great-grandchildren could read the photo files you store today, do you really expect them to look at all of them?
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.
Instead of selling PDF conversion you sell convenience. You give your paid users an identical product but allow them to queue up dozens, even hundreds, of files via some basic desktop program maybe. Alternatively auto-magical conversion via email (PDF comes in, plain text goes out). Plus turn off ads (e.g. make free users wait 20 sec on an ad page).
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.
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.
I'd switch to having paid jobs only, but offer a money-back guarantee. Any users that take advantage of this offer too much could be turned away.
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'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.
Any clever solutions?
How about 4pm, Sunday September 21, Ritual Coffee on Valencia Street?
If interested, ping me at firstname.lastname@example.org or http://twitter.com/yurylifshits