PayPal Freezes Mailpile Campaign Funds - <AUTHOR> http://www.mailpile.is/blog/2013-09-05_PayPal_Freezes_Campaign_Funds.html <comment><USER2> I don't know why, in 2013, people are surprised when they use PayPal and wind up without access to the money for months or years. Paypal apologists will say that this is relatively rare. Even if that is true, since the criteria they use to take these actions are often beyond the control of merchants, using PayPal is an unacceptable risk for any business that doesn't have at least 6 months of working capital.

Always avoid PayPal if you need access to the money. Even if you feel that your business falls squarely within PayPal's AUP, always have a backup implementation with an alternative payment provider coded and ready to go (I recommend using Stripe and skipping PayPal altogether). You don't want to lose new sales on top of the money PayPal decides to hold indefinitely.

<comment><USER3> I've seen PayPal nearly put several small businesses out of business.

There are some things that cause PayPal to just freeze an account, and it's next to impossible to speak to a human or to otherwise get the situation resolved.

Pretty much the only threat to Stripe's eventual world domination would be PayPal getting its act together.

<comment><USER4> Most of Paypal's competitors weren't wiped out by Paypal being good, they were wiped out because they weren't as good as handling risk and fraud as Paypal. They got wiped out by criminals.

Paypal is risk averse, which means you shouldn't use them for cases where you're taking a large amount of money up front and not delivering in the near future (i.e events, crowd-funding), or alternatively get pre-approval from Paypal.

I've no idea what the current fraud level against Stripe is, but as they become more mainstream they're going to need to employ more anti-fraud and anti-risk measures as their exposure increases.

<comment><USER5> > _I 've no idea what the current fraud level against Stripe is, but as they > become more mainstream they're going to need to employ more anti-fraud and > anti-risk measures as their exposure increases._

I'm one of Stripe's cofounders. For what it's worth -- we already process billions of dollars a year. (More than PayPal when it was acquired.) There'll always be _more_ we can do on the fraud/risk side, but we're already operating at a scale that requires a decent amount of sophistication.

<comment><USER4> (in a previous life I worked in front office investment banking so had to undergo anti-fraud and anti-money laundering training as well as worked on general exposure risk issues)

The problem is that fraud/risk (like tech security) is it often involves black swan events. Everything seems fine right until the point where it's not and you're on the hook for millions of dollars (Stripe is probably in the position where you can afford to take a few black swan type events and survive; a lot of Paypal competitors weren't).

Given that Stripe don't do the "wallet" approach of Paypal and is primarily focused on API customers I'm guessing your risks in general are lower, but I'd recommend you be careful about becoming over-complacent.

<comment><USER5> > _I 'd recommend you be careful about becoming over-complacent._

Absolutely. Indeed, I'd characterize us as actively paranoid. My point was merely that we're already operating at a scale that needs pretty good fraud systems.

(I think we're mostly in strong agreement.)

<comment><USER6> Does fraud follow the power law?

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> _They just don 't want to, and we cannot help but wonder why._

The risk of complaints, refunds, and chargebacks for non-delivery would be my guess.

 _" Please provide an itemized budget and your development goal dates for your project"_

 _This puts us in an incredibly uncomfortable position..._

...of having a roadmap for your product's development. It's really not unreasonable, and if you don't have even a vague idea right now, that's a big warning sign.

 _... we do not feel that it 's remotely in their jurisdiction to ask for a detailed budget of our business_

Which is unfortunate, as PayPal's business boils down to risk management, and they're asking you to reduce their risk.

<comment><USER8> Note that they had previously stated that they wanted to release the funds as slowly as possible. Asking us to provide a detailed budget is basically asking us to justify that and give them a timetable so they can withhold the maximum amount of cash for the maximum amount of time.

<comment><USER7> _Note that they had previously stated that they wanted to release the funds as slowly as possible. Asking us to provide a detailed budget is basically asking us to justify that_

None of this contradicts my point about mitigating risk, nor that it's a Very Good Idea to have even the most basic of development roadmaps.

<comment><USER8> Sure, but we have no reason to give those details to PayPal, and very good reasons not to.

Edit: Delaying payments by months is not acceptable or reasonable. There are tax implications (we have to deal with multiple jurisdictions) and opportunity costs. Also, this very obviously goes against the wishes of our community of backers - they are supporting a free software development project, not buying a product.

<comment><USER7> _Sure, but we have no reason to give those details to PayPal_

You'll reduce your risk profile, and increase your chances of receiving payment inside the next year.

 _and very good reasons not to_

Aside from potentially delayed payouts, what are your other good reasons?

Edit, replying to your edit:

 _Our community of backers... are supporting a free software development project, not buying a product_

Do you know for a fact that all of your backers 100% understand the difference?

Do you also know for 100% that you will receive no complaints, no refund requests, and no chargebacks in the event that you don't deliver?

<comment><USER9> I see your point.

PayPal is a business partner in this setup, and they are shouldering a lot of risk on the developers behalf. I can understand not wanting to share something as intimate as a business/developement plan, but PayPal is within their rights, boty legally and morally, to ask for one. If the developers are having trouble with this, they should find another partner for their venture. (imho)

That said, PayPal can be real douchebags. Too many friends, business partners and colleagues has been burnt by them in the past. If you're doing something nonprofit, move elsewhere.

<comment><USER10> > but PayPal is within their rights, boty legally and morally

No and no. They're a payment provider, a utility, not a partner. They could have stated up front that they want a business plan or could have denied acting as payment provider. They could have demanded the backers to waive their refund rights. I'd even be on their side if they kept a percentage of the funds as security.

The backers have a moral right to see a business plan, if any person at all has one. It's their money and they did not give it to paypal so that paypal can collect interest on it, they gave it to mailpile and they collectively are shouldering a much bigger risk than paypal in that transaction.

<comment><USER11> > they collectively are shouldering a much bigger risk than paypal in that > transaction.

No, they are not. Financially, PayPal is the one shouldering the biggest risk.

Edit: > No and no. They're a payment provider,

They most likely have legal obligations in various jurisdictions and with the credit card providers to do due diligence. And looking at business plans and how payments like this will be used is an important part of that. Try getting the same funding directly from a bank rather than going through a middleman and see what they ask for.

Every time a PayPal story comes up, I'm always reading at how the people are innocent and everything is fine, and yet, they are doing something shady.

Here you have an organization that's effectively asking for donations to support a project, but it's not, from what I can tell, certified as a non- profit.

So suddenly yes, that does become high risk. Any banker in the world is going to look at this scenario and know that it's high risk.

<comment><USER10> > No, they are not. Financially, PayPal is the one shouldering the biggest > risk.

Actually not. Let's assume a chargeback rate of 100%. The donated amount was 135 000 USD, the amount PayPal handled was 45 000 USD, so the remaining backers collectively shoulder about twice as much risk as PayPal.

> They most likely have legal obligations in various jurisdictions and with > the credit card providers to do due diligence.

They're an official payment provider for IGG. I assume they know what IGG is by now and the risks associated with that. So they can either

a) choose to forfeit that business because it's too risky. Fair enough.

b) Lay out the conditions early: Hey, we'll take the money and keep it for a year. But would would IGG then still offer PayPal as payment provider?

c) eat the risk and honor the implied contract.

> Here you have an organization that's effectively asking for donations to > support a project, but it's not, from what I can tell, certified as a non- > profit.

Yes, that's what they do. Every backer voluntarily decided to support that business. I backed kickstarter campaings because the project sounded nice and I wanted those people to have a chance to finish their project, because I thought it was a worthy thing to back. I never even touched the finished goods. A lot of open-source projects ask for donations without being non- profits, for example nginx do. Point is: everyone can decide under which conditions he'd like to support a project - certified non-profit or not, but that's not PayPals business.

> So suddenly yes, that does become high risk.

Sure. Nobody denies that crowdfunding is not inherently risky. But see above. Either don't participate or live with the risk. But PayPal is trying to eat the cake and still have it too: They happily took the money and kept the fees, but will neither refund it to the backers nor cash it out. That's shady in my opinion.

<comment><USER11> > the amount PayPal handled was 45 000 USD

Which is the only part relevant to this discussion. PayPal's risk is far greater than 45,000. This depends on how much PayPal is charged for chargebacks, a rate I cannot know.

> They're an official payment provider for IGG. I assume they know what IGG is > by now and the risks associated with that.

Yes. Hence the reason for the additional due diligence. Understanding IGG's operations, it makes complete sense that the would oversee individual projects going through on IGG, and doing additional due diligence on top of IGG. You are making a unwarranted assumption that they their diligence stops at IGG. Having dealt directly with situations like this (essentially acting as an IPSP, or basically, something akin to IGG), banks are still required to do their part.

> Point is: everyone can decide under which conditions he'd like to support a > project - certified non-profit or not, but that's not PayPals business.

Just because you say it's not PayPal's business doesn't make it so. It's very much their business. The belief that it shouldn't be their business shows a lack of understanding of the area that PayPal operates.

> Nobody denies that crowdfunding is not inherently risky.

Except no one understands all the risks that are involved. Otherwise, you'd understand _why_ PayPal should be asking for how the money will be used, the business plan, etc. These are additional steps that should be taken precisely because of the risks that exist.

Stopping diligence at IGG would be horribly, horribly wrong.

> Either don't participate or live with the risk.

