Instagram says it now has the right to sell your photos - <AUTHOR> http://news.cnet.com/8301-13578_3-57559710-38/instagram-says-it-now-has-the-right-to-sell-your-photos/ <comment><USER2> I'm starting to realize that Instagram is not the service I thought it was. I initially thought it was Flickr with social features, but more and more it's turning into Facebook with photos.

There is zero content discoveries features, so you have no way to get new followers or find new people to follow. And the top posters are all teenage pop stars that I've never even heard about who post completely uninteresting photos.

The more Instagram turns into Facebook, the more this opens up a spot for another company to build an actual social network around photos. Whether this will be 500px, Flickr (again), or somebody else entirely, I don't know.

<comment><USER3> As soon as i read that FB was buying Instagram i quit and deleted my Instagram account. It was too predictable that something like this will happen.

Mark Zuckerberg is in a horrible position. I bet he would love to just build a cool and useful product. Instead he is damned to roll out all these awful money making features. And quick. Not only for his investors but also for the staff that owns FB stock.

How smooth could FB move along if their investors trusted them like they trust Jeff Bezos and his very long-term view.

<comment><USER4> What's the alternative? A cool and useful product that makes revenues how? How do you propose that Instagram actually make money?

Not attacking. Just wanted to hear more specific thoughts.

<comment><USER5> Would it be viable to let users opt-in to selling their photos, with users and Instagram splitting the money? That seems to be a system that would appeal to both sides.

</comment></comment></comment></comment><comment><USER6> This is not new. It seems that their new TOS explicitly lays out that your photos may be used in advertising, possibly due to a new law somewhere requiring specific notification and release, but my understanding is that _you'd already given them this right_ based on this clause:

 _By displaying or publishing ("posting") any Content on or through the Instagram Services, you hereby grant to Instagram a non-exclusive, fully paid and royalty-free, worldwide, limited license to use, modify, delete from, add to, publicly perform, publicly display, reproduce and translate such Content, including without limitation distributing part or all of the Site in any media formats through any media channels, except Content not shared publicly ("private") will not be distributed outside the Instagram Services._

Yes, that's in the _old_ TOS, and it's pretty much boilerplate for any site with user-generated content. That language certainly seems to me like it would cover uses in advertising or even Instagram reselling your images as a "stock photo" site. This kind of clause is required so that users can't attempt to entrap the service provider by uploading content and then claiming that Instagram didn't have a license to utilize it and therefore had violated copyright, and also probably as a fallback policy in case a cranky user spotted their image in a stream or feed or video or something (or, alternately, that the server is hacked and db is leaked, and thousands of claims of "unauthorized use" come flooding in).

IANAL but pretty much this is a non-story. They've simply decided to _specifically_ inform you that a license to " non-exclusive, fully paid and royalty-free, worldwide, limited license to use, modify, delete from, add to, publicly perform, publicly display, reproduce and translate such Content, including without limitation distributing part or all of the Site in any media formats through any media channels" includes use in advertisement, as one would reasonably believe it does.

<comment><USER7> Agreed with aptwebapps. The old TOU, as you correctly say, is pretty standard. Twitter's is similar, and any company with decent lawyers is going to protect themselves with similar wording.

The new TOU, however, heads in a different direction. The phrase "limited license" is gone. It's been replaced with the phrase "transferable, sub- licensable" license. Also new is "a business or other entity may pay us to display your... photos... in connection with paid or sponsored content or promotions, without any compensation to you."

Transferable is a very important word. So is sub-licensable. Those were NOT in the old terms of use.

<comment><USER6> It really doesn't seem like a material change to me. Again, IANAL, so if there is some reason to believe these things would be disallowed under the old TOS, I'd like to know, but it sounds fairly straightforward. While Instagram may have had a more difficult case under the old TOS, and may have had to be more careful about the dispensation rather than just doing a blatant "stock photo"-type interface, I could definitely see an attempt at the argument that representation in "any media formats through any media channels" covers Instagram in most cases of what would be considered "transferred sub- licensing".

