[Members] Summer of Code proposals and applications

Peter Saint-Andre stpeter at jabber.org
Wed May 17 11:28:05 CDT 2006

Hash: SHA1

Lucas Nussbaum wrote:
> Hi,
> I just read stpeter's status update on the processing of SoC
> applications[0], and the proposals list[1].
> [0] http://www.saint-andre.com/blog/2006-05.html#2006-05-15T15:47
> [1] http://wiki.jabber.org/index.php/Summer_of_Code_2006
> I think we have a problem with the scope of some of the proposals. The
> mentoring organisation is the Jabber Software Foundation, not Psi,
> ejabberd, wildfire, etc. The projects should really benefit the Jabber
> community as a whole, not only users of a specific client or server.
> I think that priority should be given to proposals targetting
> improvements at a larger scale. Peter, will this be part of the
> council's guidelines for moderating applications ?

There are several issues here:

1. We need mentors. Last year many of our projects were effectively
unmentored. One of those projects (gloox) was successful because the
student was extremely organized. Others were not mentored (well, I was
the mentor, and you can imagine how effective that was!). One of the
other successful projects was to add TLS+SASL support to the Wildfire
server, and that project was mentored by Gaston Dombiak of the Wildfire
team. One way to locate mentors is to have the student project happen
under the umbrella of an existing project like Wildfire, ejabbed, Psi,
Coccinella, Smack, Idavoll, etc. Another way to locate mentors is to
find people who know Jabber/XMPP development in the relevant language,
and we had one such mentor-student relationship last year, which worked
quite well. But I think it's unfair to the students if we have no
mentors for them (only 10% of the students can probably handle that, and
I don't know how to find such people up front based on their applications).

2. I don't see any conflict or tension between adding features to a
particular codebase and benefiting the Jabber community as a whole.
Isn't it good that Wildfire now supports TLS+SASL? That makes the Jabber
network more secure and trustworthy, which benefits the Jabber community
as a whole. The same would be true if someone helped to make Idavoll
fully compliant with JEP-0060 version 1.8, added PEP or HTTP Binding
support to jabberd 1.x, implemented JEP-0116 in Psi or JWChat, etc.
Sometimes a completely new project benefits the Jabber community, but
sometimes it doesn't. Would it really be beneficial for someone to write
a completely new Ruby or Python library instead of contributing to one
of the existing libraries? Maybe, but maybe not.

4. Benefit to the Jabber community as a whole is not the primary
criterion for selection. The point of the Summer of Code is to help
students learn about open-source development pratices through a project
that can be completed successfully in 6-8 weeks. If what they work on
helps the community, that is great, but it is not the primary goal.

5. There is a limit to the number of mentoring organizations that Google
will accept. I don't think they would accept Wildfire, ejabber, Psi,
Coccinella, BuddySpace, or whatever. Most people would think of those as
"Jabber projects" that fall under the JSF umbrella.

6. I'm probably more interested in benefiting the Jabber community and
network as a whole than anyone else, and I will definitely take that
into account as I mod various applications up and down (qualified by my
statements above).


- --
Peter Saint-Andre
Jabber Software Foundation

Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3641 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/members/attachments/20060517/5d3e8f16/smime.bin

More information about the Members mailing list