They are trying to participate. They are being denied.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER12> People should start to understand that crowdfunding is _not_ a trivial business from a legal and regulatory perspective.

Yes, PayPal sucks, but you can run into this crap with any bank or payment service provider you don't have clear and direct business dealings with, and who you haven't informed upfront about what you're up to.

Also, it's just plain lazy and irresponsible of IndieGogo to pay out via PayPal, at least not without big fat warning signs. Of all the options available, this is pretty much the worst.

It's very naive to think that you can just accept money in exchange for unverifiable promises and not set off all kinds of alarm bells. Expect frozen assets to start to happen more and more often with crowdfunding, and not just at PayPal.

<comment><USER13> I'm surprised PayPal still haven't taken a clear stance against crowdfunding like Amazon Payments have. That's part of the problem - it's really vague as to what situations PayPal will intervene in.

<comment><USER14> That's funny, because Amazon Payments is _exactly_ what crowdfunding site Kickstarter uses[0] to pay out to projects.

[0]: [http://www.kickstarter.com/help/amazon](http://www.kickstarter.com/help/amazon)

<comment><USER15> I think that Kickstarter has their shit together, and the risk of a chargeback from Kickstarter to [project leader] is relatively low, compared to the risk of a project funded directly through Amazon Payments.

I don't know how indiegogo works, but in the case of Kickstarter, I would assume that Kickstarter is collecting the payments, arbiter of refunds in the case a goal is not met, and does not have access to the money in the interim.

Then Kickstarter uses Amazon Payments to disburse the funds to project lead? I am uneducated and did not contribute to the fund, so I don't really know how it works. Can you enlighten?

<comment><USER16> Not 100% sure but I think kickstarter uses amazon's deferred payment api. Basically they get authorizations from the donors to be charged a certain amount on their credit card, but the amount isn't charged until the crowdfunding ends successfully. If the goal isn't reached nothing is charged on credit cards, if it is, the money is sent to kickstarter's amazon payments account, and from there kickstarter sends it to the project after taking its cut.

<comment><USER15> Ah. So, it sounds lower risk for Amazon, but I don't really know how indiegogo and paypal interoperate, so maybe it's the same exact pattern.

Sounds like a fantastic racket for Kickstarter!

EDIT: I've read more of the comments and it sounds like IndieGoGo has nothing to do with Paypal. They were separate funding efforts, from the same landing page. "You can pay by IndieGoGo or Paypal."

I presume the reason I couldn't figure this out from the Mailpile website is that they stopped mentioning the PayPal option when it was clear that Mailpile wasn't going to get paid by PayPal in any kind of short order. You can pay IndieGoGo or you can send Bitcoins.

That's how I'd run my business if I didn't have a product yet. You'd have to be crazy to use PayPal for that.

EDIT2: I guess IndieGoGo does offer the PayPal option. I don't understand enough about how this is put together to have an informed opinion. If PPUSD and credit cards are all handled by PayPal, then it would seem that PayPal does indeed have some risk. Maybe it's actually accepting credit cards that's crazy. _THOSE_ have some serious anti-fraud guarantees, and there's more to fraud than simple non-delivery.

</comment></comment></comment></comment></comment></comment><comment><USER17> I work at GoCardless.com, a UK-based payments startup (YC S11), and thus I have a above-average insight into these kinds of issues from my day-to-day work.

From the point of view of fraud protection and risk management, I can see why PayPal take this kind of unilateral action. Payments providers are always at high risk, and since they deal with and indemnify other financial firms further up the chain, they're the ones taking the risk.

Even when you're charging relatively high fees as PayPal does, one case of fraud or even something as simple as a project that doesn't materialise (not that I think that'll happen with Mailpile!) can eat up tonnes of your revenue and make your business unviable.

As such, GoCardless sometimes has to make decisions that account holders won't like. However, the difference between us (as well as, I believe, other providers like Stripe) and PayPal is that we will be (a) reachable and (b) reasonable.

For me, PayPal's failing is in the lack of customer engagement on these issues. Every story like this shows PayPal as cagey, unhelpful and unwilling to have a discussion or reconsider at all. Everyone can, to a degree, understand why PayPal has to make unpopular decisions to protect itself from unacceptable risk (as all businesses will have to do in various ways), but their approach and manner in doing so is what is unacceptable.

</comment><comment><USER18> What strikes me as really disappointing here is that the person has no idea why PayPal has frozen their account. It's surprising to me that they don't understand the inherent risks to PayPal from a kickstarter program (how dare they ask me for my business plan?!). In this post at least it seems like they just think PayPal doesn't like them and wants to hold their money for a long time. I guess they should have done more reading up around the financial side of a kickstarter.

And PayPal is clearly at fault that this person is so confused and upset too. How hard is it for them to say "In the past, we have seen crowd funding sites/services that never delivered anything. That resulted in a lot of unhappy end users going to their credit card companies and initiating a chargeback which we're on the hook to pay. As you can see, if you took the money from your account and disappeared we'd be on the hook for that entire $X. That's why it's important we understand more about what you're up to"

It would be ideal if this happened pre account/money collecting but I don't know all the details around that (Perhaps this is a long term account used for "normal" credit card processing who then decided, without informing PayPal, to run a Kickstarter. Who knows)

<comment><USER19> >> How hard is it for them to say "In the past, we have seen crowd funding sites/services that never delivered anything. That resulted in a lot of unhappy end users going to their credit card companies and initiating a chargeback which we're on the hook to pay. As you can see, if you took the money from your account and disappeared we'd be on the hook for that entire $X. That's why it's important we understand more about what you're up to"

The reason they don't is probably experience. If you're delivering bad news, don't mess around and don't over-explain. Every extra sentence in your communication is just a potential complication. Tell the target the problem simply, including details that directly relate to their conduct, and tell them how to fix it to your satisfaction. Don't tell them the history of this type of problem.

You do this because the target is going to be upset about it and they're going to want to argue. The more you communicate, the more points they have to argue. In your description, I see at least four more points to argue ("we're not like those guys that didn't deliver...our users are different...we're trustworthy people...you're only a percentage of our total funding so your risk really isn't that great..."). None of those points matter and none of them are going to change anything.

Paypal has told them what's wrong and given them concrete steps to fix it. Anything more is just going to drag out the resolution of the problem from Paypal's perspective.

<comment><USER18> The problem with your answer though is that this was the top post on HN for x hours and damaged an already damaged (and trying to recover) brand. So I would say the complications of additional details would offset the risk of saying little and sending a bewildered blogger into the wilderness.

</comment></comment></comment><comment><USER20> Indulge me in a flight of fancy in which we pretend, for the sake of argument, that

a) Paypal is run not by Snidely Whiplash clones but b) by smart geeks working with thin margins in a highly regulated industry where c) customers are at risk essentially never, d) merchants eat 100% of the risk if they stay in business, and e) Paypal eats 100% of the risk if the merchant doesn't.

Why is Paypal very skeptical of pre-sales? Because, if the business fails (as new businesses often do), customers _will_ file chargebacks. Their banks will hear "Internet merchant did not deliver as promised" and sustain the chargeback _automatically_. Paypal will lose that argument with the bank, 99.999% of the time, and have to seek restitution from the merchant.

Paypal has to do underwriting -- basically, guessing at probable risks and likelihood of partial repayment -- for new merchant accounts. What percentage of sales are at risk of chargeback in a pre-sales business? A Very High Percentage (TM). What is the probable chance of failure of a new business in developing a new product? Fairly high. Given product failure, what assets will be available to Paypal (in the Paypal account or the linked bank account) for automatic recovery from the failed business? Very Little (TM). What is Paypal's margin on this business? _A fraction of a percent._

Now we break out the Hadoop cluster and use several billions of dollars of transactional data to construct a model of what the expected loss is, expected recovery given loss, and expected margin in event of non-loss is.

 _This puts us in an incredibly uncomfortable position as we do not feel that it 's remotely in their jurisdiction to ask for a detailed budget of our business, any more than it is within our right to ask for theirs._

This communication is incredibly useful from Paypal's perspective among multiple axes:

1) It signals very strongly "We are not only unwilling to comply with the table stakes of every underwriting process for businesses everywhere, we are so inexperienced at business as to be unaware that this _is_ table stakes, and accordingly you should dramatically revise upwards your estimate of our risk of failure."

2) It provides Paypal a simple, face-saving out for declining this business without having to say, in so many words, that "You seem, oh, 93% likely to ship this year. You get an A! This means, however, you are 7% likely to lose all the money, and we only make .9% margins, so this is going to be a No. We get that you don't like this. We don't like having to decline hundreds of dollars of revenue either, but we have the experience of losing _hundreds of millions_ to fraud and know that some revenue just isn't worth the risk. We respect that you might not agree with this, but don't feel the need to spend additional resources paying for our computer programmers, underwriters, lawyers, and accountants to give you an expensive education in the realities of e-commerce on our nickel."

Let's talk about the difference between Paypal and Indiegogo:

1) You pay Paypal ~3% when their costs are probably approaching ~2%. Indiegogo would charge ~7% for the same thing. One of the luxuries when selling something which is five times as lucrative is that you can self-insure against project failure.

2) Indiegogo believes it has a different business model than Paypal and that they have a uniquely better understanding of the risks of crowdfunding, whereas Paypal has had their filters tuned by too many middle Americans selling Beanie Babies.

