Hacker News new | past | comments | ask | show | jobs | submit login
Trouble with Diaspora (steveklabnik.com)
153 points by brettbender on Sept 17, 2010 | hide | past | web | favorite | 161 comments



This code was written by a bunch of undergraduate college students.

This is hiring a bunch of interns (with near zero experience) to implement your product, giving them three months, and then being shocked -- SHOCKED, when the code is not professional grade quality.

I was shocked when everyone and their brother was willing to shell out money to a group of completely unproven college students to produce a distributed open source 'Facebook Clone', that is also 'private'. My inclination is that the 'distributed' and 'private' parts of the description push it into the oxymoron tier of product specifications. I would have expected this alone to give people pause about what the architecture would be (somehow it didn't).

Honestly, at least they have produced something, and for the most part, it works. Hopefully they haven't burned through too much of the $250,000 that they started with. 3 months of development time is honestly nothing.

Presumably, they could get comments on this, throw the entire thing away, re-write while fixing the various issues, and be well beyond where they are now in another three months. (If this is as bad as Steve says, I hope this is the case). Presumably the development will go faster because previously they were learning and developing at the same time (presumably).

Hacking together a prototype that you then throw away is a perfectly reasonable development model. I'm impressed (and pleased) that they have produced anything.


"Hopefully they haven't burned through too much of the $250,000 that they started with."

They mention at least two large cost items - luxr (basically consulting by Janice Fraser, it says around $10k on the company page) and pivotal labs. Pivotal is the huge one, I once got a quote from them on a project I was working on and they basically said they don't do less than 6 figures. So unless they got some kind of insider discount, the back-of-the-napkin math says at least half of their cash is gone.

Whether it was worth it or not is a separate matter. As a resume builder for a young team: sure, why not, you could do a lot worse. As a product for end users: you might support their cause, it depends on whether you're 1) a Facebook-hating neckbeard-sporting privacy nut - excuse me, libertarian, or 2) willing to cut them slack on an early release because there's some interesting technical challenge they're tackling.

For everyone else: no thanks, Facebook's fine and we'll stick with the real thing.


According to a post in a thread yesterday, they just worked at Pivotal's office, they weren't consulting for them.


>it depends on whether you're 1) a Facebook-hating neckbeard-sporting privacy nut - excuse me, libertarian

What exactly is so abnormal about being concerned with Facebook's privacy problems? Particularly, what issues are normal to be concerned about and what issues make one a "neckbeard-sporting privacy nut"?


If they re-write, given that they're fairly inexperienced but are probably still sitting on a pile of cash, they run into the Second System Effect.

http://en.wikipedia.org/wiki/Second-system_effect


"Build one to throw away" seems more applicable here. Context is everything when applying fuzzy jargon.


"when following on from a relatively small, elegant, and successful system."

I don't think that the second system effect applies, specifically given that it isn't elegant or successful yet. (In fact, most of the comments are that it is inelegant and a failure).

Second system effect mostly reflects the evils of redesigning a perfectly good working product.


Not necessarily and I think it's one of those phrases open to interpretation.

IMO, second system effect is doing everything you've done bigger and better while fixing the problems in the first system. It wasn't tied to the elegance of the first system design, at least in my mind.


IMO the Wikipedia definition is too restrictive. SSE is common even if the first design wasn't small, elegant or successful.


I agree, rewriting software, even ugly but well debugged software, is bad.

(Debugging is 90% of software development).

But this isn't even debugged.

I write a prototype to learn the technologies for a given project all the time. It is the first step in my development cycle (How the hell does this stuff work?) I don't design it, I just start hacking.

Once I have an understanding of how the various pieces are able to fit together, then I make a design and put together the first system.

My point is that I don't think this is complete or well-implemented enough to comprise a first system. (And it isn't, it is an alpha).


hiring a bunch of interns (with near zero experience) to implement your product - that is how a nearly 90% of projects are started, due to pure economical reason. ^_^


I'm an intern with near zero experience... Anyone hiring? ;-)