The clarifications, of course, are intended to clarify the consent they're taking. I'd be interested to know their motives for this; as I speculated in the parent, does a new law take effect in an important market with regard to advertising? Are they just trying to play it safe? Are they going to make aggressive moves into this kind of space (reselling user photos, using users' profiles without consent in advertisements) and wanted to ensure that they didn't have to deal with any lawsuits upon launch?

I will agree that the new TOS allows them to use your profile and likeness as they see fit, which based on my simple layman's reading, isn't included in the old TOS.

Just thinking out loud here, move along.

<comment><USER8> You granted _Instagram_ a license. Under the old ToS, an entity that wasn't Instagram, say a nightclub, couldn't use your pictures on their own promotional materials, advetising, or site without obtaining a separate license from you, _period_. This changed.

<comment><USER6> Right, I'm aware "that changed". I'm not sure that "an entity that wasn't Instagram, say a nightclub, couldn't use your pictures on their own promotional materials, advetising, or site without obtaining a separate license from you" is really true, though. If a night club was working in clear collaboration with Instagram and published your photos on its promotional materials, that would seem to be covered by Instagram's license to replicate your content in "any media formats through any media channels", as _Instagram_ exercised their license to place it there.

As I said, they'd probably have difficulty operating as a blatant competitor to iStockPhoto, but I think if they'd structured things with a modicum of cleverness, their old ToS would allow them to get away with most of what's explicitly covered in the new ToS.

<comment><USER9> There is a difference between a contract that "Joe can use this" and one that says "Joe can let anyone use it". Sure, if Mary uses it Joe can say "She's just using it for me", but UNLIKE code, the law is not completely decimated by a single loophole. Judges and juries can see through blatant abuses and rule that the contract did not cover that use. ("Can", not "will", but even the chance is enough: a 1% chance of losing a 100-million dollar class-action lawsuit is a million dollar cost, plus legal fees.)

<comment><USER10> _Judges and juries can see through blatant abuses and rule that the contract did not cover that use._

I've seen this observation mentioned a few times on HN and it seems quite right. The letter of the law may say this or that, but ultimately it comes down to some form of the giggle test. You have to imagine a judge saying, "You didn't _really_ think that's what the law|contract meant, did you?"

For example, people trying to avoid penalties for unauthorized distribution of copyrighted material by claiming they own the copyright on certain large integers or are merely passing _numbers_ around, not movies or songs.

With the boilerplate TOS there may be all sorts of things that one could imagine are allowed but I'm pretty sure Instagram's (i.e. Facebook's) lawyers thought that the original phrasing would not be sufficient to clearly allow them to do what they wanted to do, so it was changed.

</comment></comment></comment></comment></comment></comment></comment><comment><USER11> There's an ethical and an unethical way to do this.

Not being able to opt out, and changing the system wholesale overnight like this, is deeply unethical.

On the scale of things they could do that would make this better:

* Best case: opt-in only, compensate users whose photos they use.

* Present a choice to users when they sign up, default to opt-out.

* At least present a choice to existing users whether they want this or not, and allow them to continued access to the service either way.

* Notify users and only change the rights when any new photos uploaded, and keep existing photos under the old terms.

* Give existing users the opportunity to deactivate/delete their account if they don't agree, and a chance to download their photos. Or "freeze" existing accounts until they acknowledge the changes, rather than automatically assuming consent.

They seem to have picked the absolute worst option available to them, and it's troubling to say the least.

<comment><USER12> It seems that you can opt out by selecting to be a "private" user.

</comment></comment><comment><USER13> I was about to delete my Instagram account when I saw this, but having given it a bit of thought, I'm actually ok with it.

Instagram needs to get money from somewhere, and as far as I'm concerned selling my photos is preferable to filling the feeds with ads. However I can see how for a lot of people they'd rather have ads then have their photos sold (especially pro photographers) so it'll be interesting to see how many users they loose over this.

Also it goes with out saying that if they do put adverts in, I'm out.

<comment><USER14> I don't understand why people have downvoted this yet far more inane comments that are older haven't been downvoted as much (case in point: <http://news.ycombinator.com/item?id=4936978>). This is an "expressed opinion" - it's not "inane banter" (like this one: <http://news.ycombinator.com/item?id=4936806>) - yet people have downvoted it because they disagree. It doesn't express the hive mind thus the downvotes rain in. So weird...

</comment></comment><comment><USER15> This is going to get interesting.

I know several professional photographers who use Instagram regularly (and are worth following). I suspect this will not sit well with some of them. I'm especially curious if Instagram will let people leave _and_ remove their old photos easily.

Some of them also post professional images they've imported from their computer ( _not_ just phone images).

For example, here's an image taken by Jose Villa (high-end wedding photographer) for Williams Sonoma's gift registry: <http://instagram.com/p/STxUVcrodv/>

What's gonna happen when IG sells ads with those kind of images?

<comment><USER16> Why is he even using Instagram? Doesn't seem like he used any filter there, did he? Seems like he's just using it to promote his own DSLR-made photos. Google+ might be a better target for that kind of community.

<comment><USER17> Because Instagram has a huge audience. Google+ might be a better place for the photos, but it doesn't have an audience.

<comment><USER18> Google+ has a significantly larger audience than Instagram. G+ is more than photos though and has a different audience.

<comment><USER17> How do you figure that G+ has a larger audience? Larger _potential_ audience, sure, given the number of Google users out there. But Instagram posts have engagement (likes and comments) on a level I've never seen on Google+.

<comment><USER18> G+ has more active users than Instagram based on the released data. They purposefully don't release too much information, but the figures that have been announced show G+ to be far larger than Instagram. Instagram claims more than 100M signups, Google claims more than 500M. I don't see MAU for Instagram, but Google+'s MAU is 135M which is more than all of Instagram's signups.

Like any social network, what you see is dependent on who you are and how you use the service. Instagram is much more wide open than G+ as well, people are much more likely to share content to only a few people on G+ and thus you'll never see that content (or any replies). From what I've heard from photographers, G+ is definitely an active place to share photos.

<comment><USER19> What makes a user "active" on G+ exactly?

</comment></comment></comment></comment></comment></comment></comment><comment><USER20> deleting your account is futile, photographs will still remain on their AWS account.

after deleting one of my accounts, I was suspicious that they would still keep the photographs.

So to test this, I made a dummy account named after where i live; nikkojapan <http://instagram.com/nikkojapan/>

i made a quick pointless photograph just to upload <http://instagram.com/p/K8bx_ZB59K/>

Here is the link that still exists to the photograph of an account that was deleted right after the Facebook acquisition announcement. [http://distilleryimage6.instagram.com/6d96aaa0a45611e1a9f712...](http://distilleryimage6.instagram.com/6d96aaa0a45611e1a9f71231382044a1_7.jpg)

<comment><USER21> This is actually kind of a big deal. Have you sent this info to any tech blogs?

<comment><USER20> I have commented on blog posts of tech blogs about it using ...but, they hasn't been noticed yet.

</comment></comment></comment><comment><USER22> So, how big is the target market for over saturated photos of someone's dinner?

<comment><USER23> A billion dollars?

</comment></comment><comment><USER24> So the claim that Instagram is establishing the right to sell your photos is supported in the article with this language:

 _It says that "a business or other entity may pay us to display your... photos... in connection with paid or sponsored content or promotions, without any compensation to you."_

I read this as intended to say "when we display your photos (as part of our own service), we may serve up ads to be displayed next to them and not give you a cut of the proceeds".

I don't mean to argue that the language _can't_ be interpreted to let FB sell the pictures but it doesn't look to me as _intended_ for that purpose.

In any case, the usual scenario of virtualized user outrage will be followed by backpedaling by Instagram. 2% of the user base will vow to never use the servie again, and then all will go on as before.

<comment><USER25> You glibly ignore the previous paragraph that references the section which establishes the rights for Instagram/Facebook to do whatever it likes with the Content.

And since when is "intent" ever part of US law (especially with regards to IP)...

<comment><USER24> You seem to argue (by the use of "glibly") that the presence of the transferability clause leaves no other interpretation possible than that that transfer will be for use of user content by third part in return for payment. However, the clause may also be there to allow use of content on other services owned by Instagram's parent.

I was quite explicit that I was giving my read of the intent, not my assessment of what Instagram _could_ legally get away with. The transferability clause does not change my reading of the intent.

</comment></comment></comment><comment><USER26> The new flickr app (albeit very late) looks a whole lot better proposition then Instagram.

To value Instagram at a billion dollars (well less now I guess because of Facebook's share price) is insane. They have a serious problem with spam - every photo I upload is liked by many getM0refollowers<RandomNumber> and every photo I upload is bombarded with spam comments. They seem incapable of getting a grip on this problem.

The app also has bugs e.g. it says I have X followed but then displays X minus Y when I try to view who they are.

Its popular photos are rubbish - so there is no way to discover interesting photos other than searching for tags you're interested in. Photos with a 1000 likes appeal to the teenage market only i.e. they're not serious photos.

When you follow someone you get very large photos dominating your stream, so I don't follow many people because of this.

I really hope flickr aggresively try and take back this market. Instagram is a neat idea, but has very poor execution.

<comment><USER27> I don't really know what Instagram is really worth, but it might have been worth a billion dollars to Facebook to keep Instagram away from Twitter. Twitter + Instagram is starting to look like a viable Facebook competitor.

Although we know now that Twitter is choosing to become a walled garden with a very limited kind of service, a year ago it seemed possible for them to become a sort of internet infrastructure.

</comment></comment><comment><USER28> I fully understand that with a free product, I am the product. I go into that with eyes open, and happily used Instagram assuming they would eventually start serving ads near the photos, promoting photos or similar. However, using my photos as ads seems a bit of a stretch. So, I just happily gave Flickr $25 after deleting my Instagram account. Some things are worth paying for, because sometimes I don't want to be the product.

<comment><USER29> With Flickr you're still the product unfortunately, although Flickr is much better than other similar services in this regard. Do you really think your measly $25/year cover for their expenses with you?

Seriously, if you don't want to be the product, organize those photos in a standard directory structure and synchronize it either with Dropbox or Google Drive or SkyDrive.

The downside of doing that is that storage is more expensive, but that's closer to the real price the service is worth and so that makes it sustainable. Also, migrating between cloud storage solutions is much easier.

Shameless plug - try Dropbox by clicking the following link, and we'll both get a small bonus: <http://db.tt/x1XoSUnE>

<comment><USER21> "Do you really think your measly $25/year cover for their expenses with you?"

Actually, yes. Hard drive space is incredibly cheap, especially at their scale. My photos aren't terribly popular, so they aren't using much bandwidth either. I probably cost them $5-10/year, tops. In fact, I'm probably one of the majority, the ones who subsidize the heavy, uber-popular users with tens of thousands of followers who upload hundreds of photos a year.

<comment><USER29> > _Hard drive space is incredibly cheap_

Actually, no it isn't and at scale it makes it even more expensive, because you need redundancy. We are talking about RAID and CDN, not to mention that at scale hardware breaks a lot more often.

What actually makes it palatable for businesses such as Yahoo or Google is that many people pay for this storage without using it, while heavy users that share a lot help by marketing the product through their sharing to others.

On the other hand I've got 50 GB worth of data uploaded on Flickr. You can't tell me that 50 GB of redundant on-demand storage is worth $25 / year, unless you live in some kind of fairy land. I also have only a couple of photos shared. So what value does Flickr get from me?

<comment><USER30> >Actually, no it isn't and at scale it makes it even more expensive, because you need redundancy. We are talking about RAID and CDN, not to mention that at scale hardware breaks a lot more often.

That's related to reliability not scaling per see. Building a highly reliable system is far cheaper when you reach the scale of Google or Amazon because you can rationalize purchase. Actually, I bet price of hardware can totally be neglected next to admin and bandwidth cost.

> On the other hand I've got 50 GB worth of data uploaded on Flickr. You can't > tell me that 50 GB of redundant on-demand storage is worth $25 / year, > unless you live in some kind of fairy land.

I must live in fairy land. :-) You can buy 4 decent 1TB for 400$ that will allow you to cater for 20 users at 20$ per user. Conservatively you can expect them to live 3 years on average which brings the cost to 7$ per user per year. Add a 400$ server good enough to do software RAID. Let's say 5 years of life expectancy it adds 5$. It's 12$ per user plus network cost on a lan.

Flickr uses better material and pay bandwidth and admin. But they have economy of scale and can put far more than 20 50GB users on 1TB on average because a lot of them don't use them fully. I think they are above break even point at 25$/year.

<comment><USER21> And that's assuming every user has 50GB worth of photos - which, for the record, is _a lot_ of photos. Most are probably in the low hundreds-of-MB range, which brings your cost per user down by an order of magnitude, at least.

</comment></comment></comment></comment></comment></comment><comment><USER31> Dont worry! The founders of instagram where afraid of this as well and they devised a poison pill before they sold out! All you images have been made useless for any commercial use by the application of shitty "lets make it look like a polaroid left in the sun for 30 years"-filters...

</comment><comment><USER32> I'm beginning to adopt a "I don't sign up for your service/social network if you don't know how to make money other than sell me someday" mindset because I'm sick of being burned. First the Twitter debacle, and now this. Instagram should be inspired by App.net, not Twitter. Sorry guys, I'm canceling my account. Flickr is starting to show signs of promise as a decent photo service again, and I'll happily pay them money for a Pro account.

Buh bye Instagram. Hope that ad thing works out for you. (Not.)

</comment><comment><USER33> Posted some related stories:

* [Instagram's suicide note](<http://news.ycombinator.com/item?id=4934271>)

* [Instagram Will Share User Data With Facebook According To Its New Privacy Policy](<http://news.ycombinator.com/item?id=4932765>)

The last one may be more interesting than the usage rights for photos.

<comment><USER34> Those are both the same HN URL - looks like you mistakenly copied the URL for the 2nd by the 1st. :-)

<comment><USER33> There we go, thanks. At least the most important one was the one that was copied. :)

</comment></comment></comment><comment><USER35> It doesn't matter who the target market is. This can create a precedence, and make other "social" enterprises greedier. While I understand a contract can specify almost anything and there's always "if you don't like it, don't use it" way of looking at this, but there should be a basic sense of decency among all that claim to be serving the wider public.

<comment><USER36> Sense of decency often loses against profit. That's why I think this quote from RMS is relevant when it comes to the old "if you don't like it, don't use it":

 _"All in all, I think it is a mistake to defend people's rights with one hand tied behind our backs, using nothing except the individual option to say no to a deal. We should use democracy to organize and together impose limits on what the rich can do to the rest of us. That's what democracy was invented for!"_

<comment><USER37> From a much much more cynical view: Democracy was created so the rich could convince a majority to tie the hands of a minority.

<comment><USER38> Just as laws have the effect of protecting the rich from the poor. I will explain the rationale behind that argument if anyone asks.

<comment><USER39> Yes, please do. Thanks.

<comment><USER38> People are very predictable if you know enough about them. <http://en.wikipedia.org/wiki/Correlates_of_crime> Criminality is essentially a combination of low dopamine, low serotonin and low adrenaline levels. Stress chemicals such as cortisol can rapidly deplete neurotransmitter levels. There is also an inverse correlation between socioeconomic status and criminality. Being poor means more stress and lower levels of those neurotransmitters.

The impulsivity caused by dopamine deficiency also causes more unwanted pregnancies - another risk factor for criminality.

Poor people are also more likely to be religious - [http://www.gallup.com/poll/116449/religion-provides- emotiona...](http://www.gallup.com/poll/116449/religion-provides-emotional- boost-world-poor.aspx) and being religious is correlated with criminality.

So there is clearly a strong correlation between the effects of being poor or in poverty and criminality. Since the law is specifically designed to 'deal' with criminality, it is a mechanism which is quite biased against the poor. Hence, the law is there to protect the rich from the poor.

<comment><USER39> Thank you!

</comment></comment></comment></comment></comment></comment></comment><comment><USER40> What I am trying to figure out is: does this apply to 'private' accounts as well? I see no statement that seems to exempt private accounts from these new policies, but would definitely like to hear a conclusive statement regarding this.

<comment><USER7> I think it's fair to say that private accounts are probably not covered, but it would be nice for Instagram to make it clear one way or another.

</comment></comment><comment><USER41> InstaByeBye.com coming soon. 1 Click exports and online photo log. Stay Cool. 3 hours and counting. Live update = @instabyebye

<comment><USER33> My main concern as a passive user is finding a way to export likes and follows. I haven't really posted that many photos, but there is still something to lose as a lurker.

</comment></comment><comment><USER42> "you acknowledge we may not always identify paid services, sponsored content, and commercial communications"

Translation: You accept that we may try to trick you.

I'm an intellectual property lawyer and I think the intent behind the above language is quite clear. It is not aimed at alleviating an undue burden of identifying commercial content (as Instagram might suggest), it's about reducing transparency to allow for marketing tactics that would not likely be viewed favorably if they were obvious to the user. While under no legal obligation to do so, Google has been identifying sponsored content for over a decade. If we were to begin by looking at "standard practice" then we might start there.

I think it's great that people are reading TOS from web companies and making their concerns known. We might call this negotiation. If you accept that idea, then I think users are in an excellent bargaining position. They can walk away at any time. They can adapt and they can find new alternatives. These companies however may not be able to find new audiences so easily. I believe they will take the feedback very seriously and respond, with new language if necessary.

I'm noticing some of my friends on Facebook who were using it extensively for one purpose or another are now closing their accounts. Other friends of mine cannot use Facebook because of their employers. It seems clear to me there are both costs and benefits to using Facebook or Instagram and that sometimes the costs may outweigh the benefits.

Keep reading TOS. It is good for the web.

</comment><comment><USER43> While this isn't reddit, this would probably be a good time for that "That escalated quickly" picture.

I'm surprised Facebook is moving so quickly to try and monetize Instagram. I wonder if they're using it for experimentation of what their user base will accept. Regardless, I think this is probably a step too far in the wrong direction.

Will Facebook and Instagram be able to clamp down on users with the right acrobatics to keep their userbase and increase their ARPU? Either way, these seem like shady tactics.

</comment><comment><USER44> Instagram's new TOS[1] state:

      To help us deliver interesting paid or sponsored content or promotions, you agree that a business or other entity may pay us to display your username, likeness, photos (along with any associated metadata), and/or actions you take, in connection with paid or sponsored content or promotions, without any compensation to you.

In other words, they're trying to monetize Instagram a similar way Facebook is - Sponsored Posts - your photos and associated data can be promoted by companies without having to notify you about it.

Furthermore under Section 106: Exclusive rights in copyrighted works aka. 17 U.S.C. § 106[2] Instagram _cannot_ sell your photos and it _cannot_ use your photos and alter them in any meaningful way.

Having said that Instagram could have communicated this better as this hasn't helped the situation either.

[1] <http://instagram.com/about/legal/terms/updated/>

[2] <http://www.copyright.gov/title17/92chap1.html>

====

NOTE: Also posted this at: <http://news.ycombinator.com/item?id=4939663>

</comment><comment><USER45> I doubt this policy is going to last long - the biggest and most important Instagram users as far as I can tell are celebrities (incl. professionals and other popular persons), and they sure as hell will do something if Instagram starts selling/licensing the photos to anyone who wants them.

Coupled with the other big mistake of separating themselves from Twitter, I'd say Instagram is well on their way of becoming the next MySpace.

<comment><USER46> I'd suspect that on the flip side, if Instagram does intend to do this sort of thing, they will have a well-curated list of "who not to piss off".

That being said, said celebrities, professionals and popular persons also agreed to the same TOS...

</comment></comment><comment><USER47> If we assume that the good folks at Instagram (or at least their lawyers and public relations people) are not complete idiots, then they have no intention of actually following through with this change. Here's a prediction: it will be dropped due to "user feedback" or some such in a week or so and everyone will have a warm, fuzzy feeling.

The question is, what do they actually want to accomplish by floating this trial balloon?

</comment><comment><USER48> Instagram isn't about to become iStockphoto. There's no way they're going to let people buy pictures of other people to do what they want with them. More likely they want the option to use photos to help advertise. For example showing photos taken at a hotel on the hotels website or on the hotels facebook page without users moaning that they're being used without permission.

<comment><USER49> Those sorts of uses are exactly what some more professional photographers would want to prevent. It's exactly why I never uploaded any of my tens of thousands of scenic photos to Panoramio. People can use their API to display photos on their sites.

<http://www.panoramio.com/api/widget/api.html>

[http://www.panoramio.com/api/widget/api.html#conditions- of-u...](http://www.panoramio.com/api/widget/api.html#conditions-of-use)

</comment></comment><comment><USER50> Wow. Wonder if their users will be bothered to care

<comment><USER2> I wouldn't much care about my Facebook statuses somehow being used as advertising, or even my tweets for that matter. They're just things I've said publicly and social networks have trained me not to expect any control over them anymore.

On the other hand, photos are much more personal: they're works of art, at their own level.

So I think whether you care or not depends not only on your stance regarding privacy and all that, but also how you frame your use of Instagram: is it a way to post status updates disguised as photos, or photos disguised as status updates?

<comment><USER51> > social networks have trained me not to expect any control over them anymore

I think this is the major issue that will define the internet landscape in the long term. People indeed got _trained_ not to care about privacy and just like with "war on terror", they gradually give up their rights and freedom for the sake of "security" and "better user experience".

Soon enough anyone who speaks out of user rights or privacy will be seen as a mad man akin to RMS these days. 10 years back, a site, which required a scan of your government issued ID in order to change your name would be deemed insane. Now it's a common practice.

Welcome to the Matrix, gentlemen.

</comment></comment></comment><comment><USER52> What a wonderfully missed opportunity. Had they decided to share profits from content with authors they could attract more professional photographers to their service. I can't imagine any pro author will publish beautiful photos on Instagram now, and I suspect the service will just be flooded with amateur photos. And who is going to pay them for that?

<comment><USER53> Yep, make that an opt-in feature, add some light ads, and you have a full business model.

I believe they may have just wanted to spare themselves the headache of a money system and of people who would reupload other people's pictures or copyrighted works for their own profit.

</comment></comment><comment><USER54> I hope casual and regular Instagram users riot over this change (doubt it, really), honestly, not for their sake, or to spite Facebook or Instagram, but simply because I'd really hate it if they started doing this, and it turns out to be an awesome money maker. I don't look forward to a web where that precedent is set.

</comment><comment><USER55> Anyone else completely see this coming at this exact point in time when first hearing the acquisition announcement?

</comment><comment><USER56> Isn't it possible to use app.net to build an Instagram-like network without this whole monetizing problem?

</comment><comment><USER57> You can easily move your instagram photos to Flickr with this web app we created today if you don't like their policies.

<http://freethephotos.com>

We wanted to move ours, so we built this handy thing and decided to release it. Let us know if you run into any issues.

</comment><comment><USER58> I wonder what this means for <http://instaprints.com>.

<comment><USER59> To my understanding, it means Instagram can do a direct deal with Instaprints and cut out the "sending profits to the artists" cost.

</comment></comment><comment><USER60> I noticed awhile back that Instagram branding was appearing in television commercials, such as recent Taco Bell ads about Doritos Locos. If companies are using Instagram content for branding it makes sense to try to change the license agreement to capitalize if you're focused on monetizing an acqusition. As we've seen, however, it will certainly anger a solid chunk of the user base.

Nick Tran, social media lead for Taco Bell talks a bit about the campaign in the below article: "<http://www.mobilemarketer.com/cms/news/content/13959.html>

</comment><comment><USER61> Guess I'll have to continue not using Instagram. All joking aside, this was the worst possible time for them to do this, considering Twitter and Flickr both attacking their space more and more now.

</comment><comment><USER62> Since you cannot delete all photo's at once, i deleted my account.

<comment><USER63> I'm having a real hard time deleting my account, because I used plus addressing in the email when I signed up for Instagram. This is making it impossible for me to log in to the web version of Instagram which is as far as I can tell the only way to delete an account… Suppose I'll have to write support, if there is such a thing.

</comment></comment><comment><USER64> Unlike Facebook, I don't think Instagram can afford these antics.

<comment><USER65> Instagram's target market doesn't care. These aren't professional photographers, or even amateur ones like flickr, they're teens and 20-somethings with camera phones who want to be able to take and share cool photos with their friends.

<comment><USER66> I bet celebrities will care when their picture unknowingly appears in some ad.

<comment><USER67> UIAM you can't publish an advertisement with someone in it until they sign a model release form.

<comment><USER68> You supposedly read and agreed to the TOS, aren't they effectively giving your permission?

<comment><USER69> The person reading and agreeing to the TOS is not necessarily the same person as the one(s) appearing in the photos. It is the latter that needs to sign a model release.

</comment></comment></comment></comment></comment></comment><comment><USER70> Hipsters begin losing interest in instagram at a reliable rate.

</comment><comment><USER71> As infuriating as I find this, I am afraid that many people won't care.

Worse, I feel that FB/Instagram will backtrack from this, and nearly everyone will forgive them. Not me. They have shown their true colors. I'm out. I won't let them sell me down the river.

Classic negotiating tactic - ask for WAY too much, then backtrack a bit, and you get more than people would have possibly let you have, had you asked only for that in the first place.

</comment><comment><USER72> I am shocked. Weren't social media platforms to be our friends and respect our privacy, pay for servers and programmers without anything in return?

</comment><comment><USER73> The hardest thing about legalese: trying to convey intent and write something specific at the same time. The intent may be in the category of "don't be evil", but the user never knows. And while it is easy to say "well, just stop using the service", the impact of networks is that it makes it less realistic to use another service. Just another signal that we live in a "Caveat User" world…

</comment><comment><USER74> Is there a lawyer around? How legal is this?

It's one thing if instagram uses a picture of you for advertising purposes, since you have agreed to their ToS. However, how do they know which pictures are of you and which are of other people? They shouldn't have any legal right to use pictures of other people for advertising purposes, as far as I understand, because there is no contract involved.

<comment><USER75> I think you are right. There are two rights involved with this: copyright and model releases. Only the person in the photograph can sign away the rights to their likeness. I'm not sure how they'd be able to use these photos in a commercial manner without model release for each person in the photos.

</comment></comment><comment><USER76> I just found out about <http://i-am-cc.org/> They propose releasing your Instagram images as CC. What I don't understand is what effect, if any, will that have on Instagram using your images for creating ads or for other uses. How would a CC license affect in this situation?

<comment><USER77> > How would a CC license affect in this situation?

Not at all. When you upload your photos to Instagram, you grant them a non- exclusive license to use them in accordance with their TOS. Licensing them under CC is just issuing another non-exclusive license to another party.

</comment></comment><comment><USER78> for those of your jumping ship, here's three tools that can help you grab your instagram photos as a ZIP or migrate them to another service:

[http://www.forbes.com/sites/limyunghui/2012/12/18/export- ins...](http://www.forbes.com/sites/limyunghui/2012/12/18/export-instagram- photos-a-few-good-tools/)

</comment><comment><USER79> This is a phenomenally dumb move. Instagram is (was) cool because of the absence of ads or any other monetization features. It was free, simple, clean, and fun. Now it begins the slow march towards a crowded, busy, ad-littered experience. And this is really bad press.

In my opinion, the decline starts now...

</comment><comment><USER80> Let us move away from these services, into a more distributed model:

[http://statspotting.com/2012/12/instagrams-policy-changes- is...](http://statspotting.com/2012/12/instagrams-policy-changes-is-it-time- to-move-everything-to-our-pockets/)

</comment><comment><USER81> The copyright issue can be a bit tricky. Assuming that Instagram goes on and sells users' pictures - who's liable if somebody uploads a picture which he/she doesn't own, and then Instagram goes on and sells that to a third party?

<comment><USER75> More than that -- how is Instagram getting model releases for everyone in the photos?

</comment></comment><comment><USER82> Wow, that was not entirely unexpected, but rather poorly executed. I would have hoped there would be a grace period were you could either remove material or mark it in such a way that it wasn't tagged with this right.

</comment><comment><USER83> Presumably Instagram would not have the right to sell photos from people that restrict the viewing of their photos in public. I have my profile set up so only those people I "approve" to follow me can see them.

<comment><USER84> The language in the TOS says "you can control who can view certain of your Content and activities on the Service". Note that key qualifier: _on the Service_. It does _not_ say that you can control who can view your Content by other means; so if they sold your photos to someone else who made them viewable through some other means, you can't control that. At least, that's the way I read it; IANAL.

</comment></comment><comment><USER38> I'll just leave this here - [http://www.thecrimson.com/article/2003/11/19/facemash- creato...](http://www.thecrimson.com/article/2003/11/19/facemash-creator- survives-ad-board-the/)

</comment><comment><USER85> Isn't this how YouTube policy works as well? As I recall YouTube is always the rights holder - if a YouTube video is played on TV the TV program pays royalties to YouTube and the user gets nothing.

</comment><comment><USER86> Didn't we expect that they'd need to find some way to make money off us?

</comment><comment><USER87> Instagram-export service Instaport is returning 500 errors:

<http://instaport.me/>

500 Internal Server Error

nginx/0.7.67

<comment><USER33> They're understandably under heavy load. It worked fine, when I tried it, though.

</comment></comment><comment><USER88> I'm not sure how Instagram has obtained my photos, but I will not stand for this.

</comment><comment><USER89> Get ready for the biggest duck face/bathroom mirror stock photo sale of all time

</comment><comment><USER90> Is there an open alternative that anyone would recommend?

</comment><comment><USER91> This is totally unfair . Now shifting to Flickr

</comment><comment><USER92> Wait don't we already do this and accuse proponents of SOPA etc. of curbing our freedom under the excuse of piracy?

<comment><USER93> No.

</comment></comment><comment><USER94> Let them sell one with your kid then you can sue their ass off.

</comment><comment><USER95> So if I repurpose a photo I found on Instagram and it becomes the next Obama "Hope" poster I have to pay the photographer _and_ Instagram? That would be lolled out of court.

Same thing with selling people's personal pics as stock photos, it doesn't matter what the user agreement says, that ain't gonna fly in front of a judge.

It would be like putting a sticker on the back of a picture frame that says whatever you put in here now belongs to Frames incorporated, NAL but it seems to me however legally binding it claims to be it wouldn't pass the smell test in court.

<comment><USER96> In no case does this require you to pay the photographer _and_ Instagram. It would be legally possible for you to pay the photographer _or_ Instagram.

This change means that Instagram could license photos published through their service to you without compensating the photographer. You always have the option of licensing the photos directly from the photographer, in which case Instagram isn't involved at all.

</comment></comment><comment><USER97> Question, with these new rules, can you still sell your pictures?

Unless you live under a rock, you know that many "Instagram girls" sell their posts to clothing stores to promote them, it's actually hugely successful!

<comment><USER98> I've been living under a rock, then. Although, it's fairly ingenious.

<comment><USER97> Maybe because I have friends doing fashion, I know it goes from 500 bucks a pop. A girl with about 100K followers. And she would say something like this:

"Awesome glasses I got them from example.com use code EXAMPLE50 for %50 off on all their inventory"

I wonder if that's still legal. Or maybe Instagram can automate that!

</comment></comment></comment><comment><USER99> If only Android let you one-click share to any social network you wanted and included all of the photo manipulation and filter features of Instagram. Oh wait.

</comment><comment><USER100> People still wondering that someone not just paying the bills, but making money in the first place, and that all these "free" services are about _making money_ by aggregating and selling user-generated content, logs and statistics?

There is no other _working_ model, btw.

</comment><comment><USER101> So long Intagram, and thanks for all the fish.</comment>


Design of the Burroughs B1700 (1972) [pdf] - <AUTHOR> https://pdfs.semanticscholar.org/cff6/6b2eba20a7172c5db281e84600049e1e82fe.pdf <comment><USER2> A few years ago there was an article like this about an old computer on HN that mentioned France's complicated railway workers pension system. Anybody have a link to that? It was super interesting.

</comment><comment><USER3> In some aspects, more details are in the earlier (1972) text by the same author:

[https://archive.org/details/bitsavers_burroughsBgnImpMay72_2...](https://archive.org/details/bitsavers_burroughsBgnImpMay72_2101971)

</comment><comment><USER4> Its interesting they essentially passed all memory reads through a barrel shifter right in the critical path. This would have been a huge performance bottleneck had the platform survived.

It is very flexible, but... costly.</comment>


Ask HN: Services that monitor computer behavior for signs of illness? - <AUTHOR>

im wondering what kind of stuff there is that can do something like look at how you type, or when you use the computer, or how much, or what you do on it, or how your patterns change, and make inferences about health. it seems like some thing's early warning signs could show up in how you type, like stroke for instance. <comment><USER2> I agree that this is possible, but to find the correlation, a full data set is needed (behavior and medical data).

As far as I know, no single entity has such a data set.</comment>


When AWS, Azure, or GCP Becomes the Competition - <AUTHOR> https://www.gkogan.co/blog/big-cloud/ <comment><USER2> While AWS has ruffled a bunch of feathers with their Elasticsearch and Kafka managed offerings which can be easily construed as attempts to steam roll the respective open source-first entities, I am actually quite impressed by the mechanism that Azure has employed with Azure Managed Applications: [https://docs.microsoft.com/en-us/azure/managed- applications/...](https://docs.microsoft.com/en-us/azure/managed- applications/overview). Hashicorp recently announced their collaboration with Azure to bring forth managed consul offering using this: [https://www.hashicorp.com/blog/announcing-consul-service- on-...](https://www.hashicorp.com/blog/announcing-consul-service-on-azure/)

This in my opinion is the right way to solve the problem, i.e. provide the customers that want a managed offering the means to get a managed version directly from the entity most active behind the project, (e.g. Hashicorp) while getting the most from the cloud provider's infrastructure. I would be willing to trust Confluent or Hashicorp with operating/managing my Kafka or consul cluster but taking another dependency on their respective cloud offerings should be of concern.

I am quite surprised that its Azure that has shown creativity here while AWS and Google have limited themselves to offering marketplace AMIs/images at ridiculous markups.

<comment><USER3> > While AWS has ruffled a bunch of feathers with their Elasticsearch and Kafka > managed offerings

Also DynamoDB (vs MongoDB)

<comment><USER4> Instead of DynamoDB, perhaps you meant DocumentDB which is AWS's managed MongoDB compatible database service.

<comment><USER3> Whoops, right! Hard to keep track of all those AWS services

</comment></comment></comment></comment><comment><USER5> > Think Twice Before Open-Sourcing

I think it is a problem that it is very hard to monetize open source infrastructure libraries. In the past, you could try to do consulting or else offer paid hosting. Now with the cloud providers doing "zero management" hosting of open source libraries, both those avenues have been seriously curtailed.

Honestly, it seems like if you are the primary author of a popular open source library, your best bet is try to leverage that notoriety into getting hired by one of the cloud companies, and try to work on the open source library as a side project. Trying to use that open source library to support yourself any other way, seems destined for penury and misery.

<comment><USER6> These days, I wouldn't open source anything other than a small hobby project or utility library/app.

<comment><USER7> Well.. there is the AGPL.

</comment></comment></comment><comment><USER8> If you're doing anything ML related your best bet is to niche down and solve a very narrow problem for a specific industry / market segment. Building generic AI tooling sounds great but rarely solves anyones problems.

<comment><USER9> As an ML practitioner in a large ecommerce company, I totally agree. When I evaluate third party tools, 99% have no use at all for me. Things like Algolia or Rekognition or Clarifai.

Even Sagemaker and Fargate are mostly not useful to me as my company can easily operate its own k8s platform.

Open source tools for model building are great and a small team of engineers can write whatever odds & ends that aren't covered, or make scalable implementations.

Notebook platforms like Databricks are similarly useless. A notebook is not a frontend to a cluster and notebooks are universally poor development environments even for the very tasks they are advertised.

The main thing that matters for ML development is how quickly & easily you can put an arbitrary container or VM into a deployment environment. You're always going to need to rapidly change your container or VM, have common ancestors that get specialized to support GPU training or some web server application layer. Making the shortest possible distance between the definition of this environment and deployment of it is the whole game.

The type of tools I'm willing to pay for are specialized database engines, rapid data annotation tools, and specialized hardware environments.

I have no time for some "platform" tool for data provenance, notebook environments, model tracking, model-as-a-service APIs like Rekognition, or anything where I upload data and get back a model.

<comment><USER10> Could you care to elaborate further on specialized database engines and rapid data annotation tools? There are plenty of data annotation tools out there that seem to do the job so not sure what rapid would mean in this instance.

<comment><USER9> I mean things like vertica or kdb+ that have specialized performance properties for some use cases. Also to some minor extent managed cluster pipeline tooling like Spark. I don't mind paying for managed versions of these (not Databricks though). For annotation tools I mean things like Prodigy.

<comment><USER10> Thanks. Why the interest in managed cluster pipeline but not Databricks? They seem to be the big name in the game for Spark. Would some tooling around snapshotting, sequential AB testing, staged rollouts, ghost models be of use?

<comment><USER9> Databricks is a notebook frontend to cluster computing. Cluster computing is useful and I'm willing to pay for it as long as I have total & complete control of the environments and tooling used in the cluster workflow.

A notebook frontend however is less than useless, and is actively harmful by propagating poor notebook environments even further into aspects of computing where they cause harm and hurt reproducability and code factoring.

Given this, even if Databricks offered perfectly complete features for all aspects of cluster computing, it would still be inferior to just my own managed EC2 or EMR clusters or equivalent with other providers, where there is no "notebook as control plane" garbage.

But when you add to that the fact that Databricks lacks full features for me to totally own every customized detail of my cluster environment (e.g. how can I run plain Python multiprocessing tasks with zero Spark in Databricks? How can I bring my own custom defined GPU container with custom compiled Tensorflow?) it makes the deal even worse.

Databricks is just another Spark / Hadoop style snake oil seller banking on capturing a bunch of data science teams before people realize that it's a conceptually junk way to work.

As for the other tooling you mention, I'd almost always say to build it in house. For example, I don't know of a single A/B testing provider that actually uses frequentist sequential testing to correctly avoid early stopping bias. You actually need real statisticians hired in-house to solve these problems, and the engineering work to set up an extensible A/B test as a service internal tool is not bad. (I've built Bayesian A/B test frameworks with teams of 2-3 engineers in 3 different companies). It's just not cost effective to outsource it on the false hopes of not needing to hire your own in-house statistics experts. Just pony up the dough and hire them.

</comment></comment></comment></comment></comment></comment><comment><USER11> I think a lot of this depends on what your product or audience is. If you're a domain-expert in your niche then lots of folks would rather go with you since they'll have _you_ in their corner versus someone just trying to get it running half-assed. There's also the "you're not amazon so we're going with you" mentality amongst a lot of folks out there. Simply not being one of these giants can be a differentiator, especially for folks outside the US.

My anecdotal story is when GCP announced support for running chromium out-of- the-box. I thought that that would be the end of browserless.io. I held back my knee-jerk reaction to shutdown, and after a few months I believe we only lost a single customer. There's probably been a few others that we've lost along the way since the announcement, but it didn't seem to stifle our growth in any significant way.

In any case it really depends on what your product or service is. Just wanted to chime-in and say that the writing isn't necessarily on the wall if this happens to you. Stay the course and offer them the much-needed competition.

<comment><USER12> Support is where the money is at. Every major cloud vendor has garbage support and smaller, niche companies value their customers more, especially if you're not a huge account.

Also, If I'm using your service, and a competitor announces a similar service, unless they provide something that's much much cheaper, I will probably not switch.

</comment></comment><comment><USER13> Sounds like a lot of free marketing! If you're well positioned and a bigger company enters your space take it for what it is they're advertising to people in your space. Sure some will just default to one of them but most will shop around and because these guys are going to be dumping money into your space - you'll see more eyes on your product. Be on your A game it'll be good for you. Maybe they'll acquire you because you do it better.

</comment><comment><USER14> It misses a couple of big ones:

1\. Offer a great user experience. Many cloud providers are just pumping products out the door with little to no concern for UX.

2\. Have great personality. That could be through offering outstanding support, or through being the kind of company that people root for. (Honeycomb.io is a good example of this.)

<comment><USER15> Of the many people who hated Microsoft during their rise to power, one of the most coherent groups were people who were mad because MS put a competitor with an arguably better product out of business.

That is in fact how FUD got into the vernacular. They would make vague promises that you couldn't quite call outright lies about having a product coming in that market, and a year later they'd put out something tepid (thereby proving they were lying about their progress earlier), but with some bulk licensing deal.

By the time the MS product came out the competitor would already be experiencing reduced sales growth because people would play wait-and-see for the MS product.

There is nothing stopping any of these folks from pulling the same trick. Having a better product will not save you. A brilliant product might, but even that's not a given.

<comment><USER16> Who is gonna play wait-and-see in this day and age? We're not in the 90's where one had to wait for the product to be announced, then built, then shipped on a CD.

<comment><USER17> If a product has lots of integrations within your company, or if you store lots of data in it which would need to be migrated to another product (e.g. a database), or if lots of people in your company need to receive training for the product, then it might make sense to wait 6 months to see what product the big player is going to come out with, rather than choosing a smaller niche vendor.

</comment></comment></comment></comment><comment><USER18> I wonder if this is a driving force behind why Cognitect has kept Datomic closed source. I've seen people rally against Datomic more than once for that reason, but honestly, how can you open-source something truly unique and monetize without a large risk of cloud provider hijacking.

<comment><USER19> RICH HICKEY: To those who think that Datomic ought to be open source: We don't see a viable economic model there.

The source is an r/clojure flamewar which I'm not going to link.

</comment></comment><comment><AUTHOR> There are many more examples that I did not include. Like Redis (and AWS Elasticache), MongoDB, Cassandra, Akamai (and AWS Cloudfront), etc.

Any others?

<comment><USER20> Timescale/Influx, Neptune/multiple graphdbs, activeMQ/MQ, Kafka, Kubernetes, Hadoop/EMR, Athena/presto, Spark/Glue+Kinesis, Iron.io, even CloudWatch log insights eating other log platforms.

</comment></comment><comment><USER21> Uses want to pay for (managed) services, not software. The rise of AWS and cloud and downfall of on-prem licensing models over the last decade has proven this beyond any doubt.

It's completely a failure of vendors to keep trying to sell software instead of competing on the services. The ones who have rolled out their own offerings are generating plenty of revenue, but the overall breadth, flexibility and quality of is still rather poor. I don't understand why these vendors are moving slowly here. They're the best at running their own software. Writing some blog posts isn't going to fix anything.

</comment><comment><USER22> This is a good post from a16z -

[https://a16z.com/2019/10/04/commercializing-open- source/](https://a16z.com/2019/10/04/commercializing-open-source/)

"As software has eaten the world, open source is eating software.

Today, almost every major technology company, from Facebook to Google, is written on the backs of open source software. Increasingly, these companies are building their own open source projects as well – Airbnb, for example, has more than 30 open source projects, and Google more than 2000!

In the future, the virtuous cycle will continue. Technologically, AI, open source data, and block chain are some examples of emerging innovations. The next generation of business models may include ad-supported OSS, as when a large proprietary enterprise supports open source projects; data-driven revenue; and crypto tokens, which monetize blockchain.

I believe Open Source 3.0 will expand how we think of and define open source businesses. Open source will no longer be RedHat, Elastic, Databricks, and Cloudera; it will be – at least in part – Facebook, Airbnb, Google, and any other business that has open source as a key part of its stack. When we look at open source this way, then the renaissance underway may only be in its infancy. The market and possibilities for open source software are far greater than we have yet realized."

</comment><comment><USER23> [http://www.joelonsoftware.com/articles/fog0000000052.html](http://www.joelonsoftware.com/articles/fog0000000052.html) can help Win Against Big Cloud

</comment><comment><USER24> Wait, isn't it like any other market which already has long lasting players?

If you want no competition -- find a new market (and win it). Otherwise you have to be smarter and faster than existing players.

<comment><USER25> You can probably draw a parallel between the retail sector and the phenomenon discussed in the article. For example:

Decades ago (before Walmart, Target, etc), it was common to have many small specialized stores that did just 1 thing really well (ie. selling just books, selling just shoes, selling just office supplies). Over time, Walmart/Target came along and bundled all of those specialty stores into 1 giant store that sells everything, causing a lot of the small specialty stores to eventually fade away.

AWS/GCP/Azure is sort of like the "Walmart of B2B Internet Services" in that they are in direct competition with companies like MongoDB, Akamai, and the other examples from the article re: offering comparable managed services.

As a market matures, the market consolidates into a small number a big players. To survive, specialty shops need to do things that the big players won't or can't, which I think the article does a good job discussing.

</comment></comment><comment><USER26> The other option is to partner up with Big Cloud. They all offer marketplace programs that let customers install third-party software quickly and easily, and take care of the billing too (for a price, of course).

<comment><AUTHOR> I address this in the article. Unfortunately (for the startup) being in one of the Big Cloud partner programs does not prevent them from launching directly competitive products.

<comment><USER27> It probably only makes it easier for them as well since they can see what add ons/tools are the most consumed. Then they can use that data to figure out what features they should build next for their tools

</comment></comment></comment><comment><USER28> There will not be another Dropbox.

<comment><USER29> What does that mean?

</comment></comment><comment><USER30> Is there anyway to create your own AWS/Azure/GCP on your own server?

<comment><USER31> Azure has Azure Stack, you need a deep wallet [https://azure.microsoft.com/en- gb/overview/azure-stack/](https://azure.microsoft.com/en-gb/overview/azure- stack/)

<comment><USER30> Interesting, because I was seriously thinking of building a product where you get a good amount of features from these cloud providers and run it on your own servers... although obviously there's going to be some drawbacks, you may save a lot of money.

<comment><USER32> That's [https://www.openstack.org/](https://www.openstack.org/).

<comment><USER30> Oh. Haha. Looks like I learned something new today. Thanks for the info!

</comment></comment></comment></comment></comment><comment><USER33> This one is easy: patents

</comment><comment><USER34> Nice plug in the middle of middle of the article, exactly at the right spot:

> By the way, I write an article like this every month or so, covering lessons > learned from growing B2B software startups. Get an email update when the > next one is published

This is the closest I got to subscribing to a newsletter.

<comment><AUTHOR> > This is the closest I got to subscribing to a newsletter.

Almost got you, huh? :)

I've A/B tested various locations and the inline-embed is the best, by far. This is also why many news sites now include related stories in the middle of the article, not at the end.

<comment><USER35> Wish the rss/atom was better represented, rather than only existing in metadata on your site. I must be a dying breed, but I refuse to sign up for email newsletters. I refuse to hand over that much of my attention.

Edit: [https://www.gkogan.co/feed.xml](https://www.gkogan.co/feed.xml)

<comment><USER36> That's interesting. So RSS didn't stick because it didn't allow advertisers to harvest email addresses.

Which is stupid because you still can't reach to your audience if you just buy harvested addresses, so if it's just people who subscribed to your newsletter, you're just better off letting them subscribe to your RSS. Perhaps the quantifiability of newsletters vs RSS makes email win. If only RSS had embedded ways to count views and see what users looked at.

</comment></comment></comment></comment><comment><USER37> Terrible blog post, they completely forget to mention Mesos which owned the orchestration market before Docker Swarm and Kubernetes

<comment><USER18> Yikes, that's a little harsh considering the good discussion going on before and after your comment.

<comment><USER37> There is good discussion but there is a lot of hyperbole, how many companies can you name that have been killed by these hyperscale cloud providers?

Many seem to be doing well: [https://a16z.com/2019/10/04/commercializing-open- source/](https://a16z.com/2019/10/04/commercializing-open-source/)

Some just may not be worth their oversized valuations in the long run but made choices to be valued much larger than their actual worth.</comment></comment></comment>


Managing database schema changes without downtime - <AUTHOR> https://samsaffron.com/archive/2018/03/22/managing-db-schema-changes-without-downtime <comment><USER2> Having no-down-time when doing migrations is not an easy topic.

> These defer drops will happen at least 30 minutes after the particular > migration referenced ran (in the next migration cycle), giving us peace of > mind that the new application code is in place.

Pretty much that's what I've seen before. You do series of deployments + migration scripts.

Usually :

\- Migrate with backward-compatible modifications of the schema

\- Release application logic that takes advantage of both migrated / to-be- deprecated tables

\- Possible extra migration to sync the new / old tables.

\- Release application logic that stops using the to-be-deprecated tables.

\- Migrate with destructive modifications to remove the old table.

Usually that's a huge complicated process which might be replaced with one migration and a few minutes of downtime. Sadly some companies can't afford it, so they do such changes with weeks planing.

I usually vote for having some planned non-working-hours downtime.

<comment><USER3> > Having no-down-time when doing migrations is not an easy topic.

Depending on the nature of the migration and the type of data and the type of service and how coupled everything is, it's impossible. Especially when you are dealing with financial data and transactions that you can't afford to screw up even a single one.

> I usually vote for having some planned non-working-hours downtime.

Yep. No other way around it. You tell your clients weeks/months ahead of the planned downtime. They'll understand and migrate in the middle of the night over a holiday weekend.

But this is in regards to major structural migrations, not simple schema updates or changes.

<comment><USER4> Are you saying no downtime is impossible or merely expensive?

Erlang/OTP with relups is an example of a system that provides zero downtime online upgrade and rollback with zero downtime.

<comment><USER3> I'm talking about serious systematic migrations, not upgrades. In these instances, it is impossible to avoid downtime ( whether it be a few seconds, minutes or even hours ). It's one of the reasons why SLAs do not offer 100% uptimes.

<comment><USER5> Interested in a concrete example of where you see a migration being impossible without downtime; I'm not aware of Amazon or Google taking their APIs down for maintenance, which suggests that you can solve these problems with enough engineering spend.

> depending on... how coupled everything is

If you're just saying here that some systems aren't currently able to migrate in a hitless way, rather than claiming that it would never be possible for some systems, then I fully agree. Hitless migrations require a lot of work, and probably aren't worth the cost for many applications/systems.

<comment><USER6> Neither Amazon nor Google run off of an RDBMS.

Relational databases are awesome, but it's much harder to achieve 100% uptime compared to schemaless, distributed, replicated data stores. You easily can take down your system with one innocuous-looking DDL migration that works great in test but grinds the machine to a halt on a production dataset.

<comment><USER5> That's a good general point, but Youtube does use MySQL:

[https://www.mysql.com/customers/view/?id=750](https://www.mysql.com/customers/view/?id=750) [http://highscalability.com/youtube- architecture](http://highscalability.com/youtube-architecture)

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> At GitLab we do the following:

We have two migration directories: db/migrate and db/post_migrate. If a migration adds something (e.g. a table or a column) or migrates data that existing code can deal with (e.g. populating a new table) then it goes in db/migrate. If a migration removes or updates something that first requires a code deploy, it goes in db/post_migrate. We combine this with a variety of helpers in various places to allow for zero downtime upgrades (if you're using PostgreSQL). For example, to remove a column we take these steps:

1\. Deploy a new version of the code that ignores the column we will drop (this is a matter of adding `ignore_column :column_name` in the right class).

2\. Run a post-deployment migration that removes said column.

3\. In the next release we can remove the `ignore_column` line (we require that users upgrade at most one minor version for online upgrades).

The migrations in db/post_migrate are executed by default but you can opt-out by setting an environment variable. In case of GitLab.com this results in the following deployment procedure:

1\. Deploy code with this variable set (so we don't run the post-deployment migrations)

2\. Re-run `rake db:migrate` on a particular host without setting this environment variable.

For big data migrations we use Sidekiq to run them in the background. This removes the need for a deployment procedure taking hours, though it comes with some additional complexity.

More information about this can be found at the following places:

1\. [https://docs.gitlab.com/ee/update/README.html#upgrading- with...](https://docs.gitlab.com/ee/update/README.html#upgrading-without- downtime)

2\. [https://docs.gitlab.com/ee/development/what_requires_downtim...](https://docs.gitlab.com/ee/development/what_requires_downtime.html#doc- nav)

3\. [https://docs.gitlab.com/ee/development/background_migrations...](https://docs.gitlab.com/ee/development/background_migrations.html)

<comment><USER8> Its worth noting that there are some edge cases where this could lead to potential problems. Its enough of an edge case for many apps to ignore the possibility. Take your example with the addition of the fact that the field you're removing has a unique database constraint. With your deploy process this would look something like this.

1\. Run predeploy migration in db/migrate to remove the unique constraint 2\. Deploy new version of code that ignores the column 3\. Run post-deploy migration that removes column 4\. Remove the part of code that ignores the column

Failure to do step 1 would result in multiple rows being created with null values, which would cause errors for all but one (or zero) insert. The edge case, however, is a little more subtle. Between steps 1 and 2, there's a period where the database constraint doesn't exist, but the old code still expects the constraint. Validating uniqueness in the code can mitigate this, but doesn't ensure consistency.

<comment><USER7> This is not how we do it. Constraints, columns, etc are removed using a post- deployment migration. This means you can't end up with NULL values and the likes.

<comment><USER8> This helps ensure database consistency, but might not actually avoid errors. In this scenario, the period of time between the app code being deployed and the post-deploy migration running there could potentially be application level errors because the app is now ignoring the deleted field and the database expects unique values (or non-null, or whatever constraints you have).

You can solve these issues with some creative migration paths both at the app level and at the database level, but those changes aren't always trivial, and may not necessarily fit in the pre-deploy post-deploy migration strategy.

This may also not be an issue for you. You may be willing to accept a brief period of time where an error is unlikely, but technically possible. Personally, most of the time this is acceptable to me, but I always find it important to think about these scenarios in case something does happen.

</comment></comment></comment></comment><comment><USER9> Researcher/author of a tool [0,1] also attempting to tackle this problem here.

Unfortunately zero-downtime schema changes are even more complex than suggested here. Although the expand-contract method as described in the post is a good approach to tackling this problem, the mere act of altering a database table that is in active use is a dangerous one. I've already found that some trivial operations such as adding a new column to an existing table can block database clients from reading from that table through full table locks for the duration of the schema operation [2].

In many cases it's safer to create a new table, copy data over from the old table to the new table, and switch clients over. However this introduces a whole new set of problems: keeping data in sync between tables, "fixing" foreign key constraints, etc.

If there are others researching/building tooling for this problem, I'd love to hear from you.

[0] [http://github.com/quantumdb/quantumdb](http://github.com/quantumdb/quantumdb)

[1] [https://speakerdeck.com/michaeldejong/icse-17-zero- downtime-...](https://speakerdeck.com/michaeldejong/icse-17-zero-downtime-sql- database-schema-evolution-for-continuous-deployment-1)

[2] [http://blog.minicom.nl/blog/2015/04/03/revisiting- profiling-...](http://blog.minicom.nl/blog/2015/04/03/revisiting-profiling- ddl-statements-mysqls-return/)

<comment><USER10> Significantly altering an active table without downtime is a problem that will not, and should not, ever be solved by a library. It's too fraught with peril and special case fun for any competent devops person to leave it up to external code.

<comment><USER11> The work that goes into "external code" is higher quality than most companies can achieve. The cost of developing a similar tool may also be outside what the company can afford to invest.

If your business is online schema changes, then inventing it yourself makes sense. Otherwise you are likely throwing money away to create an inferior product.

</comment></comment></comment><comment><USER12> We're using FlywayDB [0] and many of the ideas in Martin Fowler's _Evolutionary DB_ article [1]. When database changes are breaking, we use a pre-deploy and post-deploy "pair" to create an intermediate DB state that both application versions will run against.

[0] [https://flywaydb.org/documentation/migrations](https://flywaydb.org/documentation/migrations)

[1] [https://www.martinfowler.com/articles/evodb.html](https://www.martinfowler.com/articles/evodb.html)

<comment><USER13> Liquibase [0] is an alternative to FlywayDB. Unfortunately, FlywayDB changed their feature scope for the free version.

[0] [https://www.liquibase.org/](https://www.liquibase.org/)

<comment><USER12> I haven't run into a feature that I need from either of the paid plans. What features were removed that you find compelling?

As an aside, Liquibase also effectively has a paid tier - it's just that it's marketed on a different web-site than the OSS version ([http://www.datical.com/liquibase/](http://www.datical.com/liquibase/)).

<comment><USER13> Dry-runs and rollbacks (Flyway's undos). Especially rollbacks are useful for development.

<comment><USER12> I don't remember roll-backs ever being in the OSS project either. We always do potentially destructive operations in two different migrations since you'll never get data back once you delete it. We tend to favor soft-deletes anyway which makes life a lot easier but can bloat your DB.

</comment></comment></comment></comment></comment><comment><USER14> There is also anchor modeling [1] with quite a few publications [2] and even an online modelling tool [3] to play around with. It is essentially a method that yields a highly normalized bitemporal database model so that every prior database state, schema and data, is a subset of the current database state.

I was personally not able to use it yet but I really like the idea behind it. It is probably not the ideal choice in general due to its append only nature ever increasing the consumed storage space and due to its high degree of normalization which may or may not have a negative impact on performance when implemented on top of a rational database depending on the nature of your queries.

But if you do not have to deal with excessive amounts of data, if you expect a lot of schema evolution, if you need traceability of all changes for auditing purposes or such, then using anchor modeling might be worth a shoot.

[1] [https://en.wikipedia.org/wiki/Anchor_modeling](https://en.wikipedia.org/wiki/Anchor_modeling)

[2] [http://www.anchormodeling.com/?page_id=360](http://www.anchormodeling.com/?page_id=360)

[3] [http://www.anchormodeling.com/modeler/latest/](http://www.anchormodeling.com/modeler/latest/)

</comment><comment><USER15> This looks like a helpful approach to a tricky topic! I'm curious how the post-deploy migrations work when you run all your migrations at once, from the beginning, e.g. in Circle CI or when onboarding a new developer?

Also, do you do anything to protect yourself against migrations written at time _t_0_ and then run much later at time _t_n_? I've seen a lot of problems there when migrations use application code (e.g. ActiveRecord models), and then that code changes. (My solution is to never call model code from migrations, but there are other ways.) This isn't really specific to your article I guess, but does your approach making managing that harder? Easier?

Does having that details table help at all when you have migrations on a long- lived branch that is merged after other migrations have been added? Or is the solution there just to rebase the branch and test before merging it in?

EDIT: I think this blog post by the Google SRE folks is great reading for people thinking about migrations and deployment:

[https://cloudplatform.googleblog.com/2017/03/reliable- releas...](https://cloudplatform.googleblog.com/2017/03/reliable-releases-and- rollbacks-CRE-life-lessons.html)

I've never been comfortable with rolling back migrations in production, but their plan changed my mind that it can be done safely. Is your approach compatible with theirs?

</comment><comment><USER16> This is cool but I've started reducing my need for migrations by just serializing most of the structured pieces of the record into a text string (json for example), and only have separate columns for things that need to be joined (usually an id column) or selected on/indexed. I find this approach prevents me from needing to do migrations nearly as often. If you find that you really do need to index on a new field, adding a column is the easiest kind of migration to do.

Of course sometimes you do still need to which is where strategies like this come in.

</comment><comment><USER5> >Migrate database to new schema... spin up new instance

Sadly this is more of a pain in Django, since it does not write default values to the database. To be able to safely run the migration first, one must manually rewrite the SQL for the migration. [1]

[1]: [http://pankrat.github.io/2015/django-migrations-without- down...](http://pankrat.github.io/2015/django-migrations-without-downtimes/)

</comment><comment><USER17> Sigh, wishing there was some magic sauce for this. But currently will have to sit through a 14 HOUR downtime while my team upgrades our SonarQube DB to 6.7.

</comment><comment><USER18> Just put your database schema in a VCS and get on with life: [http://www.liquibase.org/](http://www.liquibase.org/)

</comment><comment><USER19> is it really 0 downtime as the title suggest, or minimal downtime?

<comment><USER5> If you do it right, it's zero downtime (i.e. no DB locks held for long enough to cause timeouts to clients).

<comment><USER20> In most cases. However, some changes, such as adding the column and needing to manipulate data (populate nulls, transforms, etc.) could still cause locking.

This really comes down to knowing the boundaries of what changes could cause timeouts and working around them as best you can. However, some edge cases could cause downtime.

</comment></comment></comment><comment><USER21> I wonder how it is done in Dynamodb or Mongo.

</comment><comment><USER22> I'd love to see an article about letting your users fucking deal with it, because no one really needs this much uptime anymore.

<comment><USER6> This is probably not going to get a lot of love but it's really not a terrible answer for many, many apps - especially anything business related where you can assume that most users work single-country office hours.

This exact same compatibility problem exists at other boundaries of your app - in particular, the web/backend interface.</comment></comment>


How To Encrypt Your Gmail & Facebook Messages - <AUTHOR> http://www.makeuseof.com/tag/encrypt-gmail-facebook-messages/ <comment><USER2> Of course your autosaves will still be sent to gmail in plaintext while writing your original message.

</comment><comment><USER3> I am offended that people try to sell me AES as if that was a necessary and sufficient requirement for security. In this case, it's certainly not sufficient...

</comment><comment><USER4> What we really need is the ability to use pubkey systems like OpenPGP without hacking the script context of a page (a la FireGPG--- while good, it was fragile with respect to Gmail changes). I would love to have browsers bake in PGP support and for sites like Gmail and FB to start relying on the browser for encryption services.

<comment><USER5> It's best done at Google or at your email client. Anything elsewhere (e.g., at a browser) will suffer the same fate as FireGPG. I don't see Google ever doing it for Gmail -- normal people don't care about encrypting their emails, and Google will not want to risk losing the ability to show context-sensitive ads.

</comment></comment><comment><USER6> Ah yes, AES implemented in javascript and dropped in a page via bookmarklet. What could _possibly_ go wrong?

</comment><comment><USER5> Perfect. And the password will be shared over Google talk, I bet.</comment>


How Google Grew from 40 to 40,000 Employees - <AUTHOR> http://blog.betterworks.com/how-google-grew/

<comment><USER2> This article has almost nothing to do with its process on how it grew from 40 to 40,000 employees, I wonder if it was an editorial error. Instead, it is focused on Google processes of goal setting/measuring and improving:

 _OKR is an acronym for Objective – Key Result. Don Dodge, a developer advocate at Google, described the OKR process this way. "Every quarter every group at Google sets goals, called OKRs, for the next 90 days. Most big companies set annual goals like improving or growing something by x%, and then measure performance once a year. At Google a year is like a decade. Annual goals aren't good enough. Set quarterly goals, set them at impossible levels, and then figure out how to achieve them. Measure progress every quarter and reward outstanding achievement."_

Interesting stuff, but its not related to that incredible scaling of employees.</comment>


Ask HN: Is there a way to search HN articles, by their content, than by title - <AUTHOR>

HN Search, I believe, only shows the results, those that match the title-string. Is there a way that we can search stories submitted in Hacker News? <comment><USER2> Speaking purely as a user with no privileged status ...

To the best of my knowledge you can search the material that is hosted on Hacker News: link titles; "Ask HN"; comments; _etc._ However, if someone submits a link to an external site, you cannot search here for the content on that site. If someone submits a link to an external page that contains the string "HoogleFleeber", no HN search will find that article (unless the content is duplicated in a comment).

And no, HNSearch does _not_ only search within titles, it also searches comments and text within submissions. Very shortly it will index this page and you will be able to use it to search for "HoogleFleeber". I'm not sure why you think otherwise. Pretty much every search I try turns up text within comments.

I hope that's clear.

<comment><AUTHOR> Thanks for confirming! It would be great if we can search the content also, by duplicating the content only for search purposes.Let me add that feature request then.

</comment></comment><comment><USER3> you can use google by typing the following in the search box of Google:

Search string site:news.ycombinator.com

<comment><AUTHOR> but that also gives the results if the search string matches the title, not content!</comment></comment>