3) Paypal has lost hundreds of millions of VC money to fraud and Indiegogo hasn't. Paypal decisionmakers might at this point give Indiegogo the sort of look a school psychologist gives a C student with a drug habit who has just announced that they're taking a semester off to find themselves, man. They know which way this story is going to turn out, which is in its own special way as bad as not knowing how the story is going to turn out.

 _Are the risks larger because we are successful?_

Ask a simple question, get a simple answer: yes! Paypal loses more on a $1,000,000-in-transactions account which goes bad than a $1,000-in- transactions account which goes bad, clearly. You might wonder "Well are we more risky than the same aggregate volume spread over N accounts?", in which case the answer is available to Paypal's Hadoop cluster but plausibly "Yes, with a p value which would make a statistician weep." Accounts which go 0-to-60 in processed transactions are hugely disproportionately likely to be outright fraud (Paypal has had many, many, _many_ encounters with carders smart enough to have invented the suborn-a-botnet and make-a-lot-of-small- donations attack prior to having seen it on Breaking Bad). Additionally, it is quite plausible that Paypal could demonstrate that success is a curse to new businesses and most which blow up proceed to, well, blow up. (Which they would, of course, not love to disclose publicly.)

This dynamic is not unique to pre-sales or crowdfunding. It also explains Paypal's active hostility to many other business models, including money services businesses, third-party payment aggregators, and travel agents. (Most people don't immediately associate travel agents with having a lot of payment industry problems, but they do: they make lots of big-ticket sales but have low working capital, and if a cruise gets canceled or a hotel goes bankrupt or any of the standard vicissitudes of the industry causes them to eat a bunch of chargebacks all at once, they go bankrupt and their payment processor is on the hook for hundreds of thousands or millions of dollars as that bankruptcy causes cascading failure to deliver promised goods or services.)

<comment><USER21> This is absurd apologism. If Indiegogo projects are fundamentally incompatible with PayPal's risk profile as you imply, the onus is on PayPal not to accept money for those projects. Full stop.

Why on Earth should we sympathize with PayPal about internal aspects of their underwriting at the expense of a small business whose funds they've practically seized?

<comment><USER22> As has been pointed out elsewhere, PayPal has an explicit policy about how they handle presales. Why can't I turn your argument around and say that if somebody doesn't like that policy, the onus is on them to not use PayPal?

<comment><USER21> I don't grant your premise that crowdfunding constitutes "presales."

Crowdfunding is an inherently speculative activity, a way to invest in a team with the hopes that they will create a product that you'd like to see in the world. Trying to fit Indiegogo into a presales model to justify PayPal's outrageous behavior here is a Procrustean approach that helps no one.

<comment><USER23> That's even worse than engaging in presales! It's practically fucking gambling the way you describe it, why the fuck would Paypal be _enticed_ by that subtle shift in framing?

<comment><USER21> Yeah, it's "gambling" the way donating to an artist you like is gambling.

And who's trying to _entice_ them? Again, if doing business with Indiegogo projects is incompatible with Paypal's risk profile they shouldn't do business with Indiegogo projects. That seems straightforward.

Bizarre to think we should be sympathizing with, enticing, or otherwise fellating PayPal in this situation.

<comment><USER23> _Bizarre to think we should be sympathizing with, enticing, or otherwise fellating PayPal in this situation._

While I understand how easy it is to sympathize with the merchant here, as none of us will ever be payment processors, the reality is that the sum of your suggestions or assertions, if explored just as a thought experiment, quickly lead to a world where nobody can do payment processing without imposing absurdly high fees. Of course we can all see how unfair it seems to have all this money promised by seemingly wide-eyed and clear-minded open source software supporters. But Paypal has millions of clients and has to act in a way that generalizes across all of them, and which requires the least amount of trust to be placed in those clients. The only argument that Mailpile has is "but we're not evil," which is true, but still insufficient.

<comment><USER24> The thing is...

...nothing is being sold.

<comment><USER25> Which, presumably, would not stop people filing chargebacks if Mailpile fails to deliver on their promises.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER26> Two things people need to keep in mind when using PayPal.

1) The company functions as an uninsured bank while essentially skipping the label thereby giving itself a legal loophole to function as it pleases. However, unlike a bank, you can't get to an actual human being in a timely manner unless you're dealing with hundreds of thousands of dollars or even millions. You're simply not important enough and PayPal is big enough that none of your complaints will really make a dent.

2) PayPal puts a value on risk. Your perception of this risk may be markedly different from PayPal's, however it is still there and if you trip over that threshold, you will be shut down with extreme prejudice. Projects like Mailpile function in a different world than even digital goods of a few years ago. You're not really donating for a product, but the expectation of a service which will, hopefully, come to fruition. The risk threshold set by PayPal is still under the older digital goods model which is an ill fit for Mailpile to begin with.

Those two aren't the only reasons why no one should use PayPal, but keep in mind that nothing you do, show or even consider reasonable matters to them as it's their assessment that ultimately holds sway. You're dealing with a banking megalith with an equivalent responsiveness.

Do not use PayPal.

</comment><comment><USER27> Or you could read the terms of the business relationship with PayPal:

      Am I allowed to presell?
      Yes, you are allowed to presell items as long as you follow these guidelines.
      Off eBay presale requirements
      If you sell items in an online store (not eBay), you must guarantee delivery
      within 20 days from the date of purchase and make sure that the customer
      knows they are buying a presale item.
      [...]
      If you are selling goods or services in an online store (not eBay), you may
      be allowed to presell items but we may hold your money in a reserve
      account or limit what you can do with your account to reduce the higher risks
      associated with presale items.

Or as the ruder ones of us said in the 90s on Usenet: RTFM.

