Sophie - DW and the Google Summer of Code
browse
my journal
February 2020
 

Date: 2010-03-29 08:53
Security: Public
Mood:worried worried
xposthttp://soph.livejournal.com/200038.html
Tags:big posts, dreamwidth, google, google summer of code, livejournal, programming
Subject: DW and the Google Summer of Code

I've been hesitant to post about this, as I know that both Mark and Denise read this journal, but this issue is important enough to me to post it.

So, the application phase for students to apply to organisations participating in the Google Summer of Code begins today. Dreamwidth is one of these organisations.

From the start, I haven't liked the idea of DW taking part in the GSoC, and that's because GSoC, by definition, focuses on the code. Students enter the GSoC to code, and to get money from Google for doing it. They're not there to spend ages learning about the culture.

One of my favourite parts of the DW development culture was nicely summed up by Kirrily Robert, in a presentation called Standing Out From The Crowd that she made at OSCON last year:

From the very earliest days of your project, recruit the diversity you want to see. The first two or three members of the project will set the tone for what follows. People will look at the project and think, “Is this somewhere I can see myself fitting in?”

If you’re working on a desktop app, recruit desktop users. If you’re writing a music sharing toolkit, recruit music lovers. Don’t worry about their programming skills. You can teach programming; you can’t teach passion or diversity.


This isn't to say that coding experience doesn't matter, but it does place a lot more emphasis on passion - someone's love for the idea of what they're doing. Passion, in a lot of cases, also implies experience and involvement, perhaps with similar projects, or even use of the app itself, if it's not being built from scratch.

And so far, every single one of our developers on Dreamwidth are here because of that passion. We're all avid users of the site itself; none of us started developing for DW before they started using it. Even when the project started and there wasn't a "site" to speak of, all of us originally came from LiveJournal - and since then, we've gained new developers from people using the site and wanting to help build it.

However, students who apply for GSoC may know nothing about Dreamwidth other than what they've read in the Welcome, Google Summer of Code students! post in [site community profile] dw_dev. Now, this isn't criticising that post at all; on the contrary, it's an excellent post and I'd advise every GSoC student applying to Dreamwidth to read it. However, one cannot know the community and the culture from one post. Even if they take the time to read other posts, maybe from the Latest Things page, you're not going to have that passion, or know the culture; that can only occur from actual usage of the site, having friends on the site, and taking part in things.

I want to emphasise the importance of having friends on the site here. Having a friend on the site - or at least someone you know - is an excellent way to become adjusted to the culture, because you'll be reading your friend, they'll be reading you, commenting on each other's posts, and possibly other people's too. It's one reason why I loved the invite code system on LJ, and love it on DW; it preserves the culture.

But again, GSoC students will probably not know anybody on the site before they apply. As such, their viewpoint will be mainly centred on blogging, not on community - which could explain why we've been seeing so many students wanting to write desktop clients. It makes sense that if your priority is writing your own posts, it's far easier to open up a client and use that. But if your focus is on community, the only way you can really get involved in that is by using the website itself, as very few clients will let you post comments to other journals. That said, the Dreamwidth API doesn't allow for that at the moment, so if there were any clients that commented on other journals, they'd need to web-scrape. (We are developing an NNTP server which might help with that in the future, which I'm looking forward to.)

Now, I trust Mark and Denise to not mess this up. I believe they know all this already and probably had a long discussion before even applying to become a mentoring organisation at GSoC. I believe that the candidate they pick will most likely already have been an LJ or DW user in the past. But that doesn't stop me from being afraid in case they aren't. They may be a fantastic coder, stick to all our Programming Guidelines, and wow us with how elegant their code is, but without that crucial knowledge of the community, and a passion for it, how will they be able to design features that we as a community want?

Post A Comment | 4 Comments | Add to Memories | Tell Someone | Link



foxfirefey: dreamwidth
User: [personal profile] foxfirefey
Date: 2010-03-29 09:29 (UTC)
Userpic:dreamwidth
Subject: (no subject)

GSoC isn't just about what Dreamwidth can get out of some summer coders--it's also about engaging with the broader open source community and giving something back.

I think the reason so many people are into clients is more that many applicants don't know Perl well, and writing a client doesn't require them to know or learn Perl and lets them cater to an area of their strength--much like the person who wants to revamp the RTE is catering to their strength. And well, the server codebase is pretty damn intimidating.

Dreamwidth doesn't have to use the code made by any of the students. There isn't anything to fear. I'm not saying there isn't anything to lose, per se--I mean, time and effort goes into mentoring a student that could be spent elsewhere--but we don't have to absolutely maximize the utility of our students, which is what you appear to be describing. This is more about them than us. And if they're outsiders, it's okay. We can welcome outsiders. They'll know what features the community wants because the community will tell them.

And if some Google Summer of Code student writes a client that nobody wants to use, well, that's okay. It's not going to destroy our way of life! But y'know, we really could use clients. They're nothing to sneeze at.

Reply | Thread | Link

foxfirefey: mischief
User: [personal profile] foxfirefey
Date: 2010-03-29 09:31 (UTC)
Userpic:mischief
Subject: (no subject)

...also, we can totally expand our API, eh?

Reply | Parent | Link

Azure Jane Lunatic (Azz) 🌺: #dw
User: [personal profile] azurelunatic
Date: 2010-03-29 09:35 (UTC)
Userpic:#dw
Subject: (no subject)

I see we're thinking in similar directions.

And even a bad client is somewhere to start from; other devs can pick it up later and hammer.

Reply | Parent | Link

Azure Jane Lunatic (Azz) 🌺
User: [personal profile] azurelunatic
Date: 2010-03-29 09:33 (UTC)
Subject: (no subject)

I'd be worried more about that if they were looking to bring in someone fulltime and were looking to GSoC students as possible candidates for employment.

Consider the worst-case scenario. What could a GSoC student possibly do that would affect the site longterm?

They might write a client (or other piece of the site) missing things that people in touch with the site gestalt want.
They might write something that's got things that people in touch with the site gestalt adamantly do not want.
However, since they're to be working with a mentor, I trust whoever is mentoring them to be aware of the site gestalt, and to act as gatekeeper between the greater Dreamwidth project and features that aren't in tune with the site.
Even if the mentor doesn't manage to convey the will of the userbase regarding features to include, and fails to block features that are useless or counterproductive from being produced by the GSoC student, Dreamwidth doesn't have to actually use that thing if it turns out to, against all expectations, be full of fail. Granted, if it is a client, it would be hard to stop someone from distributing it if they felt like it, but no-one who doesn't want to use a client would have to use that particular one, and someone else can write another later.

It's only over the summer, so even in the worst case of development/vision incompatibility, it's not like they'd be then requiring the oversight of an experienced dev eternally.


I think the biggest potential threat to the Dreamwidth Experience from GSoC is not in code, but in community, and specifically development and volunteer community, dynamics.

A GSoC student who is already an excellent match for the development community would be able to slip in seamlessly, or adapt to fit the framework of the community style in short order. Someone who is an exceedingly poor fit and unable to adapt would not be able to mask this for long, and would wind up either voluntarily wandering off (or flouncing, or something), or would be such a poor fit and so very unable to adapt that one of the owners would be obliged to step in and remove the person from the environment for being excessively disruptive.

However, someone who is incompatible but highly motivated to appear compatible (for example, for financial reasons) might spend some time trying very hard to get along or act like they are getting along, and soak up the social patience of the people dealing with them. This could take a toll on the people who were not bargaining on having to deal with this situation, and affect morale. However, if it's not blatant to the point where staff would feel it necessary to step in, and not to the point where someone would report it as being a problem, just grating and wearing, it might go on for some time and cause low-level crankiness. Low-level crankiness can be soul-destroying.

Again, though, it's only for the summer. September will end.

Reply | Link