(Well, I have more than zero experience... maybe I'm overqualified)


Join a group, and together you will be a gang! ^_^


This code was released to developers as an incomplete preview. I'm not sure why people are holding it to the same standards as a finished product that's being released to end users. Seems like a pretext to talk trash.


I don't think anybody is "holding it to the same standards as a finished product."

I haven't read the code myself, but the OP is claiming "really, really bad security holes", and calls out the encryption code.

Security is not something that can be bolted on after the fact; it needs to be baked in from the start, in a product like this. And, remember, security/privacy was Diaspora's raison d'etre.

No one expects the first code dump to be polished, or feature-complete. But if there are serious flaws there, of the magnitude described, pointing it out isn't just "trash talk."


Security is not something that can be bolted on after the fact

In fact, this is how it happens in the vast majority of cases, including the case of Facebook.


"It can't be bolted on after the fact" doesn't mean it's impossible to take an insecure codebase and make it secure. It means that you can't leave it to the last thing and then just toss a few security things into your product. It means you have to rearchitect major pieces of the product, possibly all the major pieces, possibly switching around what the major pieces are entirely. If you want to show that in the "vast majority of cases" that happens, you need to start by establishing not merely that a particular codebase went from "insecure because nobody hardly thought about security" to "reasonably secure", but that the transition was easy.

Facebook probably isn't the best starting point because anything working at that scale is a challenge no matter what.

(Edit: Though if one measure's Diaspora's eventual size if it reaches its goals and considers what percentage of the man-hours have been put in to date, this is still early in the process and major rearchitecting of every component was inevitable anyhow, so hopefully with one of those they can install some security too.)


Not sure Facebook was an exemplary choice.


including the case of Facebook.

...which is Diaspora's claim to existence.


Their product is released to end users, because the first thing every early adopter is doing with their shiny new host-you-own federated social network is sending out invites.


So they should develop the whole thing behind closed doors because some people are going to have to suffer the embarassment of having someone post "hahaha disregard that ... " on their mini facebook wall?

Their code is out there, they have openly said it is full of bugs and they now have a hell of a lot of eyes, They will get a massive benefit from this being opened early and it really isnt their problem if people refuse to ignore all their and everyone elses advice and give out their banks password


Basic authorization for resource access isn't the kind of thing you add later. This isn't just an issue of bugs or being in development, it's a fundamental issue with their development process.

Furthermore, one of the primary goals of the project was to make something more privacy-conscious than Facebook, and so far they show they have a development process that pays less attention to access control than any Rails app I'm aware of.


For brand new/"experimental" projects with both user permissions and a non-trivial set of features, built by a small team, I've always found it easiest to work like this:

1. Build features, ignoring permissions entirely.

2. When the feature set is relatively stable, default to disallowing everything.

3. Re-enable one feature at a time as you add appropriate permissions checks.

Step 1 looks horribly irresponsible if you don't know 2 is coming. But if you do, it avoids a false sense of security from half-finished permissions in rapidly changing code, and it keeps up early motivation since you're rolling out "exciting" features right away. And counting on step 2 ensures you're always checking whether something is allowed, instead of foolishly checking whether something isn't allowed.

Whether this scenario applies to Diaspora at all ... I don't know. Time and another release will tell. But I do think there are valid situations where authorization is "the kind of thing you add later" for appropriate values of "later".


Part of me wants to say 'Cut them some slack, they just put their work-in-progress code on Github like they promised!'[1], but I understand that most of the criticism stems from caring enough about the project to want it to succeed. At this point, they should be thankful for the attention and the guidance more experienced people are providing for free.

The question is, do the problems in the code establish beyond doubt that this team is not capable of delivering a final product that will see some level of acceptance? I really hope not.

1: I'm assuming that - I would hope they didn't think this was release-ready material.


Invites are not implemented. They have already changed websockets many times since the release. If you have an install you're probably busy merging changes and reconfiguring your web server, flushing the database and debugging it and all people capable of maintaining such an unstable environment realize that it's for testing only, I have yet to meet anyone who's using it to store personal/production data. Stop freaking people out, only devs are playing with it, and if some people are not, this is open source, there's nothing we can do about it.

And may I add, I think it is really great that many public seeds are being deployed, this is the only and best way to test a social federated network, pre-alpha or not.


They state it's a preview and has security holes. It's not their fault people are stupid.


Indeed. These guys should be lauded for getting something out. It's a very non-trivial accomplishment.

I'm afraid that Diaspora might be in an impossible position. If they release something early, they'll get a lot of bad press from knuckleheads like this one that the quality is no good. If they release late, everyone will be clamoring over the wasted $250k in the interim, demanding: "when will we see something?".


I'd argue just the opposite. Especially in today's world. "Getting Something Out" is very easy. I can come up with a project idea tonight, start coding, then publish the code within an hour. Then iterate (or not) to my heart's content. Granted, it's harder with a group. But still, it's always easy to publish shit code. Non-shit is a little harder, but also easier to do with experience and talent.

Now growing it over time, standing up to public scrutiny, hardening, balancing, monetizing -- those are much harder problems. Getting code out? Not really, in my opinion.


I haven't looked at the code, so I can't say this is the case, but...

There's some stuff that good/experienced developers do upfront naturally. There are some security, design and performance things that are clearly a case of bad development versus "this is an early release".

Fundamentals.


"Bad development" sounds like some kind of phrase from a 1950's development model.

"Fundamentals" are things like: there's no identifiable data model, the code is pure spaghetti and structure is a fleeting concept.

From my very quick scan of their code, it's readable, the parts of the data model I looked at are fairly obvious (thanks Rails), dependencies are identified, crypto seems fairly localised. Correction of bugs seems definitely doable. Extra features shouldn't require a total refactoring. Looks good to me for an alpha drop.

Next up: posts criticising the spelling in the comments in the Diaspora code.


Comments on the crypto: http://news.ycombinator.com/item?id=1699782

And I'd say having no authorization in a project that's supposed to be about privacy is missing a fundamental.


First impressions are important. Just as I was excited to hear about a decentralized, privacy-aware social network back in May, I am now worried when it's made available for us to watch its course.

The fact is, the implementation is obviously problematic. I won't go as far as saying that the design is flawed, although some security vulnerabilities are certainly pointing that way. It's obvious that Diaspora's developers are inexperienced, and therefore could use all the help they can get from us. This is one point in favour of an early release, in my book. On the other hand, early design and implementation decisions have profound implications during the lifespan of a project (this is especially true when it comes to security), and I will not trust my personal details to Diaspora in its current form; the project still has a (very) long way to go before being technically up-to-date.


I don't think this article was that mean spirited. The author did submit patches, and is planning on submitting more patches. I interpreted it as a concerned party that wants the project to succeed and is thus pointing out a very real concern, asking others to help, and is himself helping.


"Release early, release often" (an open source mantra). Here on HN i also find the 'getto launch' being preached -- "if you not embarrest by your product at lauch-time, you should have released earlier".

Judging from the noise their release makes here on HN i think the diaspora guys did well opening up their repo 'early'.

And to steve: i think you hold 'professional programmers' (which i interpret as programmer that get paid) waaay too high..


There are a few reasons why this is worse: first, they are launching to media attention and a rabid community. BCC sucked at launch, but no one saw it, so yay. (And by sucked, I mean looked ugly, not "Anyone can delete all your documents at will.") Diaspora has thousands of end users already. Some seeds have 200+. They are launched. Not prealpha. Launched.

Their entire reason for existing is "Facebook but private". At the moment, they are delivering on that like ROT13Snap delivers on secure backup. And due to a programming bug, ROT13 was applied twice, and indexes are on in Apache. It is a cluster flop.


"BCC sucked at launch, but no one saw it"

Strange thing is, the advantage Facebook had is that it launched to a small audience initially with very limited functionality.


i think you miss that diaspora is an open source project. once they release a 'developer preview' people _can_ actually use go an use it. i would not call that 'launched' or '1.0' (which is the open source analog to launching in my opinion). sitting on top of yr code will not spawn discussion, attract devs/tester to have a look. therefor the opensource mantra is release early+often.

it took me 2 minutes to find out what BCC means. for those also wondering: http://www.bingocardcreator.com/ sorry but BCC is not open source so i call it a bad comparison. commercial software is different. the thousands of diaspora end-users you talk of are probably quite aware they are guinnee-pigs of a facebook counter project.

"facebook but private", sorry but again i dont think you get diaspora as it is more like "facebook but distributed".

calling diaspora a "flop" is like calling mozilla before 1.0 a flop: it's open source (something you dont seem to get), its out there for _anyone_ to play with freely, to collaborate on, to learn from...


A related question would be, is this their minimally viable product. And how secure does a minimally viable product need to be?


I think a little more security is needed for this to be any sort of "viable"... So I suppose I'd argue that this definitely is not MVP.

OTOH, they themselves seemed to have said it's not MVP either, so I think that's okay.

I'm still concerned about the longer-term viability using the reasoning of "This many basic mistakes doesn't bode well", but time will tell.

I wish them the best of luck.


> And to steve: i think you hold 'professional programmers' (which i interpret as programmer that get paid) waaay too high..

What I meant was more of "someone who's knowledgeable about their craft," but you're absolutely right anyway.


I've seen 'really, really bad' code. This ain't it.

Yeas, it's made some rookie mistakes. Yes, there's a load of things they shouldn't be trusting on postback (silly things like not checking the owner of an object on 'delete' commands).

That's not bad code, that's a bad implementation. That's not knowing what to trust and what not trust cause they've never been screwed up the ass by it yet.

But bad code? No.

The implementations are problems, they need this shit pointed out to them. That is all.

Steve and Patio11 are doing some serious damage to a good project for no apparent reason apart from self promotion. I want to call them nasty names, I really, really do.


I'm worried that this is going to be one of those group think exercises where people are simply going to key off of their opinions without even looking at the code. Or, worse, reiterate their claims on other forums. I don't think, at least in Patio11's case, that this is gross self-promotion, I think its simply arrogance.


Call me nasty names if you'd like, but I don't see how "please help this project, it really needs it" is self promotion.


Please see the discussion from last night: http://news.ycombinator.com/item?id=1699641

Rather than type a bunch of replies to everyone, here's some random thoughts:

1. Release early, release often is great. But when your product's main focus is "a private social network where you control your data" and other people can do anything they'd like with your account...

2. If this was just unpolished, I wouldn't say anything. But like patio11 is saying, this has been covered by major news outlets, and many non-technical people are getting involved. This is a plea to pay attention to the fact that it's pre-alpha software.

3. The mistakes are beyond amateur. This isn't "omg it's not perfect," this is "I can't believe they didn't even apply the basics." The reason that this matters is that it doesn't bode well for the future of the project. If they can't even get this correct, how am I supposed to trust them later?

4. I only complain because I care. I want this project to succeed, and I really like a lot about the interface, actually. But that doesn't mean I won't call a spade a spade.


"The mistakes are beyond amateur."

Can you pinpoint them? I don't think it makes sense not to at this point..


Since I've already brought this up on Reddit...

For example: http://github.com/diaspora/diaspora/blob/master/app/controll...

There's no check to see if this is your photo or not. And before you mention it, the before_filter only checks if they're logged in, not permissions.

There are many, many similar things to this. Check out lib/encryptor.rb and shudder. I'm no security expert, but...


Same thing is true with UsersController#update (http://github.com/diaspora/diaspora/blob/master/app/controll...). At least they had the good sense not to implement #destroy.


And if you want to wait a week or two, I will explain why that one function lets you comprehensively compromise any Diaspora user in any way you want. The team thinks it only changes their first name, last name, and profile (not login) email.


That is pretty atrocious - I was very meticulous about issues like that (verifying ownership of resources before modifying them!) when I writing a what I knew to be an amateurish ecommerce system, with 9 months of PHP experience. No CS degree, nobody to help me. If they're doing stuff like this, the security situation is even worse than people are saying. If you can't get the huge grain issues even remotely right, the fine grained stuff is sure to slide right past you.


It looks like they're using Devise for authentication, but there is no attention to security beyond that. Devise is just the beginning of a robust security model. I haven't followed their mailing list/twitter/whatever, so I don't know what's going on internally, but here's how I'd rationalize this. Honestly, I don't care one way or another, but I enjoy playing the devil's advocate from time to time.

Rails 3 has been in beta for the better part of the summer. This means that many plug-ins (Devise included) haven't been able to keep up 100% compatibility. It's entirely possible that they've only implemented Devise for login authentication, but plan on expanding with something like Warden or Clearance for model/controller level security as the plug-ins come up to speed.

Our group started on a Rails 3 app back in March, and we learned early on that we should stick to our core app development, avoiding plug-in implementations until things stabilize. Hell, look at Bundler. The jump from 0.9.x to 1.0 broke our app deployment methodology between the beta3 release and Rails 1.0. We never even got around to beta4. When you develop using a beta framework that evolves quickly and breaks compatibility, you have to be careful where you place your efforts.

I'm not ready to lay down on the tracks and defend them here, but I don't think it's an impossible to assume that they just haven't addressed security yet. Maybe they haven't arrived at a framework choice. The fact that there is literally no security would seem to suggest this is true more so than if they had sparse security.

One aspect remains true, however. Anyone who deploys this and puts anything of value in it is asking to get body slammed.


How is that a fundamental security flaw if there's an easy one line fix with no likely side effects?


If it's that easy, why not just implement it in the first place and give people less of a reason to lambaste your application that supposedly centers around privacy?


It's ALPHA software. They're a few months in. They're releasing early and often. I think it's great that they're releasing it now and that people have the opportunity to work on it with them, rather than waiting for them to get everything up to production (or even beta) quality.


How is that a fundamental problem? It takes two lines of code to fix.

This is an alpha release. People shouldn't be using it, that's all. They should've put in an artificial limitation like max. 2 users with max. 2 pics each per server to avoid people using it.

The whole thing being in Rails is much more of a turn-off for me.


If I saw "# FIXME: check perms" in that code I'd have said, sure, it's alpha, no biggie. But without any acknowledgement of what should be a totally obvious security hole, it makes one question what other holes there might be, and maybe they can all be reviewed away... but it can also lead to a lot of pain for a long time. But maybe the visibility of the project will help get that review done.

Realistically, though, so long as they don't get clever it might be fine. If they do clever things then review becomes very hard.


It's not so much that it's hard to fix, it just demonstrates that they're either incompetent or not taking things seriously. It doesn't exactly inspire confidence for the future of the project.


There's a lot of negativity and "I told you so" snickering floating around Diaspora on Hacker News.

I'm putting it down to envy: these guys have shipped some pre-alpha code that's interesting to a large number of people.

Excellent marketing in the open source community for developer eyeballs, perhaps not so good in terms of end-user experiences, but that's not the point at this stage, numbers will be low and the perceptions of the dumb early-adopters (of pre-alpha distributed social networking code, ffs) shouldn't leak too badly into the mainstream.

However, people are now eating the dogfood, and I expect to see fairly rapid improvements in the code: not unexpected for an alpha drop in my experience.

To the people who are moaning, would you like others to see your alpha code and laugh bitterly about you being a young (or old for that matter) upstart?


The trouble is that they were so ambitious but lacked any experience from which to chart those ambitions. They're just a bunch of young twenty-somethings just getting out of school. They haven't built any large-scale real-world security-hardened software yet.

More than the fact that the code isn't production ready (by a long shot it seems), I'm just surprised the released anything at all. Perhaps spending all that money on those consultants was a good thing for them. I doubt they would've been able to get by on their own given what was released and the hype they set in motion. It's a lot to live up to. They made some really bold claims.

Just goes to show that you can't just talk the talk and watch your dreams come true.


The trouble is that they were so ambitious but lacked any experience from which to chart those ambitions. They're just a bunch of young twenty-somethings just getting out of school. They haven't built any large-scale real-world security-hardened software yet.

Thank God that our industry isn't lousy with ambitious but inexperienced twenty-somethings. If we let them run amok, we'd get crapware like MS-DOS and computers like the Apple II.


What were these kids thinking, starting some ambitious software project from scratch without much of a clue how to do it? This is unheard of on the internet!


I don't see what point you're trying to make.

My point is that their problem is other peoples' expectations. Their ambition set the bar before they'd written a single line of code. Had they been more humble and waited to ask for a handout afte they had released what they have now I don't think there would be half as many articles hitting HN about how crappy their software is.

I think that they released something is great. I would never put some one down for having ambitions and aspirations to follow them. I would simply advise that they keep those ambitions to themselves and let their actions speak for them.


I think the "ambitions" you're ascribing to them are based on your own interpretation of events. They sought a little seed money (what was it? $4k?) to try to do something pretty cool. They happened to do it at just the right time and rode a wave of publicity and enthusiasm. Now people like you are saying, well they should have planned it better. Well, they should have released a more mature project before begging for handouts. Well, they should have let security experts do it.

They didn't plan this. But they're giving it a shot.

Haters gon' hate.


If anything, the hype might end up making some other better implementation actually have a chance of succeeding. If anyone else out there was thinking about doing a distributed social network, now's your shot at the limelight. You've got about a week to come up with a basic OStatus-based social network in Rails that isn't full of security holes.


There's a ton of them, and they're all pretty mature. I'm hoping this does have a windfall effect on the ones that have already proven themselves from a code standpoint, and could use the hype that Diaspora has

http://opensource.appleseedproject.org

http://www.onesocialweb.org

http://www.gnu.org/software/social

http://www.elgg.org


Ok... I'm no clearer on what the problem is than when I started reading the article.

All I got from it was they have security problems. What exactly? where exactly?

"Really, Really, Really Bad" is really subjective. When stating a problem try to be concrete and objective and give examples. For instance, if you think someones cooking is a bit off and you are a chef, say you need a little more salt or pepper or whatever the case maybe. A chef can't simply say it is really, really, really bad, leave such comments to amateurs who don't know what exactly they are experiencing and how exactly to fix it.

If you don't really have the time to address each particular concern then give them a reference to some security books that are essential when developing something like this.

As it stands the community is no better off before than when you wrote this. You should have written an article about "10 security books that are a must read to prevent diaspora mistakes".[I would appreciate it if someone who is knowledge about this wrote something like this]


The vague references to security bugs are an act of charity.


Okay first of all, I'm glad that a bunch of undergrads from my school were able to raise $200k, get a lot of press, and build something. This alone should get a community of people around the project fixing bugs, etc.

I've always been saying that making a distributed social network is much easier than "solving" privacy and security for such a thing. First of all, try even defining what it means to privately share things with people on the internet. Then, realize that most solutions (such as diaspora) will actually EXACERBATE the privacy problem, by making you trust the hosting services of all your friends instead of just facebook.

That said, after diaspora was announced it made me think about whether it's possible to ensure privacy in principle. Meaning, is it possible to only trust YOUR hosting company and friends, and cut out every other middleman from being able to snoop your data?

I came up with something which I think would be very useful, and I actually submitted a provisional patent for the technology, which basically enables distributed AND private social networking using just today's web browsers.

If you want to check it out or get involved, see http://myownstream.com . This is an open-source offshoot of a social network I'm building, which I hope to release next year. You can see the roadmap there, but so far it's been going really well :)


Is your school specializing on building secure distributed social networks?


No, man. I was studying math at NYU. Now I do web development.

It's just a coincidence that these guys are also from NYU.


There are very serious security blunders here, but I wouldn't go as far as the article to say it needs a complete overhaul. Here are a few example fixes.

1. Most of the XSS errors should be handled by Rails 3 auto-escaping. I'm not certain why this isn't happening. It may be a simple HAML config error or bug.

2. The session key should be moved out of the Git repo.

3. Most of the authorization can be done by reaching through the current user's associations. For example "current_user.photos.destroy" would prevent users from destroying other's photos.

I'm not defending the developers here and agree these should not have gotten past them. My point is these problems can be fixed in a few days, and thanks to open source, there are many eyes looking at the code to find additional security issues.


This is the problem: college students are terrible programmers. There aren't enough consequences for writing bad code in college. In industry, you learn very quickly that everything you learned in college is minuscule compared to what you actually need to know to work.

I knew guys who only studied databases or only studied HTML+JavaScript+CSS. And we all expected that this level of specialization was common and even desirable! Wow. Looking back now, how silly of us. Where did we get this idea? Certainly not from anyone with significant experience in industry. We had one professor with significant industry experience... from the days of IBM mainframes. She was the head of the department. She ran two classes a year, in "software engineering", basically "technical writing and project management". They were good classes, the most like the "real world" of any of our courses, but only 50% of the students took it and it represented maybe 10% of our studies for those of us who did.

Yes, the CS degree is about preparing students for CS graduate programs. But there was never a suggestion that perhaps the CS degree was not what we needed. Or maybe there was a suggestion, one, from some guy on Teh Intarwebs, against every other person in positions of respect around us. We were consistently told that the CS degree was the path to a software development degree. Yes, internships. They are very important. We don't do enough of them. We certainly need more of an apprenticeship model. I suspect that the development of good programmers would work in a culinary school model more than a research school model.

College graduates are basically the first level of competency worth training to become developers, or at least are supposed to be (let's just stick to ideal situations right now, with no wind resistance and infinite point masses). It's like in the martial arts, we say that black-belt is where the learning begins. Once you reach black-belt/BSCS, you have only acquired the tools that you need to start learning.

Every programmer I've known thought he was a super hacker by the time he got out of college. Me included. I see it in the interviews I conduct, also. There is an air of arrogance. There is a sense of shock and personal assault when pointing out their errors. They haven't yet grocked that the code is not them. They haven't yet learned that the errors are inevitable, that it is only time and experience that teaches us how to avoid them, that programming is about the pursuit of eventual perfection and not the dogmatic defense of yesterday's code.

So one of two things happens. Either the degreed programmer shucks his hubris and finds humility, or he becomes a leech on his coworkers (and my use of the masculine pronoun is no mistake, the female programmers I've known don't have this pathology). Unfortunately, the latter is apparently indistinguishable from the former for most management types. Haha, but digging on the liberal arts majors aside, most people who come out of college with a BS in CS do not want to make programming their wake-to-sleep life. They want it to be their 9-to-5 career, and leeching is the easier route to that.

The kids mean well, I'm sure they are quite intelligent, and they've got heart. But a startup was probably the worst first endeavor for them. I think it's better to go through your male-programmer-humiliation on someone else's dollar. They're basically going into more debt to learn how to be programmers now that they've gotten out of college. They could have been earning a salary to learn how to be programmers.


I agree with you up until your last paragraph "a startup was probably the worst endeavor for them". The sheer gumption to throw yourself whole-heartedly at problems you are unqualified to solve is one of the most important characteristics of a startup founder. Even if you spent time learning to be a great coder, there would be a dozen other things you'd need to be doing for the first time when you first start a startup. Rather than spending a bunch of time learning in industry, it's just as well to just try it when you are young and have less to lose.

Diaspora is also a somewhat unusual case. For most consumer web startups, the back button is a much bigger threat than security vulnerabilities in the early stages. Once you've iterated a lot have a better idea of what you're actually building, one of the first steps is usually to hire coders who are much better than you. In Diaspora's case, it's unclear to me whether their vision is a business or an open-source project - in the latter case then having stronger coders lead the effort is more important.


I wholeheartedly agree with you, if the fact was as simple. As it stands, the paragraph should have read: "a startup [with $200,000 funding of other people's money] was probably the worst endeavor for them", as that more accurately represents the reality of the situation.


I don't think funding changes the situation either - if anything they could have used even more money so they could hire someone more senior that would help guide their development.

Perhaps the problems also lie in the expectations of those giving money. I assure you that few experienced angel investors would have been upset or surprised that the college kids they gave $200K to produced code that was messy or had some bad security problems in the early stages. They would be a lot more concerned with how the founders planned on getting adoption for their fledgling service, or whether they were iterating on the product quickly enough. It seems that many who have donated to Diaspora (or who are getting upset on behalf of other people who donated to Diaspora) have different expectations. '

Just today I was playing with the product of a company in the just-ended YC batch. I found I was able to delete someone else's posted content on the site trivially easily. While I'm sure PG wouldn't be exactly happy to hear about this, he sure as heck wouldn't think that the founders should have spent more time learning to code in industry before taking his money to build a startup. He'd just tell them to fix it (and it's probably fixed by now), and then move on to more important questions like whether they were getting more users and building the right features.


I think the problem with Diaspora is that it received much attention from the media (during the Facebook privacy issue being top of the agenda for most tech/mainstream news bulletins)

Whether that media campaign was orchestrated by the developers, or their investors, or just surfaced naturally as some news stories tend to do, I think this attention didn't really help matters when it came to putting a group of inexperienced graduates together to create what potentially should be a rival to a multi billion dollar company in one summer.

They should have been given more time and let to lead more of a low profile than the charade that's taken place over the past few months


"Every programmer I've known thought he was a super hacker by the time he got out of college. Me included."

This is referred to in the Dreyfus Model of Skill Acquistion. It refers to a space in time where we are advanced enough to not be a novice, but not advanced to realize our own lack of expertise. Merlinn Mann refers to it as being an "advanced beginner". The problem with this stage is that's it's impossible to rationalize until you've escaped it - that or you use metacognition - with awareness of said likely ineptitude because of posts like this.

http://en.wikipedia.org/wiki/Dreyfus_model_of_skill_acquisit...


I believed I was a super hacker when I got out of high school, it wasn't till I got to college (and after stubbornly admitting my teacher in HS was right) that I realised I wasn't and that my code sucked. Now I am out of college, I am in a real life working job, and I've received praise from my peers for the code I have written. Yes, getting told that your code sucks is good, it is even more awesome to get told by a veteran in the industry that your code is pretty good and easily maintainable.


I think it's better to go through your male-programmer-humiliation on someone else's dollar.

I'm pretty sure that's what just happened.


Plenty of successful tech startups have been launched by students coming straight out of college, so I think the attitude of "sorry kids, better do your time somewhere else first" is very harmful to both students and the industry as a whole.

Sure there's a lot they have to learn, but there's no reason why they won't be able to learn by doing. They clearly have all of the funding and motivation they need to get to the point of having a stable release. I'm glad the author (of this blog post) submitted a patch, and hopefully momentum on this project will continue to grow, as more experienced developers offer their advice and expertise.

edit: Also, I'm not sure if "startup" is the best thing to call Diaspora. Given the fact that they're already well funded, and working towards the public good, they might be better off incorporating as a nonprofit, similar to what the Miro guys did (http://participatoryculture.org/).


That first time someone just flat out mercilessly tells you your code is terrible is awesome.

Actually not awesome, because for the rest of your programming career you will realize that your code is terrible.

But awesome because that's when you leave the womb and start down the road to being a good programmer.


how do you make that link clickable?


Just make sure to include the http://. eg, http://paulsawaya.com


Every programmer I've known thought he was a super hacker by the time he got out of college.

Wasn't Linus Torvalds a college student when he released linux? For that matter, Facebook was written by a college student. Some college students can do amazing things. Also, this is just a pet peeve of mine, but don't diminish college students by calling them "kids." Many may be young, but they are adults.


Yes, but an advanced graduate student, and Linux was his thesis project. Though he was ~21-23 at the time, the experience and maturity level was indubitably higher than the average CS undergrad in American universities.


I think you're working too hard on the explanation of what happened here.

I think the problem is that four undergrads were given a quarter million dollars to compete with the largest website on the internet and people expected anything but disaster.


Where would Facebook be now if the founder went to learn the ropes by working for the man? Zuckerberg was still in college at the time, and now he keeps Google up at night.


This all sounds very wise...until you remember that Facebook itself was written by Zuckerberg when he wasn't yet out of college. Linux was written by Linus Torvalds when he was in college. Firefox was written by Blake Ross when he was a high school stduent. Chatroulette was written by Andrey Ternovskiy, another high school student.

Some people are just really good. And a startup makes them even better, and much faster than if they had decided to be "apprentices" or "interns" forever.

The thing about Diaspora is that UNLIKE Facebook or many other startups, its source code is on the internet for all to see. Do you think the original Facebook (written in PHP) didn't have security holes that would be transparent upon reading the source code? For that matter, do you think today's Facebook source would withstand attack if posted on the internet tomorrow?

The question answers itself.

If it achieves its potential, Diaspora will be hardened to a considerable extent because of the scrutiny that open source provides. This is not the time to slam these kids as wet behind the ears undergrads. Their code is pretty good for something written in 3 months. And if you really are that much wiser than them, they are accepting patches.


"But a startup was probably the worst first endeavor for them. I think it's better to go through your male-programmer-humiliation on someone else's dollar."

I don't know. It seems like they are earning their "male-programmer-humiliation" in the most efficient way possible. If having an article about how atrociously buggy your code is at the top of Hacker News doesn't teach one instant humility, nothing will.


This whole thing makes me wonder...

Many startups are started/coded by young programmers in or fresh out of college -- people who probably haven't really earned their 'black-belt' in programming through time and experience. This would lead you to believe that many startups (even relatively successful ones) have plenty of bad/buggy code under the hood, but they have the benefit of not being out there under the scrutiny of public eye.

That said, if you're a young (and thus, probably somewhat inexperienced) coder, it would seem you can get stuck in the conundrum of wanting to have enough experience to write good code, but also wanting to go for starting a company while you're still young. Would love to hear opinions/thoughts on how to solve that conundrum.


My guess is that the startups get VC funding, and then they hire professionals who take it from there. The "wonder boys" that started it are mostly just figureheads at that point.


it's insulting to refer to them as kids and criticism like this is only helpful if you give examples: this article does not do that, just making wide sweeping statements about "how bad" it all is. i had a quick look at github, it didn't look like it stunk, but i don't know ruby nor the framework they use.

they didn't appear to use pbkdf2 or similar to derive their crypto keys, so that isn't good. but at least they didn't make up their own algorithm (though maybe they're making their own crypto protocol--hopefully not--i couldn't tell from the code).

it's very easy to say "this sucks", it's harder to say "this sucks and here's why" and it's even harder to say "this suck and here's why and here's how i do it in my deployed product"


I call everyone 'kids,' it's not meant to be offensive. I'm 24 myself.

The 'here's why' part gets tricky with security stuff. I don't want to be complicit in people trashing accounts. And if you read, I did submit patches.

And they are making up their own protocol. It's currently not documented.


yep. in common usage it often seems 'kids' is a reference to anyone no older than 5-10 years younger than oneself. ;)


I'm not even sure it's worth submitting patches to Diaspora, both because of the fundamental problems with the code, but also because of their "Open Core" licensing scheme (AGPL + contributor agreement): http://www.ebb.org/bkuhn/blog/2009/10/16/open-core-shareware...

Looking through the code, it looks like Diaspora is really just putting a front end and "aspects" on top of OStatus. I think it might be good at this point to just scrap the Diaspora code and start over from the basics with a good OStatus-based reference implementation in Rails.


At its core, the real value in something like Diaspora is its protocols. If you disagree with the license, or the language they chose, why not make your own implementation from scratch that can federate with it.

If it survives, I might do this... I think their approach is fine for rolling out a private enterprise FB or creating an alternative hosting solution, but I'd like to see an even more decentralized solution. Ruby isn't a good choice of language for mobile, or native compiled "IJW out of the box" deployable solutions.


It's great that they're getting so much open-source help, but I'm going to ask the obvious question: if a "complete overhaul" is what's needed, as the author seems to imply, and the FOSS community performs said overhaul, then what of the $250k that was given to the Diaspora guys? Is it still even "Diaspora" anymore, as opposed to a FOSS project?


It's an awful lot easier for a bunch of third parties to refactor and fix something that's bad, a piece at a time, than for a bunch of third parties to create something from nothing. Diaspora is a good thing, even if it's bad: the mere fact of its existence and the enthusiasm around making it better gives it a vector of development that a mere idea would never have.


One could argue that it's even easier for a bunch of third parties to improve something less bad like StatusNet, OneSocialWeb, or Appleseed, but apparently Diaspora has sucked all the air out of the room.

Edit: I see jlgbecom already made a similar point below.


And more importantly, if you're going to rewrite, why help Diaspora, and not a more mature option?


Because momentum and attention are more important than maturity. The qualities that come from maturity can be built with work; momentum and attention aren't as much of a function of hard work and are far more difficult to capture.


Momentum can die as fast as it builds, while maturity is lasting. All these projects are in active development, and it'll be very difficult for Diaspora to catch up.


And this is what always happen. The choice between security, maturity and dancing bunnies is always skewed in a wrong direction.


What more more mature option were you thinking of?


Here you go! There's not just one, but a whole bunch!

http://gitorious.org/social/pages/ProjectComparison


agreed. not sure what direction they intend to go in


One thing I really liked about this post: most people readily complain about something, yet only a few like Steve actually do something to help fix it.


Indeed. If the world was filled with more people like Steve it would be awesome. This post is getting close to 100 comments. If each commenter took the time to fix just one bug, that would be a lot of progress just there.

Go Steve!


Thank you.


Jason Fried was right. All the hype and pressure before launch will cause some serious problems.


They could've really saved themselves some grief is they'd been far more explicit about saying that it's Alpha and months from being production ready. All this 'there's bugs! omfg!' hoo-ha could've been headed off at the pass


I think there's a big difference between "omfg bugs" and "The bottom line is currently there is nothing that you cannot do to someone's Diaspora account, absolutely nothing" from http://www.theregister.co.uk/2010/09/16/diaspora_pre_alpha_l...


Not really, in fact that article was exactly what I was thinking of, reading it it'd be easy to get the impression they were talking about production software after the first sentence. Bugs are fixable and I haven't found any serious design or protocol mistakes, nor seen anyone else point any out. Given that, I'd say they're doing pretty damn well.



Without more details its hard to tell how big of an issue this is. I've been brought in on projects to fix security in the past, and in many cases, after thorough design and code review, we crafted up a modified design and implemented it in a week.

And these were in substantially larger systems.

With that said, I haven't looked at the code, so maybe the issue is more fundamental than that, but I haven't seen evidence of that yet.


They could have saved themselves some grief if they didn't over-promise in order to get money for a project before they had a single line of code.


A perfect storm of backlash against Facebook's privacy issues combined with major media coverage thrust them into the spotlight - their original ambitions for the project and fundraising goal of $10,000 were set before that happened. By no means do I see that as "over-promising in order to get money."


Even asking for $10,000 was major hubris that made me skeptical they were up to the task. But they could have been more honest about their capabilities, timeline, roadmap, etc. in order to put things into perspective and bring the hype down a notch. They most definitely over-promised, even if they had only received the original $10k


At least somebody's got a sense of humor:

Github issue #8: "Facebook has a majority market share"

http://github.com/diaspora/diaspora/issues#issue/8


If you didn't catch it, it's referring to Ubuntu Bug #1: Microsoft has a majority market share

https://launchpad.net/ubuntu/+bug/1


I saw that. But it's still funny =)


Steve, where did you get the $250,000 figure? Their Kickstarter page still shows $200K and change (http://www.kickstarter.com/projects/196017994/diaspora-the-p...), and now there are currently three mentions of $250K in the comments here, none of them questioning the $50K raise. Just checking to see if I missed another bit of funding somewhere.


Nope, I just remembered wrong. I'll edit that now, thank you. At least that's not as bad as someone on Reddit who tried to say they raised $4mm...


No worries - I would have left a comment on your post, but I didn't have an account to sign in with, and wasn't sure if maybe they had raised an additional $50K outside of Kickstarter.

Just wanted to say good on you for fixing bugs and contributing to Diaspora! Unfortunately I don't even know enough Ruby to understand what I'm looking at, but I'm excited about the project - they've definitely got a good resource in you! Is there any indication that they switched to Ruby during this Summer? I swear it was originally going to be in PHP, but I can't find any mention of that now. Could the oversights in the code be due to this being the first piece of Ruby the team has written?


They won't have me for long; I have my own projects to work on. Hackety Hack is more important to me, by far.

I also vaguely remember that it was supposed to be in PHP as well, and several other people have mentioned that. I can't find a source...

It could be the reason, but things like "make sure if you're trying to delete a photo, it's yours" is something that transcends implementation languages, you know?


Maybe they'd even be open to hiring you as a paid consultant, since they are now using Ruby, and seemingly are willing to invest in improving their project.


They (Diaspora staff) said this as they released it:

"Feel free to try to get it running on your machines and use it, but we give no guarantees. We know there are security holes and bugs..."


The issue is you shouldn't build (or ship) code like this with such major security holes, you build security at the start, it should be an integral part of the application. You can't just dick out some insecure application then add in security, it doesn't work.


Microsoft didn't "build security in at the start", nor did Apple, nor did Twitter, nor (I suspect) did Facebook or YouTube. It's a pre-alpha of an open source project. Of course there will be problems.


Yeah and how much code is being used now that existed when they didn't have security? You can't compare this and what Microsoft, Apple or Twitter have done, I'd be very surprised if any of those companies continue to use code that was developed at a time when they didn't consider security. Although thinking about it, the software industry is questionable... maybe I'm wrong, it just seems a very bad start.

Twitter has had major security problems, same with many other "big" companies, shouldn't this be a lesson that security is the primary concern especially for an open source project?


What's the likely hood, security issues asside, that much of this code ends up in the 'final' Diaspora product down the line? I might misunderstand their intentions, but as I understand them, these guys are trying to start an open-source project. Open-source projects need momentum before they need anything else. Money is a start, but they need code. It doesn't even need to good code or even passable, so long as it kind of works and provides something for hackers to hack on. If they play their cards right, it's that last bit about attracting hackers to the project that will turn Diaspora into something viable. None of the code they write right now really matters.

Just think of many of the older more established FOSS projects, Linux, Apache, etc. Many of them started out very rough, but attracted developers and turned into something useful. I think that dumping the code right now, was probably the best move that they could have made.


"Now" is a biased measure. There's a difference in years between "now" and the geneses for the projects you cite; for Diaspora, a couple of days.

During the summer, I could only shake my head at the hullabaloo coming from Diaspora supporters. Now it's at the detractors.


They aren't "shipping" anything, where did you get that? They're opening it up to the OSS community. There have been far greater programmers out there that have released far more atrocious code than this at an early stage to spark interest among their fellow developers. Give them a break, this isn't a freaking launch party.


Good point. We'll wait for the security experts to build this.

.............................

................................................

Still waiting.........................


I was totally expecting crap like below when cloning the project:

* literal SQL without escaping (They use Mongo it turns out)

* 10,000 lines of controller action (The biggest one is Photo#create, but far from huge). PS: They use carrierwave, which is AWESOME.

* giant business logic in the views (They use haml and the code is clean).

* Not escaping user's input (OK, there are places where they forgot to put it).

Their code is far from shit. Easily improvable as they gain more developers. Aren't we too quick to judge?


Good thing: the project already has 292 forks and 2051 watchers on GitHub!

I believe they will get an amazing quantity of outside work.


As far as I can consider, there are two possible alternatives to this (that is, releasing their flawed code). They could have either released flawless code, or they could have released no code at all. I understand OPs concern, but considering the alternatives I don't really get the tone of the article.


First people bitch and whine because they are working "in secret" and not releasing code. Then they release and everyone freaks out because it's not finished. I guess the only way everyone would be happy would be if they released a completed project after a week.


Where in this article does the author complain about it not being finished? It's the fact that the Diaspora team is not doing things right. No one cares that this project isn't finished they care about how much it sucks because their whole reason for starting the project was privacy and they don't even come out of the gates with a secure system for people to implement/build upon...


The author of the article didn't, but no one is going to argue both points, since they are contradictory. This author is angry that the code isn't finished. Many other people were angry that it wasn't released. I'm just saying, there's no way for these guys to please everyone, which is to be expected.


I'm not angry the code isn't finished. I'm concerned that people don't understand what they're getting into; yes, they mentioned that it's an alpha release, but nobody is paying attention to them.

And I'm also concerned that if they'd consider releasing something so broken that it won't be taken care of in the future.


My god most of these comments are sickening. It sounds like a group of old men reinforcing each other how much better people were "back in their day" all the while forgetting what "back in their day" actually was. Is it jealousy that is fostering these posts?


This is pretty unfair. They just want to get it out there earlier than later, so that the community can help with a few of the less glamorous parts of the app. I guarantee they've been spending most of their time just wiring things up and making the interface look pretty (the fun stuff), and now are tapping into the OSS community to help take care of the security details. I completely sympathize with this strategy, and they explicitly said it was far from secure or complete.

It's this kind of code bashing that makes it difficult and intimidating for newbies to break into development. Think twice before you lambast younger, less experienced programmers on the internet. What a shame.


It's an MVP. Problem is, it's in an established market. Although this worked for open source in the established unix market, that wasn't a mainstream market. But note: only a tiny subset of users are going to switch initially anyway, so, in practice, it's not mainstream at all. Besides, expert coders will contribute; I've seen it happen.

And it's infinitely better than the alternative, of getting everything right first time, because that's impossible. Something is better than nothing. Live it!


The "V" in MVP stands for viable.

As is, the Diaspora code base is not viable. Not even minimally so.


The "P" stands for product, not code-base.

Logically, security and privacy are secondary: they are properties of some functionality/data.


Yes, P does indeed stand for product. And this is not a product. Not yet, anyway.


If you do some reading around MVP, you might be surprised at what a low standard exists to constitute a product. Some folk even count an ad + landing page as an MVP. ie. 0 code base. An MVP is a point of departure, not arrival.


I will certainly concede that, especially given that this isn't anywhere near my realm of knowledge - I'm strictly a coder and don't have the vision or insight into product presentation, preparation, or anything like that.

However, my instinct tells me that the example you mention of say, an ad + landing page, IS an MVP in one good sense - to gauge interest in a potential product (an iPhone app, etc), gathering subscribers to mailing lists, beta signups, etc.

But in the scope of what Diaspora is trying to accomplish, releasing the code base like this doesn't qualify as a product - I think.

I am way more than willing to be wrong on this point, though. I'm also probably just splitting hairs by this point.


At the moment, their primary task is actually to gauge/encourage interest - without that, they have lost.

A following task is to discover if what they have is usable/useful by real people, and the only real test of that is to release it and get feedback. Related is flushing out bugs (most effectively done by actual usage); testing performance (even for small numbers of users); and of course flushing out specific privacy and security issues. Note that it's not actually necessary to even continue with the same codebase; it is possible to use it as a prototype.

I think a helpful way to separate a "product" from a "codebase" is to ask whether a complete rewrite in a different language with a different internal architecture (and of course codebase), that is indistinguishable to users, could be sold as the same product.

I think the Mythical Man Month would be of interest to you; he has your perspective, but with a wider scope. I think you'd really enjoy it, if you haven't already. Some fascinating ideas appear right up in chapter 1, very clearly written.


It's fun to think of a software product as a giant ADT (Abstract Data Type), as it specifies operations that may be carried out (via a GUI, or command line, or webpage, or webservice, etc), while the detail of the implementation of those operations is hidden. Each instance (running copy) of a software product contains its own data.


As other people have already said: this is just an early code drop. It would be good to have it transition into an open source project with many developers, especially because the developers are I assume starting their fall school term.

I enjoyed building and playing with the code, and I hope that there is a much improved version in the future.


"the developers are I assume starting their fall school term." Two of the Diaspora team graduated in May, and the other two have taken a leave of absence from NYU to continue to focus on the project. See: http://www.joindiaspora.com/2010/08/26/overdue-update.html


I don't want to disclose too many details

I thought the idea of a developer release was to do exactly this.


To them? Sure. On my blog, for (what's currently around) 8000 people to read? Nope.


What do you think the first release of Facebook looked like under the hood?


I can hear Zuckerberg chuckling like an evil genius.


Why would he even care? It's only in some confused fantasies that this project, of all projects, would be THE ONE to actually challenge Facebook. It might, it might not. No more likely Diaspora than some project cooked up by a pair of 16 year olds in Brazil.


Have you seen first versions of FB?

My guess is that it was a much bigger piece of crap. A PHP crap. And guess who wrote it? Harvard undergrads. ^_^


In all this , we forgot that they are here to create an open social network. This was their dream, so may be this is the way they wanted to do it.


I'm not sure what is the problem here. It's a piece of software that was released to the public on Github and if anyone decided to use it shouldn't expect it to work without flaws.

If it was a piece of crappy software that I wrote and put it on Github, I am going to get criticize to the point that it's worthless, I'm not sure where is the open source spirit going this way.


Why? It is called crowd-sourcing and there are even several "bestsellers for dummies" about how to use crowds to make money.

Nothing to see here.




Registration is open for Startup School 2019. Classes start July 22nd.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: