Rate/Review my startup - mixturtle - <AUTHOR> http://www.mixturtle.com Hey guys, I've just launched my new site (mixturtle.com). It's a music search engine and player. It uses Ajax for the interface so you can search and play music simulataneously. Playlists are created automatically and you can access it by right click mouse. (thank you jQuery!) Any comments appreciated.<p>Thanks Louis <comment><USER2> It's pretty good - one of the better music index services I've used. Others here have commented on a few small issues but overall it seems well executed.

However, is this really a viable business? I assume you intend it to be, based upon your description of it being a startup, but please correct me if I'm mistaken. Otherwise, I'm afraid I'm going to have to piss on your parade a little bit.

I have considered developing something similar to this in the past, but I've always stopped myself - simply because if it becomes any sort of success and is seen to be either (i) taking in revenues or (ii) encouraging others to develop similar services then the RIAA will give the slightest of gestures.. a wince of the lip perhaps.. to direct a battalion of lawyers to march upon your place of business and annihilate it with a bombardment of 4,000lb bombs stuffed with subpoenas and the internal organs from children and puppies.

Although many (including myself) argue that what you're doing is probably legal, it is not really open and shut - the RIAA would argue that you're encouraging and cooperating in the acts of copyright infringement. It's going to cost you a fortune to defend yourself.. and even if you manage to generate enough revenue to successfully defend yourself once, they will keep coming after you time and time again, from many different angles.

If the CoS can sue the IRS into submitting to its demands for tax exemption then the RIAA can shut down your little operation. The law can be cruel if you can't afford it.

If anybody else (with legal training) can enlighten me then I'd love to have my doubts assuaged.

<comment><USER3> You could have made the same case to the founders of Youtube. If everyone listens to arguments like that, then the RIAA has already won.

<comment><USER4> Luckily for the founders of YouTube they were bought by Google. And given the current fight with Viacom I don't know if I would ever want to be in a similar situation.

</comment></comment></comment><comment><USER5> While I like the sparse design (and badass logo), a huge problem is that I get to site and within the first ten seconds I don't know what it does (or even why I should care). I decide to figure out more by typing an artist and click 'music search' but now it's taking forever. If I was a random visitor, I'd be gone by now.

While I expect the load time after typing will be better as you work on scaling (and work out the bugs), I still think you'd be a lot better off with a little text explaining why I should even type something in and hit 'music search'. Will I get to play music? Will I get to download music? Will I find the cheapest prices for buying music? Who knows. Just my 2 cents.

</comment><comment><USER6> Damn that turtle is bad ass.

<comment><USER7> Seriously. Tipsy might have to run and hide to get a redesign again. <http://tipjoy.com/static/images/logo2.png>

<comment><USER8> At least Tipsy seems trustworthy. I'd give him my money voluntarily; Angry Mohawk Turtle would take it from me at gunpoint, then kill me anyway.

</comment></comment></comment><comment><USER9> I'm confused as to what I'm doing. I search for music, I add songs to my playlist, and then... what?

<comment><AUTHOR> I'm guessing you have javascript turned off? Otherwise the songs should just play instantly.

<comment><USER10> Why, oh why does such a site require Javascript?!

edit: I'm not against requiring Javascript for those parts of your website that absolutely, positively require it, but everything that can work without JS should gracefully degrade.

<comment><USER11> I didn't downmod, but I don't agree that everything that can work without JS should gracefully degrade. That seems like a lot of extra work to support a miniscule segment of fussy purists.

What am I not getting?

<comment><USER10> Well, JS is turing-complete and that's both a blessing and a curse. It's a blessing because you can do "anything", but it's a curse because unconstrained code is opaque. It's very hard to do stuff like extracting the semantics (what you meant to express when you wrote the code) out of JS and doing things like transformations without an unreasonable amount of work.

I think it's better to express as much as you can in a more "constrained" language like HTML or CSS because it's more like data than code, so it offers less opportunities to make a big mess of spaghetti code and having obscure interactions in the code. It's easier to reason about. HTML and CSS, being declarative, are much easier and cleaner to deal with than JS (it's more WYSIWYG).

So I guess what I'm saying is, coding in a style that avoids JS as much as possible is beneficial, and that style facilitates graceful degradation. Conversely, keeping an eye on graceful degradation will facilitate a better style.

<comment><USER11> Thanks for explaining. Now I'm sure I disagree. :)

I'm partly kidding. I might use that design style under some circumstances. I disagree that it's the right way to do things. There are many ways to do things. I think people want a "right" way because they want to feel like they've got stuff figured out. (This is especially common in our world because software is complex and there's a lot of uncertainty around how to do it well.)

As it happens, the app I'm currently working on is as far away from this design style as you can get. We do almost everything in JS, even things that could easily be done in HTML and CSS. Our way of carving things up relies heavily on expressing everything in a single language, and the Turing- completeness of said language is an advantage not a disadvantage. It's a solution I'm fond of because it neatly combines high-level abstraction at the source level with some stringent performance requirements in the browser. It will also be fun to watch the purists turn green when they see it.

Edit: we do almost everything in _generated_ JS. Might be relevant.

</comment></comment></comment></comment></comment></comment><comment><USER12> are you using the songza api? i tried a few searches, and its clear, while your search is good, theirs is much better.

great execution, but where's the differentiation with Songza, Seeqpod, Streamzy, et. al?

<comment><USER13> And don't forget this app: <http://listen.grooveshark.com/> It was posted here by someone (author I guess) and I ended up using it for some time because it has playlists. I now check it when I'm looking for something specific. But most of the time, I just use last.fm or Pandora.

Most of these apps just do a search on Youtube and play the audio portion of videos. Only prob is that audio quality is not so great but on my laptop speakers I can't even tell the difference so all is good.

I like MixTurtle. It's a nice app! Good job louislouis! Add a queue/playlist and I'll use it as a default music search app.

</comment></comment><comment><USER14> Why hide the search request with Javascript? Since the URL is always <http://mixturtle.com/>, I can't easily send a link to a search to a friend.

It's great instant gratification to play songs on the search results page, but I can't then access the source. You don't give anything back to the music sources, so if you they find about you (like when you get big), they'll fight you.

Is this legal? Great application, but I can't help but feel that the RIAA will crush you if they find you.

</comment><comment><USER15> Looks good. I'm confused about how playlists work though - I can add songs to it, but how do I play it or view it? A killer feature that songza is missing is the ability to create and share a playlist without logging in.

edit: Another problem: since you are getting the music from remote sources, they can stick in HTTP authentication headers. I got hit with a few of those. Not sure if there is a practical technical solution to this though.

The auto source-finding works way better than songza's trial-and-error approach.

<comment><AUTHOR> The playlist can be viewed with right-click mouse button. Just added that to the site text :)

<comment><USER3> Would be nice if this worked on macs with no right click.

<comment><USER16> control click will act as right click

</comment></comment></comment></comment><comment><USER17> Great design and UI. The logo is awesome. The auto complete works very well(except just for artists, eh, not for song titles?).

It's a lot like Songza, except I like yours better. The white background is much superior to red, also your fonts are easier to read.

It also works very fast and have had good luck with finding good songs.

I like the ability to create playlists.

Occasionally the search would slow down on me.

Great job.

EDIT: Oh wow, just figured out you can save playlists. Very cool.

<comment><USER17> Suggestion: Create a favicon.ico

</comment></comment><comment><USER18> You should autofocus your search bar onload.

</comment><comment><USER19> I like it-- just a few more bugs to work out. I did a search (for my wife) of "Tori Amos honey" and it took a solid minute to return anything.

Created an account and the playlist I saved there. Cool stuff.

Heh, nice touch with it saying "Welcome" in the search box when I login.

I would be a bit sad using your site a lot because I use right-click frequently to go back/open-in-new-tab, etc. But your service is cool enough that I'd live with it, surely.

Be careful with the music industry-- you may want to make it clearer where the source is coming from somehow so you don't land yourself in hot water.

The few songs I tried don't work on the iPhone, but I wouldn't have expected them to. If you made an iPhone app like this, I'd definitely buy it, but I imagine a lot are youtube/flash/etc.

</comment><comment><USER20> Search is a bit slow ATM, but selection seems good already. I didn't think I had to click 'Save Playlist' after clicking the pluses, maybe it would be better to auto-save the first one or create a default 'Untitled' and ask you to name it.

That was also totally not self-explanatory to a non-registered user, but it did keep the playlist selection after signing up which is good.

For the results, it would be cool to see the album and year, or if it's live a 'Live @ Foo Stadium' in the album spot and the year still shown.

Also wasn't 100% clear on how to play the track, and the 'Try next source' should look like a link, not like any other text.

Otherwise, pretty cool. Got it playin' in the background as I type :)

<comment><USER20> One more thing (minor bug report): I selected a song in a 2nd search but it added one from my first search instead when I saved the playlist (I clicked songs from 2 searches for my first playlist).

<comment><AUTHOR> Thanks for the comments and suggestions. I'll have to look into those bugs you found. I do admit though it's far from perfect atm and there were lots more features I wanted add before launching, but hacker news has taught me to just throw it out there and get a response, so my server is taking a pounding for it I type.

</comment></comment></comment><comment><USER21> A good implementation of an idea I've seen before.

The really impressive part of this is "mixturtle". I remember it and its easy to type. You've got time to improve the interface. The name is very clever: WIN on branding.

</comment><comment><USER22> dude you're smoking crack if you think you can run a biz by export your itunes library, parse the meta data, and stick it online with a google-like search interface. I say this while I'm listening to some Ozzy from your site (works great, but taking over right-mouse button is rude). This is cool as your personal web front-end to your library, but if it gets any traction (free music tends to get traction) you're in for a smack-down. Good luck , rock on :)

</comment><comment><USER23> First off, I probably wouldn't have tried the service without such a badass turtle on the frontpage. Good artwork.

1\. There's no indication of what the service does — "The Music Search Engine" is written too small and in a horrible font.

2\. After entering my favourite artist and waiting nearly 1 minute there's still nothing happening. MAKE IT FASTER.

3\. The font in the footer also looks horrible (Mac user).

4\. I _hate_ it when someone changes the default right-click menu.

</comment><comment><USER24> I just lost my music hard drive to the click of death, so this is really hitting the spot right now.

Two things that would have made my first 5 minutes better: 1\. Giant play button 2\. Giant playlist link, or playlist always visible in a column, or something.

Have you considered hooking into a service to pull more thorough album information so stuff could be organized a bit better than just a list of songs?

I'm really enjoying this. Thanks.

</comment><comment><USER25> If you're going to do something that is as jolting to the user as hijacking the right-click menu, you'd better get it right. As in, get it _perfect_.

When I right-click near the right edge of the browser window, the playlist pops up off-screen and hidden, creating scrollbars. Novices won't get this at all, esp. since it's not the interface people are used to.

</comment><comment><USER26> Good job - I like. Functionally streamlined, clean design and creative branding hook - I'll be checking back in the future.

</comment><comment><USER27> I'll be honest, my first reaction was to talk shit but it is actually pretty solid. The only thing I was a little confused of was how to start the playlist. I right clicked and then played it inside the playlist, but is it possible to play it in the main view? Maybe you could just have a big play button in the corner of the page.

</comment><comment><USER28> search works well. Found 3 tracks for Sounds Like Chicken - my reference Obscure band.

but major FAIL in usage terms.. * I start saving out a playlist - then realise there's nowhere to play it. * Normally I'd leave, but I figured I'd sign up. * Signup worked fine - and then I clicked on My Playlists * And I'd lost my playlist!

Love the design though.

</comment><comment><USER29> I like the idea.

When you click [+] it would make sense for it to change to a [-] in case I want to remove it (right-clicking is not obvious). The ability to pause a song and change the volume would also be nice.

You should add some kind of visual tutorial (but keep it simple) at the top of the page so new visitors know what to do.

</comment><comment><USER30> Sometimes I get annoyed when my cat is particularly vocal and won't respond to, the usually effective, shhhhhh. I can only imagine the frustration the people at the RIAA feel with so many smart people trying to figure out how to take them out of the picture. Including many musicians!

</comment><comment><USER31> Great visual design. Throw together a "getting started" or a "features" page with screen shots of the functionality that the website offers.

In my opinion this is something that Wordpress does especially well: <http://wordpress.com/features/>

</comment><comment><USER32> I really, really like the simplicity of the interface. The slow-typing/auto- complete was irritating until I realized why it was taking so long, and then I liked it for finding new music.

This is much better than Baidu's MP3 search. You should run this in China and make some serious cash.

</comment><comment><USER33> looks awesome. two questions: 1) which technologies was used? 2) how do you handle high loads?

<comment><AUTHOR> 1) php,mysql,js,flash 2) Not very well. My server is dying. I'm about to upgrade but I'll have to take the site down for the nameservers to propogate to the new ips. Anyone know how long this takes?

I considered using amazon for scaling but the article below this one says amazon is down, hehe.

<comment><USER8> I'm not an expert on this stuff but if you're just changing the IPs and not the actual NS records for the domain, the changes will be pretty much instantaneous, depending on how quickly your DNS service registers updates. I use DNS Made Easy and they usually take about ten or twenty minutes to accept a changed IP; once it goes into their records it's reflected everywhere immediately.

</comment></comment></comment><comment><USER10> The Login and Signup... "links" don't even feel like they're clickable because they're not underlined, the cursor changes to text editing instead of a hand, and there's no hover effect at all. Same for the X's to close the login and register popups.

</comment><comment><USER34> A bit slow, but steadily I find I can find what songs I want and build up those playlists. Feels good - <http://webpoet.wordpress.com/2008/07/21/mean- green/>

</comment><comment><USER35> I liked it. For my search it brought back some very obscure artists so I am not sure where you're getting your data. But I discovered some music I liked by some new artists so that was great. Memorable URL.

</comment><comment><USER36> This is great but with the RIAA suing 12 year olds and all, I'm pretty sure they'll shut you down for allowing me to listen to the beatles and metallica for free.

Awesome app though. It looks like a great starting point.

</comment><comment><USER37> It would be pretty cool to export finished playlists to Muxtape. I mean, you can create your own playlist sharing system, but might as well play along with the marginally bigger dogs.

</comment><comment><USER38> I tried it from explorer first it didn't work (search for avril lavigne), and it just showed the picture for loading. the same with firefox and then returned can't open file

am I doing something wrong?

</comment><comment><USER39> this is sick... mainly because I was able to find what I wanted right there...

wondering how long before someone else copies this idea and takes it mainstream... also the elephant in the room, DRM.

</comment><comment><USER40> Please change the blog so I can subscribe to it. I'd love to see how this develops over time. Plus, if I'm ever feeling timid, I can just go check out that turtle :)

</comment><comment><USER41> Slow enough to be useless here. A search took a few minutes :/

</comment><comment><USER18> Several times the song has started, but then whatever method is used to determine if its working caused it to stop and keep looking for another source.

</comment><comment><USER42> Now on cNet WebWare <http://news.cnet.com/8301-17939_109-9995938-2.html>

</comment><comment><USER43> I'm not sure what possessed you to design a music player UI without a Play/Pause button! Other than that, looks great.

</comment><comment><USER44> Needs controls to play/stop/pause, and a volume slider please!

I also hate having my right-click menu hijacked. Please re-think that...

</comment><comment><USER45> That turtle scares me. Otherwise, awesome.

<comment><USER36> <http://www.youtube.com/watch?v=CMNry4PE93Y>

<comment><USER45> <http://www.gaianation.net/org/animalia.html>

</comment></comment></comment><comment><USER46> Where are you grabbing the tunes from? Isn't RIAA going to go ballistic and shut off your supply?

</comment><comment><USER47> don't understand what the fuss is about, there are plenty of website like that around, in particular i use www.melodyshot.com, its the same concept, only difference is you can download and there a way way more results.

</comment><comment><USER48> Instant access to Barry Manilow; Mix Turtle Rox!

...i write the songs...i write the songs.

</comment><comment><USER18> having three different X's in the playlist view gets pretty confusing. perhaps use "clear" for the clear playlist feature and a trash can for the remove item feature.

</comment><comment><USER49> Need a visual for pausing and playing. Looks and works well.

</comment><comment><USER50> need audio controls. Pause, play, stop, next, back, etc. Ability to build a playlist and then just have it loop through your playlist, or shuffle through it.

</comment><comment><USER51> Needs a volume slider. Hate the turtle but thats just me.

</comment><comment><USER52> Amazing!! 5 stars!! Will definitely buy again :-)

</comment><comment><USER53> great design, so far it is still searching and its been like 3 minutes ... so I don't know what to say

</comment><comment><USER54> by far, the most badass turtle i've seen.

</comment><comment><USER55> still searching after 2 minutes...

</comment><comment><USER56> this is awesome! ^_^

</comment><comment><USER57> louislouis great start.

I'm some competition...lol

<http://www.myplaylist.biz/>