[https://www.paypal-businesscenter.com/content/presale- policy...](https://www.paypal-businesscenter.com/content/presale-policy-and- reserves)

</comment><comment><USER28> PayPal is fine for a certain class of limited transactions - usually when they involve selling physical or digital products which actually exist and can be delivered _today_.

Rightly or wrongly though they have a very[1] long[2] history[3] of freezing the accounts of projects they deem to be remotely 'risky' to them. By definition this would seem to include almost any crowdfunded project where an actual product or service which people are paying for does not yet exist.

Given how well documented this is I can't help but wonder why a company like IndieGoGo would touch PayPal with a bargepole - their interests seem diametrically opposed !

IndieGoGo should be protecting their users by disabling PayPal as a payment option for all projects.

[1] [http://techcrunch.com/2011/12/06/paypal-account- freeze/](http://techcrunch.com/2011/12/06/paypal-account-freeze/)

[2] [http://www.holdtheline.com/threads/paypal-freezes-funds- from...](http://www.holdtheline.com/threads/paypal-freezes-funds-from- skullgirls-crowdfunding-drive.5309/)

[3] [http://www.siliconbeat.com/2013/08/16/paypal-freezes-then- re...](http://www.siliconbeat.com/2013/08/16/paypal-freezes-then-returns- money-for-glassup-campaign/)

</comment><comment><USER29> Part of the reason we open-sourced Selfstarter was to prevent situations like this happening to other companies. With Selfstarter and by extension Crowdtilt's Crowdhoster [1] if you have a problem like this, it would merely be a setback rather than a crisis.

You manage your relationship with your customers, not someone else. If your payment processor gives you trouble, have your customers re-auth with a friendlier provider like Stripe, WePay or Amazon. If nothing else, even having the option to do so gives you more leverage should you find yourself in this position.

If you need further convincing about the benefits of self-hosting your crowdfunding campaign, please see this earlier comment: [https://news.ycombinator.com/item?id=6261442](https://news.ycombinator.com/item?id=6261442)

[1] [http://www.crowdhoster.com/](http://www.crowdhoster.com/)

</comment><comment><USER30> Wow, I'm really surprised by the amount of snark on this thread aimed at mailpile. They are following IndieGoGo's standard process. For PayPal to take exception with them and single out their funds is ridiculous. If PayPal wants to start requiring IndieGoGo campaigns to submit business plans, they should work that out with the site, not an individual campaign, and certainly not after the whole thing is funded. This is not Mailpile's fault for following procedure.

<comment><USER31> Yes, it's odd how everyone is piling onto Mailpile for something that PayPal doesn't do with other IndieGoGo campaigns. If crowdfunding is so risky, why is PayPal totally fine with it for every other campaign out there?

Yes they make promises and there's no guarantee they'll deliver. That's the whole point of crowdfunding, it's like that for every other campaign. Why is PayPal singling out Mailpile?

</comment></comment><comment><USER13> > _They just don 't want to, and we cannot help but wonder why. _

> _Crowd funding is an adventure._

I don't think PayPal are as enthusiastic in joining you in an "adventure" as you think. Especially if that adventure includes credit card chargebacks.

<comment><USER32> Sounds like an opportunity to create a crowdfunding site that only accepts cash in the mail. But then, I'm sure you open up a whole new can of worms.

<comment><USER13> The problem there is getting people off their asses to actually do it. One- click Paypal login has a very low barrier to purchase.

</comment></comment></comment><comment><USER33> You need to get Indiegogo involved and IGG need to take serious measures, such as threatening to completely disable the paypal option from all their future projects.

</comment><comment><USER34> This is exactly why our company stopped focusing on our Paypal integration and started focusing on other gateways, such as Stripe and WePay. We had built a really great Braintree gateway, but they to came out with a policy against crowdfunding.

As far as I can tell, you can still get through and/or avoid messes like these by communicating with the gateway up front in order to get permission. Robert Space Industries did this with Amazon and Paypal before launching. They were forced to provide much of this documentation, but in the end, it helped them avoid any major hiccups.

Of course, IndieGoGo should be working with merchants to help them through this. If they are going to be the intermediary between the crowd and the company, they should do the same when dealing with payments. Sadly, all of the major crowdfunding platforms lack in this regard.

If you're thinking about crowdfunding and are nervous about being shut down, I recommend you run either as donations or pre-orders. In the case of the latter, you are best not taking funds until the goal is met or you've reached a certain development milestone.

I do think that this sucks for crowdfunding in general, but perhaps it will curtail the money grab that has been in place for some time.

And of course, if you want to have as many options as possible, check out [http://IgnitionDeck.com](http://IgnitionDeck.com). A WordPress install and you can have your choice of gateways.

Good luck to the Mailpile guys. I recommend providing this information. It will be good to have in the event that an investor knocks on the door.

</comment><comment><USER35> ...and that is why you don't use PayPal, no matter how loud people scream that they want to use PayPal.

Seriously, PayPal has screwed over so many individuals, businesses and projects in the past, the obvious conclusion is that PayPal isn't an option when you run a small business (esp. IT/software-related) or a crowdfunding campaign.

</comment><comment><USER36> It's not the first time I have heard about them freezing funds - the last time was a few years back. From what I remember they were worried that the customers would ask for their money back if the product wasn't completed (explaining why they want to see a budget). This has nothing to do with fraud. They are allowed to do whatever they want with your money because they are not a bank.

It's completely ridiculous because participants in crowd funding are aware of the risks - they may never see their money's worth (even though that isn't the case here).

Either way, I would raise a massive stink if they don't buckle - I see you have a WIRED article, maybe approach them about writing about this encounter with PayPal. That's some pretty bad publicity right there. You may also be able to demand interest if they do continue to illegally with-hold the funds for that long (again, they are not a bank, but that means that this time they are not protected by those very same laws).

<comment><USER37> > It's completely ridiculous because participants in crowd funding are aware > of the risks - they may never see their money's worth (even though that > isn't the case here).

I wish I could agree, but the angry rants on a few Kickstarter projects show that many people see it as a "shop for things that haven't been built yet", rather than "give us some money, and we'll try to build these products, and if we do manage to build them you'll get one, but we could fail".

</comment></comment><comment><USER38> > _"... unless Mailpile provides PayPal with a detailed budgetary breakdown of > how we plan to use the donations from our crowd funding campaign they will > not release the block on my account for 1 year until we have shipped a 1.0 > version of our product."_

I'm a little confused by this. What crowd-sourced funds is PayPal withholding, as I thought that went via IndieGoGo? ( _answer: IndieGoGo uses PayPal_ )

What on earth does PayPal care about the financial planning of the recipient of the funds? This doesn't seem like it has anything to do with fraud detection.

<comment><USER39> > What on earth does PayPal care about the financial planning of the recipient > of the funds? This doesn't seem like it has anything to do with fraud > detection.

Because PayPal provides users with the option to ask for refund which can be very expensive for them. If they deem the risk is too high they won't do business with you.

<comment><USER40> It seems a bit late in the day to decide not to do business with you if they've already taken money on your behalf.

<comment><USER39> No further business. The money they have frozen they are holding in escrow to help the increased risk of refunds.

</comment></comment></comment></comment><comment><USER41> I am sorry this happened to you. As a consumer I used to love Paypal, buy anything with one click. After using them as a business owner for online transactions I absolutely hate them.

I won't go into my situation but the horror stories are endless:

[http://www.ripoffreport.com/reports/directory/paypal- inc](http://www.ripoffreport.com/reports/directory/paypal-inc) [http://www.paypalsucks.com/](http://www.paypalsucks.com/)

As a developer I won't use them anymore. I use Stripe now.

</comment><comment><USER42> This is not the first time Paypal did that [1] and it most certainly won't be the last time. That's one of the reasons Bitcoin was invented. I hope that events like this will drive its adoption as a safe alternative for crowd funding and online shopping.

[1] [http://www.gamesindustry.biz/articles/2013-04-23-skullgirls-...](http://www.gamesindustry.biz/articles/2013-04-23-skullgirls- funding-held-by-paypal) and probably there's more of this

<comment><USER43> Bitcoin ftw. Sure, not everybody can contribute in bitcoin. But on balance, bitcoin beats paypal by a factor of infinity. Why infinity? Well, with bitcoin you could at least have some contributions, i.e. > 0\. With paypal you get 0 contributions. (N>1)/0 = infinity.

<comment><USER44> > Sure, not everybody can contribute in bitcoin.

Why would anyone WANT to contribute in Bitcoin? From a contributor point of view, Bitcoin leaves them massively vulnerable to fraud--it is almost as bad as mailing an envelope full of cash.

<comment><USER45> They are crowdfunding a speculative application. That's already mailing envelopes of cash. Although the users read that they are funding development and not buying software, Paypal grabbed it all and said they're worried about fraud.

Bitcoin lets the user assert that they trust the recipient. Or they could trust a third party escrow recipient. There's no payment processor to restrict who a crowdfunder wishes to trust.

<comment><USER39> People that crowdfund often do not trust the project. PayPal probably flagged them because of cancellations.

</comment></comment></comment></comment></comment><comment><USER46> I believe the whole story and comments can be summed up as:

1\. People want paypal to act as a big dumb money pipe from point A to point B

2\. Paypal refuses to act as a big dumb money pipe from point A to point B when the risk is high that point A may want their money back, and paypal cannot shift the loss allocation to someone else.

3\. Their risk mitigation strategy in the case of #2, while not atypical of the industry, upsets a lot of people who are not familiar with this type of thing occurring, and seems "unfair".

</comment><comment><USER40> The problem here is that crowd-funding is a risky business and as things stand paypal has to shoulder that risk. What we need is a type of transaction where the payer/crowdfunder assumes the risk, i.e. chargebacks are not allowed.

<comment><USER47> Textbook Bitcoin.

<comment><USER48> Yes!

</comment></comment></comment><comment><USER49> Why do people still use PayPal? Their service is just absolutely insane.

<comment><USER50> Because indiegogo forces you to do it more ore or less.

Glad I didn't donate yet. If necessary I'll fly over and deliver it in person ;)

<comment><USER8> IndieGoGo actually support direct credit card donations, but a lot of people asked for PayPal as an option and we relented. So donating via. IGG actually works just fine - we have obviously disabled the PayPal option.

<comment><USER51> Wait... really? Because when the ubuntu phone campaign happened, I _wanted_ to buy one, and didn't purely because I couldn't figure out a way to do it without PayPal.

Did I miss something on the page that would have let me pay without it? Oh well; too late now I guess.

<comment><USER31> I was in the same boat as you with respect to the Ubuntu Edge, as it turns out each campaign can choose which payment services to use. Ubuntu chose to only enable PayPal.

</comment></comment></comment></comment></comment><comment><USER49> They will only release the funds when version 1.0 ships? Does PayPal not understand that it costs money to create products? That's the entire reasoning behind crowdfunding! 'Well you see this money you said you needed to make version 1.0 of the product? Well you can have it after you've finished'

<comment><USER52> > That's the entire reasoning behind crowdfunding!

They're not a crowdfunding service, they are a escrow service. The whole point of escrowing is that the service keeps the money safe until the transaction is completed (ie the buyer gets what she was buying).

<comment><USER53> I was under the impression that PayPal was a payment service. Party A uses it to send money to Party B and as long as no laws are broken, PayPal keeps its nose out of other people's business.

What makes you think PayPal is an escrow service akin to escrow.com?

<comment><USER54> It is an escrow service because it allows the buyer to reverse the transaction.

<comment><USER55> It wouldn't kill paypal to have non-reversible transactions as long as this is made clear to the user.

<comment><USER56> Paypal is just an intermediary between merchants and whatever payment methods customers use to pay Paypal, such as debit/credit cards and bank transfers. And guess what? The modern financial system has no irreversible payment methods. Bank transfers, credit cards, and ACH are all reversible, wherever you go around the world.

If you haven't heard of it before, the May Scale of Monetary Hardness is a great way of thinking about this: [http://stakeventures.com/articles/2012/03/07/the-may- scale-o...](http://stakeventures.com/articles/2012/03/07/the-may-scale-of- money-hardness-and-bitcoin) . If you're a payment intermediary, and you're delivering irreversible assets like gold coins or briefcases full of cash in exchange for very reversible payment methods like credit cards for personal checks, you will get horribly, horribly burnt by fraud, because you can deliver the gold coin and find out weeks later that your credit card was charged back. [http://whatilearnedtoday.jameslarisch.com/?action=view&url=b...](http://whatilearnedtoday.jameslarisch.com/?action=view&url=bitcoin- ebay-profit) is a great example of this with Bitcoin and Paypal respectively.

It's not even about educating the user about irreversible transactions -- it's just that there's no way for Paypal to offer them unless customers fund their Paypal purchases by dropping off briefcases of cash and gold bullion at their local Paypal branch.

<comment><USER55> Paypal already has a policy for dealing with users who reverse transactions out from under them. Unfortunately for the users, that policy is known as "scorched earth". We're talking account suspensions and referrals to collection agencies.

It would certainly be a lot less skeevy if it was done for a service-oriented reason (i.e. one way transactions) instead of the "because fuck you" reason that they appear to use currently.

</comment></comment></comment></comment></comment></comment></comment><comment><USER57> Paypal is unavoidable - there are just too much more money that can be made using Paypal because so many people use paypal and have positive balances at paypal and considering "paypal money" as "cheap money" \- which makes them easier to spend to buy or to donate.

Paypal is good when used for what it is good for - as a vessel to receive (and send) money easily. But no one ever said that Paypal is a great bank to keep money at.

There are simple rules of the game to avoid disasters like that:

The rules of using Paypal: transfer paypal balance to your bank account as soon as it reaches $500 or more. Once funds are transferred - transfer them to parallel bank account to keep them completely out of Paypal reach (as Paypal has full access to bank account connected to paypal account).

That's it.

Piling up cash at Paypal's account never been wise.

</comment><comment><USER58> Paypal doesn't understand that it isn't their money. Every contributor to Mailpile has just had their funds stolen by what was supposed to be a middleman.

<comment><USER59> Actually it is their money. Paypal is taking all of the risk in the transaction. If Mailpile fails to deliver, Paypal is on the hook. I see no problem with what they did, maybe this should have been communicated better.

</comment></comment><comment><USER60> There is very simple solution to all this!!!!!!

PayPal should have an "AT YOUR OWN RISK" payment option. Pre-sale vendors would be required by the terms of use to use this payment option instead of the normal one unless they first get a pre-sale waiver from PayPal. PayPal can charge an application fee for that process.

All done.

<comment><USER61> The problem is that chargebacks and disputes are happening at the level above Paypal (at the banks), and Paypal is just the merchant. And there is no way for merchants to make a sale and say "no chargebacks."

</comment></comment><comment><USER62> Anyone considering using PayPal as a seller should read Jessica Livingston's "Founders at Work" interview with Max Levchin. PayPal is an anti-fraud company that occasionally processes payments.

It's appealing to customers and established merchants with slow, predictable growth and short lead times, but not for pre-orders. And I don't see them changing this - it's in their DNA.

Kickstarter with Amazon Payments, in contrast and for better or worse, is the most pre-order friendly system imaginable. Tens of thousands to millions of dollars transferred in days with virtually no questions asked. The 14-day holding period they mention is only for first time projects.

</comment><comment><USER63> I have to worry about how crowd-funding is going to continue to break records and change businesses when there's such a huge communication issue. If there is a risk of charge-backs for an undelivered product, which there clearly is based on Paypal's reaction, then people are clearly viewing them as pre- orders. That's obviously what it has become, but for crowd-funding to really be reasonable for companies like Paypal, failed projects have to leave backers out of pocket and nobody else.

If crowd-funding is synonymous with pre-ordering a not yet available produce, I can't say I blame Paypal for wanting to keep out.

</comment><comment><USER64> Could it be that we've all missed the point entirely? Maybe, just maybe, Paypal was under duress from the Feds to cancel their Paypal account because they're afraid of what Mailpile would have accomplished?

</comment><comment><USER65> I assume this is to protect against chargebacks. If Mailpile were to empty their PayPal account and then buyers start requesting refunds for non-delivery of the described product, PayPal would be left holding the bag.

<comment><USER66> Well not exactly.

Recently I sold a bunch of hardware on eBay. Took photos of it being packaged, photos of it at the post office, added express shipping and a tracking number. The tracking number says delivered, so I withdrew the funds back to my bank account. Next thing I know, PayPal debited my account for the full amount because the buyer filed a non-delivered complaint.

End story is, PayPal doesn't leave themselves with no options for recourse.

(I'm still fighting that one)

<comment><USER65> In Mailpile's case, there must be a higher risk that their linked account doesn't have $100,000 for PayPal to back out.

The same could be said for your situation, but I'm assuming the liability is lower due to the amount.

Edit: That's not quite right since $100,000 represents a collective amount, not individual buyers demanding a refund.

<comment><USER66> I certainly didn't have $250 in that account, which of course added a $50 overdraft fee. One would assume that they didn't spend all their money at once, so paypal would be able to suck back at least some of it.

</comment></comment></comment></comment><comment><USER67> I feel kind of bad about the fact that they initially didn't enable paypal donations, but enabled them a few hours after I suggested they do. I might be responsible.

My own smaller (16k) indiegogo campaign went completely over paypal without a hitch [1]. Probably the fact that my paypal account has been seeing relatively large transaction volumes for years also helped prevent the alarm algorithm from triggering on it.

[1]: [http://www.indiegogo.com/projects/tern-intelligent- javascrip...](http://www.indiegogo.com/projects/tern-intelligent-javascript- editing)

</comment><comment><USER68> There is another angle to this: PayPal needs to make sure this money actually goes to a legitimate business, instead of some trick of money laundering. From PayPal's perspective, it has a hard time to differentiate this without details on what you claim you are going to do.

If you have concern about PayPal knowing your plan and thus cause impact to your business plan, my thought will be if your business plan is so flimsy and fragile, how much confidence you are having? Same goes to if you have concerns of other people knowing and thus pilfering your ideas.

</comment><comment><USER69> It's a complex question. Easy for Mailpile if they want to go to war about it. Start a new direct campaign somewhere else and tell their previous givers to request a charge-back.

PP acting in its role in indemnifying buyers here, which is understandable, but it really isn't appropriate for them to pass judgement on MP business plans.

Free market will sort this out anyway. IGG or givers will go to another platform if PP is seen as unreasonable. Few are going to go thru the trouble of a campaign if PP is constantly holding back the funds.

</comment><comment><USER70> So we keep reading this kind of thing on Paypal. Are there any viable alternatives for consumers? As a company you could use Stripe or Paymill (for Europe), but as a consumer the only alternative is to pull out a credit card when I buy games on Steam. I don't want to do this, I want a login for a payment provider that is coupled to my bank account. I don't want to walk around with my credit card as it is too unsafe (something that Americans probably don't understand).

</comment><comment><USER71> > ... freedom to maintain your vision unbeholden to shareholders and 3rd > parties.

Aye, there's the rub. Many of us want that freedom, but it's rare. Powerful people are generally quite beholden to third parties.

The president of the US can't do whatever he wants; neither can the CEO of Google.

In order to make our dreams real, we must communicate them in common language to stakeholders, a process which may flatten them and drain their magic.

</comment><comment><USER72> Sorry, Indiegogo - I will _never_ use you for a crowdfunding campaign after seeing what Paypal does!

I'll use Kickstarter, who uses Amazon Payments.

</comment><comment><USER27>
      Paypal: If you presale we might freeze your account
      Merchant does presale
      Paypal freezes account
      Merchant: Why you did that?

<comment><USER13> It's pretty ridiculous that IndieGogo allow PayPal for their campaigns when it's pretty much against the PayPal ToS.

</comment></comment><comment><USER73> And...another group of people new to running a business find that the business side of things can be challenging and time-consuming.

</comment><comment><USER74> How many horror stories do you have to hear until you don't use paypal and don't use anything that uses paypal?

</comment><comment><USER75> seems like paypal CEO David Marcus is looking in to it.

Whenever there is a high profile case like this that gets a lot of public attention he seems to get involved [https://twitter.com/davidmarcus/status/375621484175060993](https://twitter.com/davidmarcus/status/375621484175060993)

</comment><comment><USER76> Avoid Paypal as often as you can, simple as that. I am forced to use them for certain transactions, but anytime I can avoid them I do. I hate that they force me to verify my account, they force you to use Paypal credit (if you have it) instead of a CC, etc. I really don't like their one-sided policies...

<comment><USER77> >Force you to use Paypal credit (if you have it) instead of a CC

What's so bad about that?

<comment><USER76> Sometimes I receive payment for one task and I need to pay for a service or product with another credit card. Say I have $1500 paypal credit from one of my businesses, and want to pay a $500 charge from a certain credit card. I am not able to do that without first withdrawing the money. It's beyond annoying, just let me pay with the funding source I want.

</comment></comment></comment><comment><USER78> I wonder if Elon Musk cares at all that a service he created, one that made him incredibly wealthy, is so willfully abusive and corrupt. How about Pierre Omidyar or John Donahue?

PayPal really needs to be investigated by federal governments, and put under strict oversight, regulations and controls.

</comment><comment><USER79> Apparently PayPal has reached out and unfroze the funds.

[http://arstechnica.com/business/2013/09/paypal- freezes-45000...](http://arstechnica.com/business/2013/09/paypal- freezes-45000-of-mailpiles-crowdfunded-dollars/)

</comment><comment><USER80> this doesn't surprise me in the least.

reading the comments, this thread is turning into a paypal bashing which it shouldn't. what happened is not paypal's fault or some insider attempt at stopping the project from happening as some laughable comments have suggested.

paypal's top priority is to their customers, not the merchant. if you look at this from their perspective this is the right move as what would happen if the project just took the money and never delivered?

asking them for a detailed list of `itemized budget and your development goal dates for your project` is something that any smart investor would ask for and they should have had this done already so i don't see why this is cause for concern.

</comment><comment><USER81> It's funny at the same time paypal still let extorsion websites use its services: [https://news.ycombinator.com/item?id=6328480](https://news.ycombinator.com/item?id=6328480)

</comment><comment><USER82> Paypal is well-known for this kind of behaviour. Search relevant terms through HN and various tech conferences have had issues with freezing and no warning and zero accountability and customer service.

</comment><comment> johnx123-up Can anybody explain... if using turnkey crowdfunding scripts like Agriya will help here? My previous company used Agriya and didn't face any issues from paypal. So just checking..

<comment><USER83> No, nothing will help. If PayPal discovers that you are doing crowdfunding they will freeze your money forever. Some people got away with it because PayPal didn't notice them, but you can't predict that PayPal will not notice you in the future.

</comment></comment><comment><USER84> Some things never change - even when a new executive promises.

</comment><comment><USER85> I've always wondered why this policy is in place. Is it just to screw people over or is there some legitimate use? Are they trying to prevent money laundering?

<comment><USER86> I think they do have to contend with legitimate fraud, and their automated systems simply can't deal with a true FOSS project where the people donating know precisely what they're getting into, and the developers are obviously not some gang from Nigeria

</comment></comment><comment><USER87> It's amazing to me how revered the PayPal mafia is and continues to be despite all the detestation that continues to be heaped up PayPay, the company.

</comment><comment><USER88> I see that nothing has changed, even with the new CEO that promised us Paypal would have more reasonable policies in the future.

</comment><comment><USER89> Don't use PayPal for pre-orders.

</comment><comment><USER90> Hmm.. This does not sound good. Hope it will resolve it self. Maybe a founder to founder call is in place.

</comment><comment><USER91> That's Shitpal for you

</comment><comment><USER92> Shoulda taken bitcoins.

</comment><comment><USER93> son of bitches!

</comment><comment><USER94> As I read this post, I felt a brief rush of anxiety wondering if I backed this project. I hoped not. These guys come off as rather flippant with other people's money.

</comment><comment><USER52> SURPRISE!

</comment><comment><USER95> Mailpile is about encrypted email that NSA may not be able to access. Mailpile also referred to Edward Snowden in their indiegogo campaign. Mailpile also accepts bitcoin payments. Do you need anymore reasons to why this happened ???

<comment><USER96> Get real.

<comment><USER97> It's not without precedent to see payment systems leaned on to disable their clients. This is a shiny new webmail client with a focus on encryption, but these shady groups probably aren't attacking projects this early in their life... probably.

<comment><USER98> True, and given the amount of economic and legal pressure the government has proven itself willing to apply to preserve its surveillance capabilities, I'm not sure why people think it's out of the question in this case. We haven't seen it yet for early-stage projects, but this one's gotten a fair amount of press and donations.

It may seem more likely that PayPal froze the account due to discomfort with crowdfunding, but the question then is how many other campaigns have they done this with. Since Indiegogo still uses them, it seems the answer must be "not many."</comment></comment></comment></comment>


Why there's nothing special about the business of software - <AUTHOR> http://blog.businessofsoftware.org/2009/05/why-theres-nothing-special-about-the-business-of-software.html <comment><USER3> Ok, I just had to... I got the data from here: [http://money.cnn.com/magazines/fortune/global500/2008/full_l...](http://money.cnn.com/magazines/fortune/global500/2008/full_list/)

And, I pseudo-randomly sampled companies that interested me.

Walmart _Revenue_ : $378 B _Profit_ : $12 B _Employees_ : 2055 K _Revenue_ per employee: $183 K _Profit_ per employee: $5 K

Exxon _Revenue_ : $372 B _Profit_ : $40 B _Employees_ : 107 K _Revenue_ per employee: $3476 K _Profit_ per employee: $373 K

ING Group _Revenue_ : $201 B _Profit_ : $12 B _Employees_ : 120 K _Revenue_ per employee: $1675 K _Profit_ per employee: $100 K

GM _Revenue_ : $182 B _Profit_ : $-38 B _Employees_ : 266 K _Revenue_ per employee: $684 K _Profit_ per employee: $-143 K

Ford _Revenue_ : $172 B _Profit_ : $-2 B _Employees_ : 246 K _Revenue_ per employee: $699 K _Profit_ per employee: $-9 K

Citigroup _Revenue_ : $159 B _Profit_ : $3 B _Employees_ : 380 K _Revenue_ per employee: $418 K _Profit_ per employee: $7 K

At&T _Revenue_ : $118 B _Profit_ : $11 B _Employees_ : 309 K _Revenue_ per employee: $381 K _Profit_ per employee: $35 K

Samsung _Revenue_ : $106 B _Profit_ : $7.9 B _Employees_ : 144 K _Revenue_ per employee: $736 K _Profit_ per employee: $55 K

IBM _Revenue_ : $98 B _Profit_ : $10 B _Employees_ : 386 K _Revenue_ per employee: $253 K _Profit_ per employee: $25 K

Nestle _Revenue_ : $89 B _Profit_ : $8 B _Employees_ : 276 K _Revenue_ per employee: $322 K _Profit_ per employee: $28 K

Cardinal Health _Revenue_ : $88 B _Profit_ : $1.9 B _Employees_ : 43 K _Revenue_ per employee: $2046 K _Profit_ per employee: $44 K

Sony _Revenue_ : $77 B _Profit_ : $3.2 B _Employees_ : 180 K _Revenue_ per employee: $427 K _Profit_ per employee: $18 K

Costco _Revenue_ : $64 B _Profit_ : $1 B _Employees_ : 98.5 K _Revenue_ per employee: $650 K _Profit_ per employee: $10 K

Microsoft _Revenue_ : $51 B _Profit_ : $14 B _Employees_ : 79 K _Revenue_ per employee: $645 K _Profit_ per employee: $177 K

Oracle _Revenue_ : $17.9 B _Profit_ : $4 B _Employees_ : 64.6 K _Revenue_ per employee: $277 K _Profit_ per employee: $62 K

Cisco _Revenue_ : $34.9 B _Profit_ : $7.3 B _Employees_ : 61 K _Revenue_ per employee: $572 K _Profit_ per employee: $120 K

Coca Cola _Revenue_ : $28.8 B _Profit_ : $5.9 B _Employees_ : 90 K _Revenue_ per employee: $320 K _Profit_ per employee: $66 K

TIAA-CREF _Revenue_ : $27.5 B _Profit_ : $1.4 B _Employees_ : 7.5 K _Revenue_ per employee: $3667 K _Profit_ per employee: $187 K

Apple _Revenue_ : $24 B _Profit_ : $3.4 B _Employees_ : 22.6 K _Revenue_ per employee: $1062 K _Profit_ per employee: $150 K

<comment><USER4> Software or Oil. Those are the two businesses to be in - that's what the table says.

Personally, I would like my own country/principality (like Monaco or San Marino, maybe in the Caribbean) where everyone was involved in a software company, or services supporting software companies. I'd have a zero tax policy for software companies but the government automatically got 3% equity for all companies based there. Everyone would have free high speed internet and there'd be a free research university for students who passed the entrance exams.

Now, who wants to come and live in my country?

<comment><USER5> Only cause finance wasn't listed.

<comment><USER3> Actually, there were plenty of finance companies that I glossed over. Most of them took a beating this past year, so I didn't include them.

</comment></comment></comment></comment><comment><USER6> Profit per employee would be more interesting.

Even more interesting: salary per employee (not only for its meaning to employees but to the local economy.

</comment><comment><USER7> IIRC (this was discussed on the "free software business" email list a number of years back), Microsoft and possibly Autodesk are the _only_ major software companies that actually get the vast majority of their revenue from selling, well, software. Every other large company that is generally thought of as "selling software" also sells consulting services or hardware or some other complementary good.

</comment><comment><USER8> None of these companies are trying to maximize profit-per-employee, just profit. There's obviously a diminishing return with each subsequent employee, but that's no deterrent for larger companies. It's pretty reasonable that healthy companies will have per-employee profits around the average salary: if a current employee "pays" for a new employee, there's no real reason not to hire one.

If you search for software companies that _do_ try to maximize their per- employee profit, you find companies like 37Signals and id software, which I imagine are at least an order of magnitude above any other organization that's been mentioned. They're what make the business of software special, not Microsoft and Google.

</comment><comment><USER9> Revenue per employee seems like a ridiculously meaningless statistic. It tells you nothing.

Total revenue can be useful. Total Profit can be useful. Profit per employee can be useful. Loss per employee is useful.

Revenue per employee is half the story. This is how you run your business into the ground - Believing half stories.

</comment><comment><USER10> Wow, that seems low. Even more reasons to work on a startup.

</comment><comment><USER11> Hmm. I have stuff to do so I can't follow up but I'm really dubious. Note this after the chart: _General Motors has revenue of $600,000 per employee_. GM? OHRLY?

Perhaps the author conflates revenue and profit?

Edit: in fact, the author actually notes this. Which makes the whole exercise stupid: If you don't have the data you need, you don't have the data you need and using the maximum value instead is useless. As should have been trivially obvious at the time the author wrote the blog post by examining one of his or her own examples.

<comment><USER12> I think it's worth noting how many of the world's top ten (or 20 or 50, etc.) richest people who earned it, rather than inheriting it, got there with software.

Gates, Ballmer, Allen, Brin, Page, Ellison, etc. There are plenty of others, of course, who didn't get there with software. But the numbers certainly make it seem like software is a good way to get fantastically wealthy.

<comment><USER13> What most people forget that the worlds 50 richest people are outliers - <USER2> all there are only 50 of them in the world. The interesting thing would be to see how big a percentage of the worlds richest 5 million people made their money by creating and selling software.

I'm not saying that you're wrong, just that the data doesn't support the view.

<comment><USER12> That's true. I suspect oil has made dramatically more millionaires and billionaires than software has (but, having lived for many years in Texas, having a dad that worked as an engineer in the oil and gas industry, and then working myself for a few years on software for the oil and gas industry, my view of rich people and how they got that way may be skewed). But, I think maybe we're past the time when there are major opportunities for new people to make their fortune in oil. Though I do know some software developers who're rich because of the software they make for the oil and gas industry.

Anyway, I don't know, either. We're all working with dramatically less data than we need to make an informed decision.

But, since we're probably all strongest at technical stuff, rather than finance or arbitrage or whatever other ways folks make a billion dollars, I kinda think our best odds are in playing to our strengths.

<comment><USER14> If you read the book Millionaires Next Door they pretty much tackle this problem and show that owners of small->medium sized businesses are the bulk of the millionaires. A lot of these businesses are just run of the mill things like construction, commercial real estate, service stations etc. The home runs from taking huge risks are few and far between.

<comment><USER12> _The Millionaire Next Door_ also reportedly has data problems, but, I think the idea of becoming one of those millionaires next door from software is also sound. I think the risks that have to be taken for those home runs in software are smaller, as well. What's the cost of a major construction project that can net millions in revenue vs. a major software project that can net millions in revenue?

I was just think we're pretty lucky (or clever) to be working in a field that has produced so many billionaires in a short period of time, and now requires less risk and investment than ever before. It's a good time to be a nerd.</comment></comment></comment></comment></comment></comment>


INTEL-SA-00075 – AMT Linux Detection and Mitigation Tools - <AUTHOR> https://downloadcenter.intel.com/download/26799/INTEL-SA-00075-Linux-Detection-and-Mitigation-Tools?product=23549 <comment><USER3> Looks like it does roughly the same thing as this [1]. I guess it's a tossup between a proprietary program from Intel or a free program on github from the person who found the bug.

[1] [https://news.ycombinator.com/item?id=14335159](https://news.ycombinator.com/item?id=14335159)

<comment><USER4> For what it is worth I think Maksim Malyutin from Embedi was the person that found the bug. MJG is the author of the check.

<comment><USER3> My mistake. I mistook his blog post discussing it [1] for an initial announcement of it, even though it links to an Intel announcement.

[https://mjg59.dreamwidth.org/48429.html](https://mjg59.dreamwidth.org/48429.html)

</comment></comment></comment><comment><USER5> Something security-related to keep in mind (TL;DR at end):

Directory state after initial unpack (becomes important in a minute):

      -rwxr-xr-x 1 i336 users 19K May 13 10:43 INTEL-SA-00075-Discovery-Tool
      -rw-r--r-- 1 i336 users 27K May 13 10:57 INTEL-SA-00075-Discovery-Tool.c
      -rwxr-xr-x 1 i336 users 15K May 13 10:44 INTEL-SA-00075-Unprovisioning-Tool
      -rw-r--r-- 1 i336 users 16K May 13 10:42 INTEL-SA-00075-Unprovisioning-Tool.c
      -rw-r--r-- 1 i336 users 187 May 13 10:42 Makefile

Build:

      $ cd INTEL-SA-00075-Discovery-Unprovisioning-Tool-Engineering-Release
      $ make
      gcc -I../../usr/include    INTEL-SA-00075-Discovery-Tool.c   -o INTEL-SA-00075-Discovery-Tool
      strip INTEL-SA-00075-Discovery-Tool INTEL-SA-00075-Unprovisioning-Tool
      $

OK; wipe and do it again:

      $ rm INTEL-SA-00075-Discovery-Tool INTEL-SA-00075-Unprovisioning-Tool
      $ make
      gcc -I../../usr/include    INTEL-SA-00075-Discovery-Tool.c   -o INTEL-SA-00075-Discovery-Tool
      gcc -I../../usr/include    INTEL-SA-00075-Unprovisioning-Tool.c   -o INTEL-SA-00075-Unprovisioning-Tool
      strip INTEL-SA-00075-Discovery-Tool INTEL-SA-00075-Unprovisioning-Tool
      $

Wait - why did the unprovisioning tool only get compiled on the second build?

Because the binary for the unprovisioning tool is _two minutes NEWER_ than the source code, as shown in the directory listing.

The binary for the discovery tool is older than the source (as normal).

Objectively it's 50/50 as to whether this is meaningless noise or something hidden. Of course everything points toward the former, but I thought I'd leave this here just in case.

It's worth noting that an independent security company rapidly found (and announced) the vulnerability after the initial undisclosed CVE. So if it was that easy, this vulnerability has clearly been known about in various circles for a while.

It's also worth noting that the build process strips the binary, which is arguably unnecessary, but is a nice way to explain why there are no debug symbols in the provided binaries.

Again, I trust Intel and can easily talk this away as the inanites of bureaucracy and management and deadlines, but my "hmmm" sense is tingling nonetheless.

<comment><USER6> I'm not even sure what you're implying.

EDIT: Is it that we should build it ourselves, and not trust the binaries?

EDIT 2: Well, whatever it is, I moved away the binaries and just built it again myself. It was trivial; just type `make` and it's instantly there. (I guess you need gcc and stuff)

<comment><USER5> Sorry, I was in a bit of a rush when I made the above comment - you're right, I could have worded it a little more clearly.

I don't have `ls` colorization enabled on this laptop, so I didn't immediately notice the binaries next to the source code; the first thing I noticed was the Makefile. So I just ran "make" to see what would happen.

By the time make was done my eyes had noticed the two different tools - <USER2> the fact that only one of them had rebuilt. So I freaked out, probably completely unnecessarily.

Essentially what I was thinking was, why is the unprovisioning tool binary that got copied into the distribution newer than the associated source code? How does that work?

The only scenario I can come up with is that a build server was mounted via NFS to the developer machine that prepared the source code, and the local machine's clock was a bit fast. If gcc was being run on the build server, that would produce an binary older than source.

However that does not explain why only the unprovisioning tool was affected in this way, and not the discovery tool (binaries are supplied for both).

Honestly, I'm probably barking up the wrong tree, and I kind of feel silly for posting the comment in the first place. I just wonder, that's all - it makes sense for the discovery tool to remain untouched, with the mitigation tool (the "off" switch) to be tinkered with (somehow).

As for what I'm implying, the worst-case scenario would be some kind of situation where the supplied binary version of tool "all bit completely" disables AMT, somehow leaving one tiny thing in a state where some later process can silently re-enable everything, or otherwise get access to the system. Maybe. Somehow. I have no idea.

</comment></comment></comment><comment><USER6> Thankfully it comes from an https connection on downloadmirror.intel.com. But there's no md5 sha1sum or sha256sum posted anywhere else. For whatever it's worth this is what I got:

INTEL-SA-00075-Linux-Detection-and-Mitigation-Tools-v1.1.zip

md5: a4645f80a0d573a8345545954d8da8ed

sha1: 600ca16f9530dd9069b42e9696b0ea772eb059f0

sha256: 808620dd939bd3011c689eb8f4f56d92195159fd5cab570dd86598c68dd7ec63

</comment><comment><USER7> This is weird: this tool says my laptop is vulnerable, although AMT is disabled. I also tried mjg59's mei-amt-check and it indicated that because my system is unprovisioned it was not vulnerable.

<comment><USER8> There's a second bug that allows a local, non privileged user to provision AMT.

<comment><USER9> This is the role of Intel's LMS -- Local Manageability Service.

As I understand it from having to check for / disable the AMT vulnerability on a Linux machine and then on a Windows 10 machine:

With AMT available but unprovisioned, the LMS vulnerability can be used to invoke LMS to provision AMT. Once provisioned, AMT can then be used to exploit the system.

Intel's language that I've seen solely refers to LMS in the Windows context. Even with AMT unprovisioned, a Windows machine may well have the LMS service running.

Intel's mitigation instructions for the problem describe two steps: 1) Getting AMT unprovisioned; 2) Disabling the LMS service so that it can't be exploited to enable/provision AMT.

Step 2) is further complicated in that, in addition to LMS, there is also a "microLMS" service that is an independent substitute for LMS and can or may possibly be used in lieu of it to provision AMT and gain access. I didn't look further, yet, but the bit of description they threw at "microLMS" described it as an "open-source" LMS substitute.

Most all the language I saw around LMS described it in the Windows context. I have a somewhat vague niggling in my mind that at least somewhere, I saw a description -- maybe -- of a Linux version or driver in the kernel or whatever. Unless I'm confusing that with the Linux AMT support that is of concern.

The open ports in question with regard to this functionality appear to relate to both AMT and LMS. Even if AMT is unprovisioned, LMS may have some of those ports open and ready to communicate.

So, after I went through steps to disable AMT -- and LMS, on the Windows 10 PC -- I repeated my scan of the relevant port ranges using nmap, from another machine, to check that they weren't responding. nmap -v -a -p600-699 [ip4 address] _and_ nmap -v -a -p16900-16999 [ip4 address] . -v for verbose, -a for aggressive (why not?), and port ranges -- the last a bit over-broad, for the sake of my aging memory...

By the way, on the Windows 10 machine I had to deal with, Intel's vulnerability scanner initially found AMT available but unprovisioned, LMS running, and microLMS not running.

After went through Steps 1) and 2), rerunning their vulnerability scanner showed AMT unprovisioned (as before) LMS not running, but now microLMS running. WTF -- why did it apparently kick in upon these changes?

The relevant ports as cited here and there in all the news about this, were all unresponsive to nmap scanning. And it was 2 am by that point.

But I'm left wondering what microLMS is up to, and whether it's listening on some other port(s).

Unfortunately, Windows 10 doesn't take well to nmap -v -a -p- [ip4 address] -- namely, expanding the former scan to encompass all ports, and starts choking the response rate. 2 am, and as I didn't want to wait who knows how long to get through that scan, I shut down the machine and left it, for the night.

Anyone else know more about microLMS... Now that I'm remembering and maybe have the energy to look into it, myself?

P.S. Since Intel's ME sits before the main processor running the OS and can intercept network packets ahead of it, from the NIC [a], you need to scan for the vulnerable ports from another device on the (local) network.

If you are somewhere where you don't have multiple PC's at hand, on an Android phone, the Termux app has nmap 7.40 in its repositories and this works just fine to perform the scan in question.

a) It is precisely those packets it intercepts and does not pass on to the OS, that are of interest.</comment></comment></comment>


"Proof" that Fuchsia will replace Linux for Google - <AUTHOR> https://techspecs.blog/blog/2017/2/15/proof <comment><USER2> I'm sorry but his "proof" is mostly just puns. Sometimes OSS projects are given pun names simply for laughs, not because of some deeper meaning. No doubt Google is researching new OSs, View Managers and development frameworks. (Every company that large does.) But I think it's too early to call it a potential successor; architecture takes a long time to change.

<comment><AUTHOR> [https://disq.us/url?url=https%3A%2F%2Ftwitter.com%2Fchrismck...](https://disq.us/url?url=https%3A%2F%2Ftwitter.com%2Fchrismckillop%2Fstatus%2F765438910658772992%3Al4L8Nx5RcZzAgmYMsPZIK3PRzoU&cuid=1370072)

<comment><USER3> You posted a link to a protected tweet that nobody can read with no summary or context.

<comment><USER4> It's not protected, I could read it and I don't even have a twitter account.

> @chrismckillop: Slow news week? [http://www.cnet.com/videos/googles- > mysterious-new-project-fu...](http://www.cnet.com/videos/googles-mysterious- > new-project-fuchsia/) … #Fuchsia

> @gavkar: @chrismckillop heard Travis was involved. Is the purple in pink + > purple the purple we know?

> @chrismckillop: @gavkar Yes and Yes (in spirit). The Pink part is also a > reference to the Taligent project. You should come help. :)

Here's the URL without the disqus tracker: [https://twitter.com/chrismckillop/status/765438910658772992](https://twitter.com/chrismckillop/status/765438910658772992)

<comment><USER5> and what does this prove, exactly?

<comment><USER4> It proves that the tweet was not protected?

</comment></comment></comment></comment></comment></comment><comment><USER6> I find it hard to believe that 8+ years of APIs and OS level code would be abandoned just like that, especially given the scale of Android.

If this ever happens, it would probably be an extremely slow, well thought out (hopefully), well documented (also hopefully) rollout.

<comment><USER7> They've already replaced Dalvik with ART for bytecode and it was mostly transparent from what I understood.

But popping up with a completely new platform API without any backwards compatibility would be very bold and risky. There would have to be a good compatibility story there.

Also there is talk in the article about a POSIX layer. Now that's easier said than done. But it is Google we are talking about so they certainly have the manpower and resources to try.

<comment><USER6> A new runtime is very different then a new framework/API/OS. The former doesn't necessarily require code changes (dalvik -> ART did not), the latter requires new everything.

<comment><AUTHOR> The Android API wouldn't be going anywhere. That's what I say in the article - Fuchsia would continue to support the Android API seamlessly.

</comment></comment></comment></comment><comment><USER8> It was pretty obvious for some time, but it's good that the dots are connected and documented, for some kind of proof. Fuchsia OS will be huge, even if it's hidden in the background.

Samsung has its Tizen OS (previously Bada) for 6 years as alternative ready. If anything happens with Android that Samsung doesn't like the could ship new devices simply with Tizen and kiss Google good bye. It allowed them to get better agreements. I wonder why Samsung waited that long, they had a near monopoly around 2012 with Android devices, now several new chinese players entered the market.

Samsung TV and Gear, and some phones run already on Tizen and some older on Bada. (Tizen is Linux based, it's history is complex and some involvement was also from Intel and Nokia (before the MSFT inside job)).

<comment><USER9> Have you used Tizen at all? How do you like it, if so?

<comment><USER5> The first iteration was not very impressive, but has since steadily improved.

If I had to choose between Android+Fuchsia and Tizen+Linux I might as well give Tizen a try. I am very impressed by their new watch, which IIRC runs Tizen.

</comment></comment></comment><comment><USER10> That wasn't coherent at all. The only pieces of evidence are flimsy at best and then there is a shit ton of speculation.

</comment><comment><USER11> Again this blog? Seems we have also fake news problems here on HN. This is all fairy tale speculating for me. And I don't believe his sources.

And btw: Tizen is also based on Linux. You don't build that easy a Kernel replacement.

<comment><USER12> That's not what 'fake news' means. It's perfectly clear the piece is speculative and it does not intentionally deceive (even if it turns out to be completely wrong).

<comment><USER13> The title is "Proof". The url has "proof". Not only is that a misleading click-baitey title, it is also false, because there is no proof.

<comment><USER12> It's in quotes. It even talks about the quotes. It's obvious from the tone of the thing it's not presented as real proof. And again, "I don't like the title" is not what makes "fake news".

<comment><USER13> Well this is quite a silly discussion then. If the author is using a title to mean something other than the words in the title in a manner such that the author still protects the veracity of the title, then what is the point of the title? All I can tell it is just a clickbait title.

And then I read the article and see that it is a bunch of speculation and making inferences from puns.

<comment><USER12> I don't think it's a great article or that great a title. But the fact that it's speculation is completely obvious. And that bit of punctuation is used to change the literal meaning of words, yes. It's just how English works.

</comment></comment></comment></comment></comment></comment><comment><USER14> I thought google would do something like this. They didn't want to fully embrace linux so they locked all the freedom of linux away behind restrictrions in android until they had a replacement and now they are going to try to drop gnu+linux anything GPL they can...

The new kernel is MIT/BSD... Welcome to Tivoization all over again.

I get the need for a better kernel, the gnu+linux kernel is out of control at over 14mil+loc, but why not put that effort into making a minix3 style microkernel that's gpl, or fix hurd?

I wish people understood the dangers of BSD style licenses, I hope this fails, the last thing we need is another proprietary OS on a device they built on the backs of the FOSS community but doesn't give back in a meaningful way.

We don't need another OSX, or _android apps on your PC_ , we need someone with the money and will to fix the future of GNU!

<comment><USER15> I don't understand the dangers of BSD style licenses, can you expand on that a bit please?

<comment><USER16> The "danger" is BSD licenses are highly permissive, you can take BSD licensed software, modify it and sell it and never return the changes to the community or release the source to customers.

This means all the work of the OSS community is 'free' for corporations to take.

<comment><USER17> So basically, if _you_ make some improvements to something, _you_ get to control those improvements. What a horrible idea that is.

Note: this is clearly sarcasm, and it pains me that I need to put this here, but some won't get it.

<comment><USER18> Considering it doesn't sustain the free software you needed to improve in the first place, yes, that is a terrible idea.

</comment></comment></comment></comment></comment><comment><USER19> Will it be lightweight ? Will it have a shell ? Will it be customizable ? Will it have loads of third party applications ? Will it support non-Google hardware ? Will it finally bring serious OS innovation to the consumer desktop market ? Here is to hoping yes!

</comment><comment><USER20> Doesn't putting "Proof" in quotes immediately disqualify it from being a proof?

<comment><USER13> No. Putting quotes around a word could mean a whole bunch of things.

</comment></comment><comment><USER21> "reached out" in the first sentence. That saved me some time!

</comment><comment><USER22> Googlers reach out him and confirm his guess is largely right? I can't believe it. The Googlers, please reach me and tell whatever you told the author. I can sign you an NDA.</comment>


Cash-strapped teacher sells ads on tests - <AUTHOR> http://www.cnn.com/2008/LIVING/12/03/teacher.ads.on.tests/index.html

<comment><USER2> This is a great article, but it was just posted to HN yesterday from USNews as well

<http://news.ycombinator.com/item?id=383723>

[http://www.usatoday.com/news/education/2008-12-01-test- ads_N...](http://www.usatoday.com/news/education/2008-12-01-test-ads_N.htm)

I am voting it up though, because I wonder if this is a problem we could solve here with this group. I doubt that this was duplicate posted maliciously, and it is an interesting story

I wonder if it would be useful to have a feature where rather than just "bury" or "mark as duplicate" we could link TO the original duplicated story. Since I _know_ it was posted recently, and made front page, I would go through the effort of tagging it as such and linking (as I have just done). Perhaps then this "new" post would appear as a comment in the original thread?

If this (what I'm doing) is an inappropriate use of comments and voting, I apologize - I didn't want to post a whole new "Ask HN" about it.</comment>