With many freemium services capping free accounts at single-digit numbers of users, "no limit" is a reasonable way to let people know that they can stop looking for the catch. It would be more confusing if they said "up to 5,000" users, which sends the wrong message about who their service is targeting.
Everyone understands that "unlimited breadsticks" implicitly means "lots and lots but not infinitely many"
Do you work for AT&T? Unlimited means unlimited. If there are limits, they need to be disclosed in advance. Especially if you are explicitly claiming that there are no limits..
That's a crock. Please show me one other service that explicitly states "no limit" that actually has a hidden limit. The 10,000 message search limit makes it mostly unusable for groups in the 100s or even 10s so why even enforce the user limit?
www.hostgator.com - unlimited disk and bandwidth. Never truly unlimited.
They limit the types of content you can host (no media sites), they set inode limits (http://support.hostgator.com/articles/pre-sales-policies/rul...), they will suspend you if you use too much server resources. Pretty much anything to keep you from using "unlimited" resources.
There are a ton of other examples. I would check out www.webhostingtalk.com if you want to see all the issues with these type of hosts.
They do explain that other limits make it essentially impossible to actually utilize "unlimited disk/bandwidth". And they don't mention unlimited on the home page. But fair enough, you found one.
I authored this blog post. There is a lot of merit to your criticisms of my decision making.
I want to point out that communities are increasingly using Slack, and many of them are also in the thousands of users. Slack does nothing to discourage this, aside from posting warnings about archiving messages.
The real problem is that they have an undocumented user limit. Like I said, I'm pretty sure we're the first community to hit this limit.
Big online courses, for example, routinely draw 100,000s of students, and might make the same mistake we did (Harvard's CS50 class did).
Slack may be able to fix its sluggishness for these other communities, and someone might build integrations that routinely export then delete messages so as to stay below the 10,000 message limit and remove the warnings. But it's too late for us. We can't pause our community growth while we wait for Slack to engineer around their undisclosed user limit. So we have no alternative but to switch.
The main reason I wrote this post is to provide a cautionary tale to other open-membership organizations who are considering using Slack. Slack doesn't seem to be intended to do this! Please don't do this!
I might be misreading the post, but my interpretation was that the audience is other large communities, MOOCs, and other loosely affiliated organizations that may want to try Slack, not the Slack team itself. They're providing useful information for the former, particularly if several other organizations have made similar mistakes.
The post certainly seems to attempt to lay blame on Slack. If their goal were just to educate large communities, it would be titled something like "What Slack isn't good for."
Most 'unlimited' things still have some max. Using a BIGINT for your primary key will get you a max of 18446744073709551615. Should we complain that we can't go higher in any application that uses one of these?
Slack's advertisement for unlimited users was based on their product's design. Their hard limit is perfectly reasonable because the interface wasn't really designed to handle 10k users in the first place.
To complain about this is like buying a sailboat and complaining when you sail it into a hurricane.
You seem to be missing the point. I'm saying there's literally NO application that claims 'unlimited' that doesn't actually have SOME limit. There are always going to be technical limitations. Even if it's unlimited in practice (as in, no customer will ever reach the limit we've set) there is going to be SOME limit.
Marketing materials are designed to show the intended audience how they may use something. Slack was created for use by teams, teams that know each other and that need to collaborate. Within that context, a limit of 10000 users is pretty reasonable because it IS 'unlimited' for their target audience who will never need 10000 accounts.
Again, the sailboat analogy. I was sold on my sailboat being 'seaworthy'. Does that mean it can literally handle anything the sea throws at it? No. It's a label used to show the target audience how they may use it. If I choose to sail into conditions it wasn't designed to handle, it isn't the builder's fault, it's mine.
I'm OK with "effectively unlimited". But I don't think Slack meets even that with its user limitations.
With a 10,000 search limit, I don't see why Slack needs to limit users. Without search, it's mush less useful and borderline unusable with over a thousand users or so.
> I wrote this post is to provide a cautionary tale to other open-membership organizations who are considering using Slack
I hope for their sake, The Odin Project (http://www.theodinproject.com) heeds this advice. They recently announced that they started a Slack community of 20,000 members, so they'll probably be hitting the message thresholds quickly.
> We can't pause our community growth while we wait for Slack to engineer around their undisclosed user limit.
You're popular because you're free. You've transferred that logistical problem to another team who happened to offer a free plan without your use case in mind. You've made your problems the engineering problems of another team, except in the other team's case, they're accountable to investors and a bottom line.
While I agree that they had totally unrealistic expectations (and you forgot to highlight the 5 service integrations bit that he also complained about later), slack does also advertise "no limit on users" when they do in fact have a limit.
"Small teams" and "no limit on users" aren't really compatible, and it's pretty normal for people to just read the bit they like and ignore the rest.
Slack should probably just put a 100 (or even 500) user limit on the free plan to discourage people from signing up with such unrealistic expectations.
It seems unlikely that all 5000 people are actively using their Slack account - if you started automatically deactivating accounts that haven't logged in after 3+ months (a pretty easy Cronjob using the API), you would most likely stay well south of the limits. You can always Email people with something to the effect of, "Hey! We've turned off your account, if you visit the site again, we'll turn it back on, no big deal".
This looks like a great value. We were considering using Campaign.js, but actually getting it up and running on a server to fire out campaigns seemed like a pain (as does using sendy). Combining the affordability of SES with some symbolance of the UX of mailchimp seems like a killer value proposition.
Hackathons are awesome. I try to do like 6 or 7 a year. And I'm married and in my mid 30s.
To take the OP's points one-by-one:
- Hackathons are worth the commitment. They're a fast, efficient way to try out 1) new frameworks and APIs, 2) new employees/cofounders, 3) new ideas.
- Hackathons only exclude people with "lives" who don't choose to make the event a priority. Hackathons filter out timid and less motivated people (and those two attributes are related) and you're generally left with pragmatic people who will make it through the weekend.
- The OP is right. The inconvenience isn't evenly distributed. Life isn't fair.
- Hackathons are only as unhealthy as you make them. Gardening can also be quite unhealthy if you don't wear sunscreen.
- Competition is a positive force, and the extrinsic motivation of judgement and a deadline are real, and good for the hack you produce.
- Since this is a competition, you can't work on a preexisting product any more than you could start a marathon a kilometers up the road.
- They're not just toys. Take a look at POWr.io and Zaarly, both of which came out of hackathons. There are many others, and if anyone knows of some of the top of their head, please reply with them.
I think it's great that people are coming together to help code on your gardening project. Hackathons may not be right for you, but they are definitely right for me and the dozens of ambitious people I've coded with at hackathons over the years.
Hackathons filter out people with shit to do. "Timid" people are not filtered out, except insofar as any competitive environment does. Similarly, "less motivated" people are not filtered out, because it is so, so much easier to crank on something for a weekend, damn the results, than to work incrementally on building something great. One takes a short burst of effort. The other takes significant long-term will. Finding the former to be a waste of resources is not a lack of ambition and certainly not a lack of pragmatism.
I think another important point is that Hackathons are what you make it.
I like going to them to meet new people and try out a new idea. If I want to fall asleep, I can. I'm not "forced" into doing anything I don't want to do.
I usually work 14 hours or so, go to sleep, wake up, shower, then work again - doing this for 2 or 3 days hardly makes me feel like crap or messes with my sleep schedule.
This article is PR at its most effective. An established founder snaps up a fancy domain name and his PR team convinces a reporter that Quora has somehow failed. I've found no such consensus of Quora having failed as a business (http://www.quora.com/Has-Quora-as-a-business-failed), nor as an expert question and answer site.
Anyway, the problem with Fountain is you still have to ask a question. And if you can formulate a good question to begin with, Google (which is fast and free) might very well provide a better answer than some random domain expert willing to answer random questions for small amounts of money.
I'm working on a social graph of causality, which is meant to solve the problem of having to ask specific questions to find answers. I call it Causemap (http://causemap.org). Here's something I added today about the militarization of police (http://www.causemap.org/1033-program)
This is an interesting approach. So the idea is basically amassing a bunch of people's subjective opinions about causality? Most of the ideas here are really high-level. Also, I tried to submit a "situation" without creating an account and got a 403 js error. You might want to hide that button for unauthenticated users.
Thanks for the feedback! It still has some rough edges, but I'm really glad to see how people respond to it. It's a combination of a few really new concepts on the web (social news, wiki) and the relatively obscure concept of "causality", so figuring out the right UX/UI for it is my priority right now.
> So the idea is basically amassing a bunch of people's subjective opinions about causality?
Yes, that's the idea. There's also a mechanism to strengthen the strongest causal relationships through upvoting and downvoting. This way, hopefully the most reasonable links show up on top, but everyone's opinions can be represented.
We have a project-oriented full-stack JS curriculum at FreeCodeCamp, but if you're looking for a Rails curriculum, check out OdinProject. Erik's curated the best rails resources. And I agree 100% with what Malcolm Diggs said. Build, build, build!
I couldn't agree more. All we need is Craigslist style verticals (categories of work) and horizontals (cities) + identity verification + a reputation system. The overhead for that could be really low.
The $35k/year/worker support staff would seem to be the only capital-intensive aspect of the business.
There already are some services, likes angieslist. One problem is the review/reputation system. Without purchase proof anyone can review/rate providers and this in time will make the rating system unreliable.
Much like fraud prevention is the "hard" part in a payment processor, reputation systems are one half* of the "hard" part in this kind of marketplaces, and very especially for this kind of tradesman services (*the other is getting both sides to use it).
I've seen several people try to start services like "Handy" and fail due to this.
One big problem is that the best tradespeople already have work, and don't need lead generation services.