I would recommend Linode for hosting/scaling. you need controls, SEO advice, legal statement - have a read of this: [http://thenextweb.org/2008/01/30/the- music-wars-continue-war...](http://thenextweb.org/2008/01/30/the-music-wars- continue-warner-bros-records-vs-seeqpod/)

Good luck with the app, it looks great.

<comment><USER58> The site is pretty slick. Though, I have to admit that there are many sites that do pretty much what you have done. Nevertheless, I guess it's a huge market and there is room for many players. Question to agentbleu( I have used myplaylist.biz, interesting!) • How do u monetize such service- Google ads? • How do handle the legal issues with music companies. This scares the shit out of me. I was reading about Michael legal issues with music comp and how they were targeting his car, house and everything. • Though u don't store any music files, why would legal folks come after you</comment></comment>


Ask HN: No way to verify identity on Facebook - <AUTHOR> I'm locked, and I have no other way to verify my identity on Facebook. Details and screenshots here: https://medium.com/@pof/prisoner-of-facebook-521929a26a95
Were you in such situation sometime? Can someone help me what to do? I have no way to contact Facebook, I can get nowhere after login, can't fill out any form to post a request. I already send them my government-issued ID scan, now I can't send any other ID scan or any other document anymore. This is desperate situation lasting 4th month. <comment><USER2> I recently logged in to create some ads. But got locked out as I changed my country since last login. I dont remember the fake birthday I gave them nor do I still own the phone number I used.

I decided for myself to declare Facebook for finally dead for me. I removed my personal account long ago but now I also don't do business around Facebook anymore

</comment><comment><AUTHOR> Details and screenshots here: [https://medium.com/@pof/prisoner-of- facebook-521929a26a95](https://medium.com/@pof/prisoner-of- facebook-521929a26a95)

</comment><comment><USER3> If all else fails, just create a new account with a new email address and add all your details. Surely, your friends will re-add you, and if they don't, it was probably not meant to be.

<comment><AUTHOR> Unfortunately it's not about friends but about my website's fan page which contains hundreds of links to my website and images not showing anymore. Fans are confused, posting nasty comments :(

<comment><USER3> I hope they eventually respond. I think Facebook does take a few weeks to actually do anything. They aren't so good in the "customer service" department. They had banned a website of mine where I share links often, and I think it took almost a month for them to remove it from their ban list. The website is mostly family-friendly, and for the parts that its not, it certainly did not warrant a ban from Facebook.</comment></comment></comment>


T5: The Text-to-Text Transfer Transformer - <AUTHOR> https://ai.googleblog.com/2020/02/exploring-transfer-learning-with-t5.html <comment><USER2> The 'fill in the N blanks' results at the end are fascinating! N<64 are all pretty normal, but then for N=64 and N=512, it starts going on about the old 1930s cookbook it has and its grad school experiences! Wild. I think I would not be able to distinguish this from a selection of real Amazon reviews or similar informal text.

<comment><USER3> It reads like a typical blog recipe introduction.

<comment><USER4> Which makes sense, given the corpus they trained T5 on.

</comment></comment></comment><comment><USER5> Question: How did they obtain the Colossal Clean Crawled Corpus (C4) they mention in the article?

Options:

1\. "Mechanical Turk" style, a massive undertaking to manually clean up Common Crawl, perhaps using underpaid labor in third world countries (such as samasource.com does)

2\. By means of somehow getting the internet to do it for them with something like reCAPTCHA

3\. With the help of machine learning / traditional text processing

4\. Some other way

Anyone has any ideas? I'm intrigued. The paper [[https://arxiv.org/pdf/1910.10683.pdf](https://arxiv.org/pdf/1910.10683.pdf)] and the website [[https://www.tensorflow.org/datasets/catalog/c4](https://www.tensorflow.org/datasets/catalog/c4)] mention almost nothing, except for an option to switch off the cleaning & deduplication, which hints at option number 3.

<comment><USER6> In section 2.2 of the paper they describe the process they use: applying a series of heuristic rules to the text. (Also the dataset is 750Gb... )

<comment><USER5> Ah wow, thanks! Not sure how I missed that. For other interested parties, here's the key section:

> Unfortunately, the majority of [the text in Common Crawl] is not natural > language. Instead, it largely comprises gibberish or boiler-plate text like > menus, error messages, or duplicate text. Furthermore, a good deal of the > scraped text contains content that is unlikely to be helpful for any of the > tasks we consider (offensive language, placeholder text, source code, etc.). > To address these issues, we used the following heuristics for cleaning up > Common Crawl's web extracted text:

•We only retained lines that ended in a terminal punctuation mark (i.e. a period, exclamation mark, question mark, or end quotation mark).

•We removed any page that contained any word on the "List of Dirty, Naughty, Obscene or Otherwise Bad Words". [[https://github.com/LDNOOBW/List-of-Dirty- Naughty-Obscene-and...](https://github.com/LDNOOBW/List-of-Dirty-Naughty- Obscene-and-Otherwise-Bad-Words)]

•Many of the scraped pages contained warnings stating that Javascript should be enabled so we removed any line with the word Javascript.

•Some pages had placeholder "lorem ipsum" text; we removed any page where the phrase "lorem ipsum" appeared.

•Some pages inadvertently contained code. Since the curly bracket "{" appears in many programming languages (such as Javascript, widely used on the web) but not in natural text,we removed any pages that contained a curly bracket.

•To deduplicate the dataset, we discarded all but one of any three-sentence span occurring more than once in the dataset.

Additionally, since most of our downstream tasks are focused on English- language text, we used langdetect [[https://pypi.org/project/langdetect/](https://pypi.org/project/langdetect/)] to filter out any pages that were not classified as English with a probability of at least 0.99.

<comment><USER7> > We removed any page that contained any word on the "List of Dirty, Naughty, > Obscene or Otherwise Bad Words". [[https://github.com/LDNOOBW/List-of-Dirty- > Naughty-Obscene-and...](https://github.com/LDNOOBW/List-of-Dirty-Naughty- > Obscene-and...)]

Looking at that list, I wonder what the unintended consequences of a decision like this is. If you want to create something related to sentiment analysis, that swear words you discarded is a useful signal, not noise right? If you wanted to use the dataset somehow for your tour guide business in Austria, how does it handle the the village called Fucking? Does T5 understand the British colloquialism for cigarettes? Can ornithologists talk to it about penguins and eagles, but not about yellow-bellied tits and blue-footed boobies?

<comment><USER8> That made me think of something along the lines of "backdooring a dataset" by introducing some hard to find but easy to trigger failure modes or fingerprinting for any application built on top of it.

<comment><USER9> Sounds like an awesome idea, put some easter eggs in the common crawl to compromise the future of NLP.

</comment></comment></comment></comment></comment></comment><comment><USER10> _To put these results in perspective, the T5 team went head-to-head with the model in a pub trivia challenge and lost!_

Trivia fact recall and NLP seem like two quite different tasks even though both are required to do well in a quiz.

<comment><USER11> Agreed! The interesting thing is that basic unsupervised pre-training seems to produce a model which functions not only as a knowledge base but also an NLU system which can effectively query the knowledge base using natural text questions. This is exactly what our follow-up paper is on.

</comment></comment><comment><USER12> The trivia game ([https://t5-trivia.glitch.me/](https://t5-trivia.glitch.me/)) needs a little work.

> Q: How did Gus Grissom, Ed White and Roger B. Chaffee die in 1967?

> You: "Apollo 1" WRONG

> T5: "They were killed when their Apollo 1 spacecraft exploded" WRONG

> Correct answer: burned to death

> Q: Which Alpine peak is known in Italy as Monte Cervino?

> You: "Monte Cervino" CORRECT

I wonder how many of the problems with this game could be fixed by applying T5 itself to the answer grading.

<comment><USER11> Yes, unfortunately we have to rely on the very brittle "exact match" method of evaluating whether an answer is correct. FWIW and perhaps surprisingly, this is the primary way question-answering systems are evaluated in common benchmarks. I totally agree that fine-tuning T5 for answer grading would be super interesting!

<comment><USER13> I'm sorry for being blunt, but is it possible that the `very brittle "exact match" method of evaluating whether an answer is correct` means value equality? Is `==` the secret sauce?

<comment><USER11> It's slightly more than that -- it also involves lowercasing and removing articles before testing for string equality.

</comment></comment></comment></comment><comment><USER14> Anyone know what's new in the blogpost? T5 has been out for a few months now.

<comment><USER11> The blogpost has a summary of our paper from October (a bit late, sorry!) but also has some (fun?) new results on closed-book question answering and fill- in-the-blank text generation.

</comment></comment><comment><USER15> No mention of MASS by Microsoft? It was afaik one of the first pretraining schemes for a full transformer outside of XLM.

Imho a bit unfortunate, as is calling the decoder or the encoder of a transformer "a transformer", as it has happened with GPT and BERT, which now forces people to use "full transformer" or using phrases like the title of the blog post.

<comment><USER11> We include MASS in our empirical survey (see e.g. section 3.3.2 of our paper, [https://arxiv.org/pdf/1910.10683.pdf](https://arxiv.org/pdf/1910.10683.pdf)). FWIW, people were pre-training Transformers before MASS, e.g. "Improving Language Understanding by Generative Pre-Training" by Radford et al. from 2018. Even further back, "Semi-Supervised Sequence Learning" by Dai et al. describe pre-training an RNN encoder-decoder model for subsequent transfer.

<comment><USER15> But Radford is just pretraining the decoder and qualitatively different from a seq2seq approach such as MASS. If we just look at the original paper from Vaswani, than "pretraining a transformer" imho should always only have meant pretraing the encoder and decoder. Obviously that ship has sailed.

</comment></comment></comment><comment><USER16> Wonder how this would compare with Watson at playing Jeopardy...

<comment><USER17> I would assume most QA (question answering) models blow Watson out of the water. A lot has been done since then. See: [https://aclweb.org/aclwiki/Question_Answering_(State_of_the_...](https://aclweb.org/aclwiki/Question_Answering_\(State_of_the_art\))

<comment><USER18> (I've done work in QA and have played at building Jeopardy style QA models)

Watson (Jeopardy Watson, not the IBM branding exercise Watson is now) has much weaker text understanding models, but has much much better optimisations for the incremental style of data release that you see in Jeopardy (ie, you get more and more data the longer you listen). IBM did a lot of work optimising _when_ to answer as well as trying to get the correct answer.

The closest analogy that is regularly studied in modern QA research is "Quizbowl"-style datasets, but these tend to be much smaller than the SQUAD datasets that most modern neural network QA systems are built against.

</comment></comment></comment><comment><USER19> How would this perform on the reading comprehension part of the SAT?

</comment><comment><USER20> The example figure has a weird entry for the summary task. The input is:

"summarize: state authorities dispatched emergency crews tuesday to survey the damage after an onslaught of severe weather in mississippi..."

And the output is:

"six people hospitalized after a storm in attala county."

That's quite a bad summary, no mention of "six" people in the original text, no mention of hospitalization. And "attala" county is too specific, a precision not present in the original text.

If that's the result of their model, that's not good. If it's coming from the training set, it's an even bigger problem. I guess it's the result of the model, because some issues can be explained by correlations ("emergency" correlates with "hospital", "mississipi" correlates with "attala").

I'm wondering why they chose this example for the flagship figure of their paper.

<comment><USER21> The "..." at the end of the phrase is the give away that they couldn't fit the whole article in the picture. Checkout the complete paper.

<comment><USER20> I missed that ellipsis cue, thanks for pointing it out. The complete excerpt is not in the complete paper though, but it's probably in their released data.

</comment></comment></comment><comment><USER22> If you want to train or run T5 for pure text generation (GPT-2-style), Nax developed a Colab notebook for that: [https://twitter.com/NaxAlpha/status/1224912629967310848](https://twitter.com/NaxAlpha/status/1224912629967310848) [https://colab.research.google.com/drive/1-ROO7L09EupLFLQM- TW...](https://colab.research.google.com/drive/1-ROO7L09EupLFLQM- TWgDHa5-FIOdLLh)

</comment><comment><USER23> Link to the paper: [https://arxiv.org/abs/1910.10683](https://arxiv.org/abs/1910.10683)

</comment><comment><USER24> Listen to the paper here you can [https://youtu.be/gyBdnNY1WPI](https://youtu.be/gyBdnNY1WPI)

</comment><comment><USER25> Now I'm curious what it'd give as output for the missing-tokens task if you specialized it on understanding SVG vector image data...

<comment><USER26> Interesting thought! I think you'd have to provide more than the image XML though. The locality of XML elements in text form doesn't necessarily correspond with their locality in rendered image form, that would be tricky as there wouldn't be a lot of "context" to go off of.

</comment></comment><comment><USER27> would pre-training on non-English text (using a joint dictionary) improve translation performance?

I'm not sure if the information on [http://nlpprogress.com/english/machine_translation.html](http://nlpprogress.com/english/machine_translation.html) is accurate, but it appears that the top translation results rely on backtranslation, boosting and other data augmentation techniques with a _vanilla_ transformer model. It would be interesting to see the Bleu scores for T5 that's more optimized for translation specifically.

<comment><USER4> It'd be really interesting to see if T5 could be made to perform a reading comprehension or summarization task where the source article is in a different language from the question and answer. Seems like a potentially interesting application for a model as flexible as this one.

</comment></comment><comment><USER28> In case anyone from the team is watching, the colab link at the bottom is broken.

<comment><USER11> Thanks, fixed!

</comment></comment><comment><USER29> Isn't that the name of Microsoft's code generation templating language?

<comment><USER30> That's T4. The naming is pretty unfortunate.

<comment><USER31> Not to be confused with the m4 language.

</comment></comment></comment><comment><USER32> Of course every equestrian (or parent of one) would know that a sentence like "the course is jumping well" is totally legit.

</comment><comment><USER33> > Text-To-Text Transfer Transformer (T5)

> Colossal Clean Crawled Corpus (C4)

pun detector at 3.6 punits. not great, not terrible.

</comment><comment><USER34> This is epic...

> Q: What is the opposite of an acid?

> You: alkaline

> T5: Alkali

> Correct answer: a Base

:-)

</comment><comment><USER35> Did you consider incorporating convolution into the model ala the evolved transformer?

</comment><comment><USER36> > the full 11 billion parameter model achieves the exact text of the answer > 50%[ to 30% of the time]

If you need to tweak 11-billion parameters to get a particular result, I don't see how you can call whatever is being called a model, more like a component of a model.

</comment><comment><USER37> Social-media political bots about to get harder to detect.

</comment><comment><USER35> Did you consider incorporating convolution a la 'the evolved transformer'?

</comment><comment><USER38> Ironically this can be used to create search engine spam!

</comment><comment><USER39> Will it be able to learn the universal Turing machine? We could "train" a compiler & runtime into existence. Probably too much of a correctness constraint (since the output has to be the exact result of computing the encoded program with the encoded machine).

</comment><comment><USER40> > _" With T5, we propose reframing all NLP tasks into a unified text-to-text- > format where the input and output are always text strings..."_

So exactly like the "unix pipe" philosophy invented 47 years ago?

I guess ideas are cyclical...</comment>


The Footage of SpaceX's First Falcon 9 Reusable Flight Test is Gorgeous - <AUTHOR> http://io9.com/the-footage-of-spacexs-first-falcon-9-reusable-flight-t-1565072553

<comment><AUTHOR> Alternatively, the video alone is available from [https://www.youtube.com/watch?v=0UjWqQPWmsY](https://www.youtube.com/watch?v=0UjWqQPWmsY)</comment>


The lack of namespaces on crates.io is a feature - <AUTHOR> https://samsieber.tech/posts/2020/09/registry-structure-influence/ <comment><USER2> For those not familiar with Rust or the debate around this subject, "namespace" here is not like a C++ namespace (Rust's modules are analogous to C++'s namespaces). "namespace" here is about the crates.io package registry, not the Rust language.

Let's say you have a crate (Rust's terminology for a package) named "foo". Inside "foo" you have a few subcrates (named "foo_bar", "foo_baz", "foo_qux"). There are a number of situations where a crate will have subcrates. Sometimes these subcrates are intended to be used publicly (e.g., you want people to be able to use just the "foo_bar" subcrate if they don't need the whole "foo" crate) Sometimes these subcrates aren't intended to be used publicly (e.g., Cargo forces you to put your proc macro in a separate crate, but that's an implementation detail of "foo" and isn't something other people should use directly).

So now you have "foo" on crates.io, as well as a bunch of "foo_*" subcrates on crates.io. Currently there is nothing stopping some random developer from publishing their own "foo_haha" crate. This new crate isn't related to your "foo" crates and might even be squatting on a name you would have liked to use for a subcrate.

Or multiple people might want to create different crates for similar things. e.g., there are multiple regular expression crates. But only one of these crates got the "regex" name. Everyone else has to use a different name, and sometimes people use creative (unintuitive) crate names.

So for various reasons, some people want namespacing on crates.io that would allow someone to reserve an entire namespace. This would allow you to prevent others from using a name that might be confusingly similar to yours. It also allows you to use conflicting crate names if multiple people want to publish different crates with the same name.

TL;DR some people want something like npm's scopes for crates.io. And other people don't want it. This has led to much debate and arguing and whatnot.

It's funny, though, because the team that owns crates.io almost never weighs in on the discussion, and on the rare occasion that one of the team members does say something they always do it in a personal capacity and not in a way that represents the team. This has created its own set of frustrations.

<comment><USER3> is there a TL;DR for why some people don't want namespaces for crates? Is it just because NPM does and javascript is bad or is there something else I'm missing? I couldn't imagine github or npm working well without them.

<comment><USER4> > Is it just because NPM does and javascript is bad

Not at all! In fact, npm's implementation is why some are pro, but also why some say that it's not worth it; see [https://news.ycombinator.com/item?id=24444852](https://news.ycombinator.com/item?id=24444852) for some npm specific sentiment.

(Incidentally, npm added scoped packages in 2015, _after_ these decisions were made for crates.io. However, crates.io is still smaller than npm was then...)

There isn't really a TL;DR because this space is complex, and there's a lot of details, and they matter, and different people have different reasons for not wanting them. I think it's good that github has namespaces, but that doesn't mean I think that Cargo should have them, because they're fundamentally different services.

The short reason we gave back in 2014 was:

> Because namespaces are strictly more complicated in a number of ways,and > because they can be added compatibly in the future should they become > necessary, we're going to stick with a single shared namespace.

from [https://internals.rust-lang.org/t/crates-io-package- policies...](https://internals.rust-lang.org/t/crates-io-package- policies/1041) which is linked in the post.

<comment><USER5> But unlike traditional namespace, that you automatically got alias to things inside the same namespace.

The npm's namespace is basically just a preserved prefix, mention scoped package inside another scoped package still requires you to write full name (scope + package) or it didn't work.

I don't really see a reason that you can't implement it in a flat name package manager? Something like "you can't publish a package named as 'USERNAME_private_WHATEVER' unless you are USERNAME"

<comment><USER4> Nobody is saying that it's impossible to implement. However, someone would have to write that up as a plan, including all the details, and put it through the RFC process, and get folks to agree that that plan is the one that should be implemented, rather than other possible plans.

</comment></comment></comment></comment></comment><comment><USER6> If there was a sports-like betting site for future decisions that major open source projects are going to make, I would put a thousand dollars on "Cargo/Crates will implement namespaces."

The developers have convinced themselves that they're right on this, having, I suppose, not learned from the hundreds of package managers that have come before them. They're wrong; full stop, no qualifications, no asterisk, no footnote, they are totally wrong on this and it is inevitable that their opinion will change.

But, this is the nature of open source (and even startups). New projects start under the (oftentimes correct) belief that they can do something better, which experiences linear extrapolation into believing everything you do is better through virtue of being unlike what everyone else is doing. We see the end- state of Maven, NPM, etc; we don't see the war that those projects went through to reach this state. History is elided, forgotten, then repeated.

<comment><USER7> _> The developers have convinced themselves that they're right on this_

This is a complete misrepresentation of the issue. Adding namespaces to crates.io is a social problem, not a technical one, because adding them means you now must do the work of arbitrating disputes over an identity layer, which is a job unfit for part-time volunteers, which is all that crates.io has. The only alternative to arbitrating your own identity layer is to tie yourself to some other preexisting identity layer (e.g. GitHub, DNS), which raises questions about the notion of project ownership, the potential transfer of ownership, the immutability of the package registry, and all the while just pushes the "race to register" to a different sphere.

If crates.io had full-time employees rather than only volunteers, I'd be all for paying someone to handle identity problems in exchange for the existence of namespacing. But who's going to pay for it?

<comment><USER8> > The only alternative to arbitrating your own identity layer is to tie > yourself to some other preexisting identity layer (e.g. GitHub, DNS)

Devolving identity down to DNS has been a really good decision for Go. I'm not sure why everyone doesn't do it. It's like XML namespaces, but actually useful.

<comment><USER9> > Devolving identity down to DNS has been a really good decision for Go

If it works for go, the because go is not old enough. Domain registrations lapse quickly and then someone else can buy them. That's very close to the worst that can happen for trust in packages.

<comment><USER8> If you lose your domain, spreading bad software is the least of your concerns. They can reset all email passwords and access every service you've ever used.

<comment><USER10> > _If you lose your domain, spreading bad software is the least of your > concerns._

But if _you_ lose your domain spreading bad software is the top of _my_ concerns.

<comment><USER8> Either the package manager site allows email resets and the same issue applies, or it doesn't and you can be locked out forever by forgetting a password. Both failure modes suck.

<comment><USER10> You're still assuming the domain owner's participation.

How many domains lapse while the owner is active and responsive in the community?

<comment><USER8> You just agreed with my original point that outsourcing identity to DNS/TLS is a good practice!

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER11> You really should look to other ecosystems and see what lessons they've learned. In java, packages are normally "namespaced" by the author's reverse domain name, like `org.lwjgl/lwjgl`.

Since clojure uses maven as well, the same applies, but clojure tools like leiningen decided to create a shortcut: if the group and artifact name are the same, like `iglu/iglu`, they can be collapsed into one name: `iglu`

Well, that just encouraged everyone to choose collapsible names. In retrospect, this didn't buy us much. Who cares about saving a few characters of typing? Most now seem to agree it wasn't a good idea.

When the "collapsed" name falls out of maintenance, the forks will all seem somehow less "official", even if they are much higher quality. Forks are inevitable; why would you want to discourage them?

I finally decided to start using the reverse of my personal domain for my future libraries. The java folks were right all along.

<comment><USER4> We did look and learn; a lot of crates.io was informed by several of us having experience with CPAN, RubyGems, and npm. Both the good and the bad.

And also by the experience of going through GitHub hosting a RubyGems server and all the fallout that happened there.

<comment><USER12> I have less experience with CPAN and RubyGems but npm's namespacing system has two very serious problems:

1\. It was introduced very late, meaning the community had already formed patterns of contribution around a flawed flat system. This is a problem of the flat system, not of the namespaced one.

2\. It is still to this day entirely optional (for understandable backward compat. reasons). This gives namespaceless packages a misplaced position of authority over namespaced ones, which erodes the value of namespacing.

These are tough problems to get around if you start with a flat structure, but they really just outline the urgency of switching to namespaces for a relatively young project.

<comment><USER4> I agree with a lot of this perspective. It's also directly relevant to our situation, because we are basically in exactly that place now, and dealing with these problems is something that proponents of adding namespaces need to navigate.

<comment><USER12> PHP and it's ecosystem has a lot of problems, but I think Composer/Packagist is as surprisingly exemplary example of how to go about structuring package management.

<comment><USER13> Except for the decision to not tackle solutions for native extensions.

</comment></comment></comment></comment></comment></comment><comment><USER7> This article is poorly titled; it's about the lack of namespaces on crates.io. Rust does have namespaces. Cargo is capable of supporting registries that use namespaces. Using Rust doesn't even require one to use Cargo, and using Cargo doesn't require one to use crates.io.

(For the record, I do think that namespaces on crates.io would be a marginal improvement, but the benefits are often overstated and it would add organizational costs that the crates.io maintainers can't currently bear. The amount of ire over this topic is disproportionate to its impact.)

<comment><USER14> Ok, we'll use your phrasing above. Thanks!

</comment></comment><comment><USER12> > _This is a strike against any namespace system that allows namespace > ownership to unexpectedly change. Discontinuous identity has a couple of > issues._

Hard agree but this has nothing to do with namespaces. This is equally applicable to names in a flat registry. I don't see the point of bringing this up in this article.

> _there are also real benefits. [...] discourages forks_

What. How? Why?

I guess there's possibly some valid argument for disliking forks (though it's certainly not put forward in this article), but discouraging them via package registry structure is... delusional.

Forks are a reality of software and they neither happen as a result of registry structures, nor can the be discouraged by their designs. They happen for entirely external, human reasons, and a well-designed registry structure (i.e. a non-flat one) will be set up to be _resilient_ to forking.

<comment><USER15> Aspects of Registry Structure -

Identity

Continuity

Stability

Squatting

None of these are features, which are incompatible with namespaces. I can't find a compelling reason that Crate works this way in this entire article. The article reads like a list of "why Crate is poorly implemented". Of course, it works when the community is rather young and small. Give it time.

</comment></comment><comment><USER16> I remember when this came up because of the following user:

[https://crates.io/users/swmon](https://crates.io/users/swmon)

<comment><USER17> Interestingly, you can't name squat on GitHub. I just asked them for the guy squatting my first name and they gave it to me. Ah, the power of non- community-run product. You can do the right thing without having to worry about the slippery slope.

<comment><USER18> > I just asked them for the guy squatting my first name and they gave it to > me.

Your... first name? So "rene" (if I was to assume a few things about your username)?

<comment><USER17> Haha, that's not my real first name. You know, like how Ronaldinho's actual first name is Ronaldo? Like that. The actual name.

<comment><USER18> Sure, and that's why I said I was assuming, but my (poorly communicated) intent was to question how unique your first name is, and how someone is squatting on it if it's a real account and maybe they have that name too?

I mean, it's probably not a big deal in this case. But if I had a github account that someone wanted and github just gave out my (personal?) info, I might feel a bit betrayed by them. I know, I shouldn't give them any info I really want private, but that doesn't mean I can't expect them to act responsibly with what I have given them. I just didn't want to state all that up front, because it assumes a lot about what happened when there wasn't a lot of detail provided.

It is nice when people can just make simple stuff happen though, I agree. It's just a hard line to walk, because you allow that and then you get stuff like the recent Twitter hack. It's hard for us to all have nice things and nice people that can help us because there really are a bunch of people out there to get you (or someone in a similar situation, at least). :/

<comment><USER17> They don't give you access to the account. They tombstone the old one and assign its handle to yours. So you get the other GitHub handle but your account retains its repos, its keys, etc and doesn't get mixed in with the other account.

Of course, if they just let you login to the other one that would be crazy business. You'd know the other guy's email for starters. But they don't.

It's all perfectly kosher. You just get the namespace.

<comment><USER18> Ah, they gave the account name. When you said "asked them for the guy" and "they just gave it to me", I was interpreting it as the guy's contact info and them just giving it to you, which is what was raising red flags for me. Yeah, it's much less problematic if they just let you use the name of a discontinued account (as long as the github single-sign-on stuff keys off an ID and not a name, which I assume it does).

<comment><USER17> Yeah sorry about that. Though it's funny. You can just scrape folks' repos to get their email anyway. They all include it in commits. Emails are better made public than kept private imho.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER19> It's actually terrible, justs look at NPM and RubyGems.

Instead of just coming up with a good name for your project, you have to come up with a unique one even though the project with that name isn't even active. And since most names are taken, you have to come up with a clever one for no real reason. Or go down the route of naming strats you see on npm/gems: better-lib, lib2, lib2-better, lib3, better-lib3, etc.

It really does nobody good except for the person who was able to clutch the original name, and that's a weird incentive structure. Subreddits have this same problem where you're instantly gimped when named anything other than r/bitcoin, r/politics, r/news, r/atlanta, etc.

Instead, there should be no preciousness to names nor dictionary words. That's the correct incentive structure: none.

People keep linking [https://crates.io/users/swmon](https://crates.io/users/swmon) and it probably seems like an easy fix to just revoke those names. But swmon isn't the problem, the system is. It's no bigger problem when swmon does it overtly vs thousands of people doing it incidentally when they register a package they don't do anything with.

The problem isn't to calibrate a system that can detect swmon but build a system where you don't care what swmon does.

What you want is something like this: [https://package.elm- lang.org/](https://package.elm-lang.org/)

Watching Crates get this wrong was like watching Swift not implement qualified imports.

</comment><comment><USER20> We really need a colorful term for the practice of 'splaining to people how a frustrating part of your code is not only not a bug but you are either doing it (to them) on purpose, or pretending to have done so in order to save face.

Bugsplaining?

<comment><USER21> Buglighting. (Bug + gaslighting).

"You don't actually have that problem. The system doing that is expressly a feature for you."

<comment><USER20> Hmmm. I admit yours is easier to create an icon for.

Not sure about recognition, or the vaguely defined requirement to avoid Poe's Law.

</comment></comment></comment><comment><USER21> The lack of namespaces in the crates registry (combined with allowing squatting) is easily one of the worse aspects of Rust.

<comment><USER22> Please elaborate, why?

<comment><USER21> Well, what's wrong with namespacing, exactly? Github, java, etc, show us that namespaces are perfectly fine. Not perfect, but fine.

The rest of Rust is extremely pleasant to work with; a lot of thought has been put into ergonomics and I love it as a result.

But with crates.io it feels like the opposite. I have to deal with name- squatting and a much more difficult naming process for crates as pretty much every short, meaningful name in English is taken at this point. For what gains? Less forks, less fracturing -in theory-?

I feel like a lot of the arguments for no namespaces are strawmans or make big stretches. For example, figuring out which fork of a project to use is really not a problem. And a lack of namespaces does not fix that anyways, because it's not a code problem... Importing two crates with the same name would be fairly rare, and rust easily solves that with `use crate::... as ...`. Etc.

Anyway, this discussion has been trod to death. There's no point having it, as I'll just be told why I'm wrong and why namespaces are just -impossible-.

<comment><USER7> _> why namespaces are just -impossible-_

As mentioned elsewhere in here, this is a misrepresentation of the issue. The problem is that crates.io is a free, volunteer-run project with zero full-time employees who could be tasked with the drudgery of intervening in naming disputes or managing an identity layer. This is unlike GitHub and unlike "Java" (by which you probably mean Maven Central, which is operated by Sonatype). Solve the funding issue first, and then you can start solving the rest.

<comment><USER21> "could be tasked with the drudgery of intervening in naming disputes or managing an identity layer"

What do these have to do with the issue of namespaces?

Having namespaces would lessen naming disputes since users would be able to name their crate whatever. Any system will have disputes, so I'm not sure what the argument is here.

I understand why crates uses github for identity management, but it's not ideal that people are locked into using one specific git platform. Github is already an unavoidable entity, much like facebook, but this is a bit of a harder issue to solve without a lot more resources.

<comment><USER7> Once you introduce namespaces, now you have naming disputes about the namespaces themselves.

<comment><USER23> So? It's still less disputes. Nobody should be taking namespaces such as "http" for example. The namespaces represent who people are, not what the package does.

</comment></comment></comment></comment></comment></comment></comment><comment><USER24> > So what's a bad actor? I consider someone who squats a bunch of crates to > make or point or prevent their names from being used to be a bad actor.

In my experience, the thorny problem with namespaces isn't _bad_ actors because you can fix that with content moderation. Yes, that takes time and effort which can be scarce in an open-source community, but it's _doable_.

No, the thorny problem is good actors with bad execution: people who publish a package with a nice name that does what it says it does, more or less, but does it _poorly_. It doesn't cover all the edges case or it is poorly optimized or it has limited features or it has some fatal design flaw in its architecture... Maybe it was fine at some point but just hasn't kept up with the times.

So what do you do if a package like that grabs the name "json" or "http" or something? You don't want to kick packages off just for not being _great_ , but you also don't want it to seem like the _de facto_ package for a task in your language. I do a lot of Haskell, and it's not the best developer experience when you have to tell people "don't use json, use aeson instead".

Namespaces would solve this problem. You could have a "blessed" namespace (like rust/) and, when functionality becomes important enough that the quality of the "default" package matters use the namespace to provide that package (rust/json, rust/http... etc). You don't have to kick off the existing package (even if it's squatting a "nice" namespace like json/json) but you also don't get into the point where packages with nice names _look_ fine but are actually flawed and a bad choice for real work.

</comment><comment><USER25> This is why I like the Go approach: just use an existing global namespacing system and delegate to it all ownership disputes etc: DNS + actual web servers serving traffic (not necessarily just got repos, since the "vanity imports" offer an indirection based in html meta tags)

<comment><USER4> Yes, there are benefits to that approach. We rejected it because we want builds to be reproducible, and not to have that property depend on external entities.

<comment><USER25> That's orthogonal with the naming scheme. In fact the Go team eventually implemented a way to decouple the storage of a copy of the package from the name of the package, namely the goproxy. How they got there was admittedly a bit clumsy, but it proves that it's possible

<comment><USER4> Sort of; you can still delete github repos and the proxy doesn't keep a copy forever, right?

<comment><USER25> That's an implementarion choice of the proxy. You can run a private proxy that inplementa whatever policy you want.

If crates wants a policy that stores crates forever then just store crates forever. What I'm talking about just affects how new crates and new versions of existing crates get "uploaded".

Imagine you call your crate foo.com/bar. In order to push your crate the crates server needs to verify that you actually own the foo.com/bar URL.

There are many ways to do that. A simple one is to just have the crates server pull code from that URL instead of pushing it. If you want to push (e.g. to work around reachability issues such as firewalls) it's just the matter of devising one or more ways to prove that you "own" that handle. For example by serving some challenge response in a html meta tag

<comment><USER4> Right, but then you're back to the exact same issues we're talking about. The choices made by that proxy is the same discussion we're having here, and also means you can't _totally_ rely on the external authority for identity, because you have to manage the mutability in their service. There are many ways to do it, and that in fact is the exact issue at stake here.

All of the existing services it would make sense to delegate to are more mutable than we wanted for our system.

<comment><USER25> Ok the are many angles to this discussion.

What I wanted to highlight was:

1\. I like a package repository that has "namespaces". In fact that's what I like about Go approach to package repository from day zero, despite other rough edges.

2\. Classic approach to "namespacing" like maven's is susceptible to name squatting or just "split authority": who can claim the "org.apache" org? First comes, first served? If that doesn't match who owns the apache.org "brand" on the wider internet, it's not technically a problem of the package repository but surely it's a practical one.

3\. Name squatting problems exist for DNS too; it's a know problem, with an existing administration and dispute resolution body, a marketplace and whatnot. If you cannot get hold of foo.com you'll settle on getfoo.com or (some abomination like that) and that will be your brand as far as online presence is concerned. It's only natural for artifacts you want to associate to that owner to just piggy back on that more prominent identity rather than have to fight it independently for getfoo.com and perhaps land on gotfoo.com because getfoo.com has been taken by somebody else.

4\. Now, _if_ you decided that you want namespacing and _given_ the observed consequences of allowing your users to compete for namespace names independently of their main online presence, I claim there is a technical approach that can achieve your stated goal of reproducible builds. The goproxy is almost what you want. The main different is that the go team aims at a best effort service and thus want to call it a caching mirror. They could have chosen to offer a more strict retention guarantee. Go packages are indeed immutable. The sumdb transparent log is there to enforce that invariant. It's really just about somebody willing to take the burden of storing the package bits forever, which is what I understood you choose to do with crates.

<comment><USER26> Only apache.org can claim their org.apache on Maven Central. This is checked the first time you upload a new package.

<comment><USER25> Which is exactly my point: if you add such a check you've successfully delegated naming governance to DNS as you should.

(I do remember maven before that check was implemented and it was chaotic)

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER27> It's not clear why any of the advantages they tout occur because of the lack of namespaces.

</comment><comment><USER28> This makes me think of how Python coders say that code is or isn't "Pythonic"

So what would Rusts equivalent be... Rustic? Namespaces are not Rustic.

<comment><USER29> > Namespaces are not Rustic

why do you think that?

</comment></comment><comment><USER30> If anything, namespacing doesn't go far enough. We have a wonderful namespacing mechanism already for the Internet - it's called DNS. We use DNS validation as a security foundation for issuing TLS certificates. Package registries should allow me to "own a domain" \- backed up by DNS validation - and upload packages under that name. "Domain ownership" should be paired to a timestamp issued at verification time, so that a) package uploading can be blocked entirely if the DNS verification is lost, b) consumers can continue to download packages under the old domain timestamp c) domain ownership can still transfer as needed d) changes in ownership are tracked, and consumers are notified.

Why does everybody always have to reinvent the wheel? DNS has been around for decades. Using DNS records to verify ownership has been around since, what, the early days of the ACME protocol in 2014/2015? Earlier?

<comment><USER4> DNS records have a financial and technical barrier to account and package creation that we found unacceptable; and those costs are _ongoing_ , leading to an unacceptable level of mutability.

<comment><USER30> Well, you don't have to _only_ accept DNS records! It's like arguing that independent email providers shouldn't provide general addresses like @gmail.com or @fastmail.com if they're going to provide any support for custom domains. You could do _both_. In fact, offering support for custom domains is usually an opportunity to up-sell, particularly to the kind of customers who have already shown that they're willing to spend money on an on-going basis (by paying for the DNS name).

<comment><USER4> I'm still not sure how that solves the problem, but regardless, the point is that there are _many_ possibilities and tons of complexity. It is not a simple, unambiguous problem with a clear correct answer.

<comment><USER30> The problem is caused over people squatting on desirable package names, right? Only solves the issue up to the point where people start to squat on desirable namespaces.

If you only develop one or two packages, you don't really care about the squatting issue. Especially if a non-DNS-namespace is free. Light users are generally unaffected by the problem, so they continue to fit within a "free" offering.

Squatting is a non-issue with DNS. Nobody can take your domain from you; effectively, using DNS outsources the control issue to DNS control. The only issue is to guarantee consumers that their builds won't break just because their packages went through forced deprecation when DNS control transferred. The people who suffer from the issue badly enough to need DNS namespacing are either heavy users (who are therefore much more likely to pay) or corporate entities that actually _desire_ a paid option.

<comment><USER4> For what it's worth, and I don't have a ton of numbers here, the loudest people who want namespaces are people who haven't published a lot of packages, in my estimation. I don't have numbers on that, just gut feels.

> Squatting is a non-issue with DNS.

We must be living on a different web :)

</comment></comment></comment></comment></comment></comment><comment><USER31> I hate namespaces like everyone else, because they're inelegant and kind of uncool.

dependencies: regex

Vs

dependencies: com.cooladtech/regex

But the world doesn't let us have it elegantly, because the library with the name "regex" will almost never be the regex library you want to use. It will almost never happen to be the best, most maintained, best documented, highest performing, with all the regex features you need library.

So instead, the regex library you want will be called "potato". Like a hot potato, potato doesn't let you down when parsing regex.

And then there's the issue of groups of packages that generally make sense together, and no good way to define those groups. So you might have: regex_core regex_engine and regex_api, but it turns out regex_api is for another package and not really part of the group.

Anyhow, back to the article...

Identity? So I read and re-read the section on identity, and I'm not sure what they're saying, it seems they're saying that not having namespaces makes identity worse for discoverability? So basically it argues for namespaces? Now I'm confused...

> A flat registry makes identity management (naming a crate) harder

Than for continuity, it seems to say that if you have a namespace it's bad, because you could confuse two packages of the same name, but in different namespaces?

Okay, I did see this sometimes, mostly in tutorials where they don't list their dependencies, but only their import statements (and sometimes they don't even list the imports). So the reader is kind of left figuring which "regex" lib they are supposed to choose since it exists in many places.

But then the post also says that the lib name can differ from the package.name already? Which means you can already have the same lib name for two different packages in Crates? So I'm confused again?

> Updating to a new package version with different content under different > ownership is a real security risk

I have no idea how this would happen unless I manually changed the dependency to point to the one from somewhere else? So I really don't get the risk here.

> Doubly so if you don't ban new minor versions on the last major version > after an unintentional ownership change

Okay, hold on a second. I don't think this article is debating what I think having namespaces mean. Here it seems like the article imagined a world where you depend on the package name and do not specify a namespace, and then in crates.io someone could transfer the ownership of the package to someone else. Or something like that? This makes zero sense to me, I need someone to explain it to me.

> This is a strike against schemes that encourage multiple distinct crates to > have the same default name in code. I don't think any proposal that > encourages this could be approved.

Okay, now we're talking. This is a GREAT point. Obviously, the import statement must include the namespace as well. Otherwise you can depend on two packages and have import conflicts where who knows which module you're getting? But is this about namespaces? Maybe the argument here is that the way Rust work, this would not be the case, thus risky? If true, I think this is a defeating argument honestly, something has to be done about this. Also it sounds like this is already a problem, because lib name can differ from package name?

Anyhow, I'd direct people to this amazing post from the Go world, and I think they got everything right when it comes to their view of package management: [https://research.swtch.com/vgo-principles](https://research.swtch.com/vgo- principles)

</comment><comment><USER32> I'm sorry but a language that has data entropy and link rot built into its compiler is not appealing to me.

I prefer the Go approach which lets you host or import packages via a HTTP or git URI. If you have to have packaging built-in to the standard toolchain these days, then please use already well-known and existing protocols like DNS and git. Java also figured this out years ago (com.sun... etc).

<comment><USER4> To be clear, you can always depend on a package from your own host, or from a git URL, today.

<comment><USER33> You can also make an alternative registry and add dependencies from that registry.

That said, an alternative registry that enforces namespacing would not work, just because of cargo's limitations on package names that prevent characters like /

It could be done by making every "namespace" a different registry, and for those registries to allow packages with dependencies from other registries (something that crates.io doesn't allow, for a reasonably good reason). Would be quite verbose for the user though.

</comment></comment></comment><comment><USER17> How does crates.io treat bad faith stuff? Like if someone were to make com- steveklabnik-blog.

<comment><USER4> "bad faith stuff" is not dealt with directly. You could absolutely publish that crate right now, and I would have no inherent recourse about it.

For the most part, unless a lawyer says that it needs to be taken down, things aren't taken down. There is a small amount of wiggle room around registering a large number of packages in an automated fashion, but generally speaking, the principle is non-intervention.

<comment><USER34> What qualifies as "a large number of packages"? As was posted in another thread, it seems like the packages of user [https://crates.io/users/swmon](https://crates.io/users/swmon) would qualify?

Alternative to just removing them, would the crates team be more open to transferring ownership of these packages?

<comment><USER4> The focus in that sentence is not "a large number of packages," but the "in an automated fashion."

Plus, that's only 100 packages. There are people who legitimately maintain more crates than that.

> would the crates team be more open to transferring ownership of these > packages?

[https://github.com/rust-lang/rfcs/pull/2614](https://github.com/rust- lang/rfcs/pull/2614)

<comment><USER34> Yeah, it's not obvious what the person I linked's intent is. Resale? I'm pessimistic that the above mechanism would work but I'm glad that rust is thinking about it.

fwiw I also don't think namespacing necessarily solves this problem, it just shoves the squatting problem up a level.

</comment></comment></comment></comment></comment><comment><USER35> I don't know Rust but have learned enough about it to know that lack of namespaces in crates.io and anything at all Rust related Is inarguably a feature

</comment><comment><USER36> It sounds like both flat hierarchies and namespaces won't work cause both sides have fundamental problems that can't be solved in a way that everyone agrees upon. So what about combining them and having the best of both worlds? I think the docker namespace schema provides a great way to have a 2 stage lookup where the first part of the id (up until the last '/') is a full url to the registry, and the last name in the id is the flat hierachy of names for that registry.

In fact this scheme is already supported with cargo since you can specify the registry per dep. This means the default registry, if nothing is added is 'crates.io/' but you can specify any other registry, eg 'gitlab.local/looks/like/namespace' for personal CI, or even 'crates.io/{username}'

Let's give each user their own registry at 'crates.io/{username}'. This works in a backwards compatible way cause registry:'crates.io/' \+ crate:'mypackage' is different than registry:'crates.io/mypackage' \+ crate:'mypackage', so nothing changes with the current crates and it's all an incremental implementation detail for crates.io

Now we have the npm user style namespace ids that lessens the namesquatting problem, but increases the security issues if the registry changes hands. Honestly, I've never really understood the security argument here cause there's no reason an owner can't hand over a single package. As well, there's no reason a currently trusted owner can't patch update a package with bad code. This is a social problem that has no solution and is the same for both naming systems, so we need to come up with another way of handling things. Personally I think all published crates should be immutable and all deps should be pegged, not even allowing patches. But this leads to the argument that sometimes publishers really do want to take down a crate. I'm on the fence with this one, so let's try to solve it in another way.

So the problem is we need to potentially remap any (transitive) dependency to something else, and since we still have a flat hierarchy we really just need to remap the registry for that dependency. So let's add a registry remapping section for the cargo deps ... wait cargo already has something for that ([https://doc.rust-lang.org/cargo/reference/source- replacement...](https://doc.rust-lang.org/cargo/reference/source- replacement.html)). (Reading through the docs here, it does seems like it might be a little strict on whether we can use it for this case, but it's pretty close.)

OK wrapping up, it looks like we could have backwards compatible namespaces right now if crates.io would just implement user specific registries, ie it's an implementation detail. And the security issues are really no different than before. Thus I've got to ask, what am I missing?</comment>


Acquisition condolences  - <AUTHOR> http://37signals.com/svn/posts/2565-acquisition-condolences <comment><USER2> I'm really quite tired of the arm chair quarterbacking that occurs when a startup decides to exit.

Ron Conway said it best in response to Arrington's "Dip shit companies" comment. Ultimately it's up to the founders. The founders have put the blood sweat and tears into the company. It is the founder's life, their equity and their company. If they decide to cash out, then good for them. If they decide to stick it out and work towards an IPO, good for them. The founder is the gladiator in the arena, fighting for their company and their lives. Who are we to publicly criticize and belittle them.

Being a founder is hard enough as it is without other founders publicly criticizing their decisions while waiting for the delivery of their custom Pagani Zonda[1].

ref: [1] : [http://www.autoblog.com/2010/09/07/pagani-zonda-hh- commissio...](http://www.autoblog.com/2010/09/07/pagani-zonda-hh-commissioner- revealed-as-30-year-old-chicago-sof/)

<comment><USER3> I know people like to jump on the 37signals guys, but I don't feel this article is a criticism of founders or investors who choose to sell or be acquired.

It's a footnote reminder that acquisitions, no matter how well intentioned or promising, often result in promising products gradually being starved of attention and resources as the fickle nature of the acquirer shifts to other matters. Condolences to the users as the product is left to wither in "maintenance mode", or mothballed entirely with the sourcecode & IP archived in a drawer somewhere.

It's interesting to contemplate what the del.icio.us and Lala's of the world may have become had they been able to go it alone, and conversely what would have happened to the Facebook or Twitter's had they been acquired in the first few years.

<comment><USER4> Very interesting – that is a conversation worth having.

The trouble with 37signals and posts like this is their tone. It's shrill, nose held aloft, almost scoldy. It's guaranteed to polarize.

I'm sure it's great for traffic, and thus builds their brand, but it doesn't generate the constructive conversation it could.

edit: What's more, come on, "condolence?" Selling a business you built from the ground up is a career-defining move.

</comment></comment></comment><comment><USER5> This isn't DHHs fault, but I think this is the straw that broke the camel's back w.r.t. my own reading of "startup news."

This advice is worthless.

Everything is possible in business. Get acquired and snuffed out, get acquired and blow up, don't get acquired and run a healthy business, don't get acquired and fade out. Get sued and go out of business tomorrow.

Nobody has any idea how the founders and employees at Doppler feel. I respect my fellow professionals enough to congratulate them for their successes however they manifest, and to trust them to seek new opportunities if their current ones fail.

The acquired founders and employees are oppressed and we should offer them condolences? People would kill to have these problems.

</comment><comment><USER6> There _are_ actually other motivations than having a shot at significance. Maybe the founders want to retire on their $20 mill. Maybe they want to go on to building bigger and better stuff with the money they've made. Maybe their investors are prudent and actually expect a return on their money sometime this decade.

This is rather one-sided, but as always from 37signals great linkbait.

</comment><comment><USER7> If there's a scoreboard for the assignment of blame, I would put it 98% on acquirer and 2% on "acquireree". It's hard to fault someone for taking a $20M exit too harshly, but it's quite easy to fault a share-holder backed corporation that should know better.

<comment><USER8> To be fair, $20 million acquisitions would not be the first time money was wasted at a publicly traded company. That is actually pretty cheap compared to running a line of business with no future, such as the search engine at Yahoo or the automobile manufacturing at General Motors. (An obscure American health insurance company, misnamed due to funny historical issues.)

<comment><USER9> The pension funds of GM are at least as big a problem as the health insurance part.

And GM still sells very large numbers of vehicles, if Skoda could be turned around I don't see any reason why the same could not happen to GM.

</comment></comment></comment><comment><USER10> I have a really hard time being sad about this.

Human beings create. We have new ideas daily. When some of them die, it's okay. And it's okay if someone made a LOT of money from the deal.

People will cry. That's fine, meanwhile the people who just got bought will go on to create more, interesting, new ideas.

</comment><comment><USER4> Could this be any more self-righteous?

Here's the deal:

You build value in a startup. A company comes along and sees that value, decides it's worth some cash to advance some internal mission. Company offers you something that feels like a good deal.

Boom: sold. Right?

Who better than the people who built the company can judge the quality of these offers?

Moreover, let's say stodgy old company absorbs an awesome startup and puts their tech forever in the basement (a la Nokia here, or Microsoft with Danger). So what? It's not as though these bright minded founders simply evaporate into the atmosphere, forever lost to the future of human civilization. Now these guys are smarter, more experienced, and hopefully even better capitalized than when they started. If they're truly so bright, off to build a new idea they will go.

And if not, no big deal either, the world got what it could from them. Who's to say their idea/technology isn't in better hands now, held by a company with perhaps steadier revenues or a more mature infrastructure for distributing or selling the product?

There's value in independence. There's value in seeing things through with the long view. Absolutely no disagreement there.

But as long as you're not running an elaborate scam, how you make your money, who acquires your company and what they do with it afterward is none of my business. I hope you got a great deal and that you're in great shape for your next stab at the next big thing. (edit: if you end up making a dominant yet shitty product, though, I reserve the right to pine for the next big disruption.)

<comment><USER11> > Could this be any more self-righteous?

I believe this self-righteous attitude regarding acquisitions comes from being a bootstrapped startup. When you bootstrap your company starts with a valuation of zero. The only way to increase your company's valuation is to start making a profit. For the bootstrapped guys an acquisition offer means that your company has grown to the point where competitors feel threatened. When you are in this position the only reason to sell is if your company is no longer growing (why sell now when your company will be worth more next year?). That is a tragic situation.

The founders who raise money start with an expected valuation greater than zero. Usually these guys can sell well before they ever meet the expected valuation. I mean shit, the startup SocialThing! sold to AOL for $7 million while they were in private beta. In other situations these companies fail to meet the expected valuation and have to sell in order to protect the reputation of the investors and founders. For example Slide sold to Google for $183 million. My company Quiz Monster (bootstrapped) is a competitor to Slide, has a larger userbase, and is worth $1.5 million at best.

TL;DR: Bootstrapped companies have to work harder than venture backed companies in order to receive acquisition offers and thus feel very self- righteous.

<comment><USER4> Solid analysis. I suspected as much thanks to their series on bootstrapped companies.

I say cut the crap, though. If bootstrapping is the better way, awesome – 37signals will enjoy the bathtubs full of money they get at the end of the rainbow, etc.

Life is too short to spend your time with a chip on your shoulder. Or, at least to write like you have one.

<comment><USER12> "If bootstrapping is the better way, awesome – 37signals will enjoy the bathtubs full of money they get at the end of the rainbow, etc"

That's the problem. 37 Signals says it's the better way, but not obviously better for the founders. You won't get rich, but the world will be better off for having a better company.

<comment><USER13> _"You won't get rich"_

Says who ?

Some estimates peg 37Signals as being profitable to the tune of $6 million per year. Divided equally between the 12 employees that's $500k each. Not bad for a year's work.

For more see: [http://blog.jedchristiansen.com/2008/12/04/estimating-37sign...](http://blog.jedchristiansen.com/2008/12/04/estimating-37signals- revenue-and-general-profitability/)

<comment><USER12> But also not the kind of exit and FU money that entrepreneurs often seek.

This is just my understanding of _their_ argument, though. Better to grow a company slowly and keep running it, than to grow a company and get bought. They think you should be in the game to keep running the company, not get rich. Getting rich while running the company is also possible, but that's a nice side-effect as far as they're concerned.

</comment></comment></comment></comment></comment></comment><comment><USER14> Sometimes it cuts the other way though. Take Flickr: bought for just a bit more than Dopplr by a company with significant problems, today the #2 photo site in the world (after Facebook) and more relevant and vibrant than ever.

<comment><USER15> flickr is huge, but I don't think yahoo has done very much to advance the original feature set. which is also true for delicious. though I agree there are cases, I'm hard pressed to find many. Maybe android (google), but not dodgeball (google).

<comment><USER16> Though Yahoo did do things to clean up some of the dipshit decisions made by the founders after they left. Originally if you uploaded anything but photos taken with a lensed camera (like illustrations or screenshots), your account would be marked so that everything you posted never appeared in searches or public site areas. This practice only stopped maybe 2 years ago.

They also finally redesigned the photo pages to display them larger than 400px wide. It's no longer lower-res than Facebook, but it's still much slower since they don't prefetch images.

</comment></comment></comment><comment><USER17> Right, according to the condescending trolls at 37s, selling a company for $20 million is a failure.

Sounds like: "You poor thing, running a company by yourself so you decided to sell? Better luck next time, sucker"

37s built a good company. Congrats guys. Now quit shitting on other people's corn flakes. Deal?

</comment><comment><USER18> I noticed DHH said in the comments his beef was not with the founders selling their companies, but with the Megacorps that let their acquisitions rot.

<comment><USER19> I think sometimes these Megacorps buy out some one just so some one else cant do that and challenge them. Of course some of these could just be bad decisions.

</comment></comment><comment><USER20> Shouldn't we feel more sorry for the people who can cash out and spend the next 50 years on a beach with their families and friends, but choose to work instead?

Don't get me wrong; I love creating and I am really looking forward to working on my start-up full time, but you know what I love even more? My family and my friends. If I had an opportunity to comfortably spend every day with them, I wouldn't think twice.

<comment><USER21> it never is, nor it should be, a binary choice. you forever have to find a balance between the two. if you would quit your startup forever assuming you had full financial backing to spend with your family and friends, then you really see your startup as a means to an end and not a hobby/lifestyle like many others do

you call it work, many others call it their hobby. they just happen to do it full time and get paid for it.

<comment><USER20> You are right, each person has their own balance they must find. Otherwise, my comment is no different than dhh's article.

I would argue, though, that I can still see my startups as a hobby/lifestyle even though I would I be more than happy to retire early with fu money. Primarily because I would still want to start build my own products even without the lure of getting rich quickly.

</comment></comment></comment><comment><USER22> I think many HNers are missing the point.

This shows that building something with no profits in the hopes of getting "acquired" is not a sustainable model.

Cases like this might eventually convince big companies that acquiring startups is not that valuable after all; specially the startups that have no business model other than hoping to get acquired.

This is specially true if you (as a big company) think you're acquiring the talent (the guys who built the startup). The truth is, they will inevitable leave, because working in big companies sucks.

Building something valuable without a business model other than hoping to get acquired sounds like a scam against big companies. Basically the business model is to sell the product once for a _huge_ sum of money, and the guy who buys the product (the big company) doesn't get anything out of it; hence the scam.

The second point is, your product (as a startup) is now dead. Doesn't that make you sad? Wouldn't you be more satisfied if users loved you _and_ you were making money _and_ still doing what you love?

</comment><comment><USER23> It's up to the founders to judge a good exit or not. They are the ones who built the product and they know if the offer is good enough based on their product and their lives.

I just don't understand the flak founders get when they sell. Tell others is bad to sell without knowing the dynamics of the company and founders is not the way to do it.

People have different expectations from life and their work. One thing is growing a business and having no problems with money and feeling good about it and having no plans to sell, other is building a business and trying to make a living off of it. If you get a good offer and meets your expectations is reasonably that you would sell.

Ultimately is up to the founders to know what to do with their product and we have nothing to do with their decision because we aren't part of the business.

If the product goes to the basement after being acquired that gives the rest of us an opportunity to build another better than the one who was acquired. The founders have done their job and it's time to move on and think about a new idea.

</comment><comment><USER24> Man, these guys talk about $20 mil as if it were chump change. Probably because they have all that blog-money now.

If someone ever wants to buy _my_ company for $20 mil, and I walk away with even half that, I will be a very, _very_ happy man.

<comment><USER25> Probably because they make that amount of money in a single year.

</comment></comment><comment><USER26> He is right that acquisitions kill companies, and it is tragic to watch. I admire the romance DHH attaches to his work. You can tell he pours his heart into it.

But he underestimates the benefits of money. Even if "mojito island" is a mirage, having enough money so that you don't _have_ to work again is extremely valuable. You can take long breaks, tour the world, or pursue endeavors that may not necessarily be profitable, such as art, philanthropy, or politics. If you choose, you also have the means to start a new company from a position of comfort and control.

And besides, people often simply get tired of working on the same company and want a change of pace.

</comment><comment><USER27> You know the rules from the start. You start a company and you own only what you put in it. If it's ideas, you'll own them. Comes the day you need cash, investors make an offer. You don't have to take it. If you do, time to share a piece of your company, or more. Comes the day your little startup attracts the attention of a behemoth, they offer you a deal. You don't have to sell.

So all in all, I would recommend the following: Only complain about the way an investor treats your company if they deceived you. Otherwise, just accept that it's not your toy anymore and you got paid for it.

</comment><comment><USER28> The thing is: the Dopplr founders, early staff, and investors all likely made money. Whatever you call it, that's hardly a _bad_ result for them...

OK, bad day for Nokia. Dopplr's fault? Nope.

<comment><USER29> The argument isn't that some people don't make money, it's that the users and probably the founders are better off building a company that lasts. The users get a great product and the founders get to build and run a profitable business. Part of their argument (which is referenced but not explained in the post) is that it's not personally fulfilling to get rich and retire early but rather to continue to build.

<comment><USER28> Reading the article, you can certainly argue that Dopplr didn't have the adoption curve they hoped for. They get money, they get to do something new (one founder's a partner at BERG London, who are pretty kick-ass).

The users? Sure. But it's a free service. Like the recent quote says, the users are the product. (<http://www.metafilter.com/95152/Userdriven- discontent>, top comment.)

DHH's hating the players when he should hate the game.

</comment></comment></comment><comment><USER30> While this post is a bit on the dramatic side, I think the core point is good. I don't blame founders for selling companies knowing their product will be destroyed, nor do I blame BigCos for buying them.

But how is this encouraging startups to provide something useful to society? It's just encouraging them to target products at larger companies, not to actual customers.

</comment><comment><USER31> If megacorp buys a promising startup and thwarts it, then does this also create a new opportunity to fill the space left by the startup?

<comment><USER32> Perhaps; but it seems likely to me that another startup in the same niche would find it harder to be acquired, as megacorp #1 doesn't need another acquisition, and other megacorps might not choose to enter that space themselves. A new startup in that space might have to be bootstrapped, which might not be an appealing option.

</comment></comment><comment><USER33> Don't listen to rich people telling you that you shouldn't get your first million dollars. Is this post that different than a VC hoping poor founders stay hungry?

</comment><comment><USER34> I think there would me more condolences if money were hidden away from creators. Acquisition is a fruit you can take or reject but anyway is a sweet fruit.</comment>