Recruiting Source

Masatake YAMATOTranslated by Ryoko YAMATO

Special Form of Software Development MethodUsed in XTLA

Ideal Open Source Development● Attracts many developers and users, which leads 

to the project growth.● Ideal growing cycle:

1.First, source code is open to public.

2.Developers begin to join the project.

3.Functions and quality are improved.

4. Increase in the number of users catches the eyes of other developers.

5.More developers will join the project.

6.More users, as a result.

Open Source Development in Reality● Too many projects for the number of developers on 

earth. – The number of developers per project will not increase.– The number of users per project will not increase either.– Another similar project to be started by others; since the 

existence of the initial project is hardly known to people.– Similar projects fight over developers and users.– Each similar project is likely to remain imperfect. 

● The whole category, which these projects belongs to, might fade.  

Ideal Project

Project leader

Developers

Users

Dead­end Project

Project leader = Developer = User 

Ideal Category

Project A

Project B

Project C

 Mutual growth by competing each other

Dead­end Category

● Users can't easily see which one is the best to try.  ● Many projects are not ready for practical use.● Developers can't see which project they should compete with. 

Dead­end Category

Even if you start another project to overcome the situation, your project will be hardly recognized in too many projects.

Example of Dead­end Category : IDE

In case you don't know Eclipse, you have to check  all 519 projects.

Example of Dead­end Category : IDE

No more subdirectory here. You have to browse 26 pages.

March 11, 2004In the category of "Emacs Frontend for 

GNU Arch"

Three projects were already in this niche category.This category is destined for dead­end, too?

What can be done ?

tla.elMilan Zamazal

tilly.elMartin Pool

xtla.elStefan Reichör

Outline

● Open Source Development method, in which you make source code open to public and wait for developers and users coming to you, cannot be a solution to prevent a category from becoming "dead end."

● Proposal for "Recruiting Source Development(RSD)" method where you invite other project members who already have their assets (experience, source code) to work together.

● Reporting the growth of XTLA project to which RSD was applied.

To be covered in this presentation:● Supportive software in this project

– GNU Arch– QuickML

● Process of XTLA development● Recruiting Source Development method

Supportive software in RSD

 Distributed version control systemGNU Arch

CVS

Repository

developer developer developer

install

modifications

Arch

developer developer developer

exchange modifications

Archive

Distributed version control systemGNU Arch (cont’d)

● No permission is needed to make a branch.● Easy to create a mirror archive to publish your branch.● Development at your own pace.

– Little interference from others.– Cause little trouble to others.

● Relation to XTLA– XTLA covers up complex command line interface of Arch.– Source code of XTLA itself is managed in Arch archives.

Lightweight mailing list systemQuickML

● Run at QuickML.com ● Management tasks such as 

creating mailing lists and adding members can be done by just sending a mail.

Subject: meetingTo: party@quickml.comFrom: jet@gyve.orgCc: tank@example.com,        sub@cracker.net

● Anyone in the mailing list can invite other people to the list.

Subject: add membersTo: party@quickml.comFrom: jet@gyve.orgCc: sam@punk80.com

Development process of XTLA projectThe first three months

Why XTLA?● I have been interested in distributed version control system 

since the failure to have gs­cjk patch merged to Ghostscript.● I really liked pcl­cvs, the Emacs front­end to CVS.● There had already been three projects of front­end 

development, so  I did not think of starting another one by myself.

● After tring tla.el, tilly.el, and xtla.el, I found out xtla.el was the closest to what I was looking for.

● The author of xtla.el (hereafter Stefan) was also a developer of psvn, a Subversion interface for Emacs.

First contact●  I wanted an Emacs frontend as soon as possible.● To avoid this category from falling into dead­end, I decided to 

take part in one of the projects.● xtla.el looked the most promising.● March 15, 2004： Sent my self­introduction by e­mail to 

Stephan.  His reply was "contribution welcome." I could get a feeling for his personality from his e­mail. 

● March 18 : Sent my first patch to show my enthusiasm. Stefan merged it on that day and released the new version.

Mailing List started● March 21： Stefan requested savannah.gnu.org to register our 

project. Screening process was delayed.  ● April 10 ： Launched a mailing list at QuickML.com as a 

temporary one.– Stefan,  Matthiew Moy, and I became the ML member.– So far, XTLA project had three times as many developers 

as the other two front­end development projects did.● (March 15 : Matthiew had already made a contribution to 

XTLA)

Distributed development for XTLA by XTLA● (Since Stefan had not set up an archive­mirror for managing 

XTLA source code yet, the rest of two sent patches by e­mails.) ● All of three set out to open each one’s archive­mirror to public 

from April 8, and finished it by April 15.● Various XTLA functions needed for distributed development 

were implemented one after another.

– Setting up mirrors– Picking up changesets from other repositories.

●  XTLA became the tool to develop XTLA itself.

 Recruiting developers● How can we have more,  skilled developers in our project?● Is  there  anyone  who  wants  Emacs  interface  for  GNU 

Arch, can use Emacs lisp, and knows about GNU Arch?● April  19： Sent  an  e­mail  to  the  author  of  tla.el,  Milan 

Zamazal,  to ask  if we could work  together.   He accepted our offer, and was added to the mailing list.

● April  21：Matthiew  sent  an  e­mail  to  the  author  of tilly.el, Martin Pool. Here again, his  reply was "yes" and he joined the mailing list.

Using web search results for recruiting developers● Obtaining resources (developers, source code, know­hows) by just 

sending  a  mail!    Getting  a  taste  of  success,  I  used  Google  web search to look for developers. Keywords: tla front­end emacs ­xtla

● May  8:  Contacted  with  the  author  of  xxx.el(anonymous),  Mr. Foobar(anonymous). But it was unsuccessful.

● May 16 : Succeeded in recruiting the author of mst­arch.el, Mark Triggs.

● May  17  :  Matthiew  invited  Christian  Neukirchen,  the  author  of nbbba.el.  He showed his interest, but he was not active in coding.

May 17, 2004The category of 

“Emacs frontend for GNU Arch"

xxx.elMr.Foobar

XTLA

Stefan ReichörMatthiew Moy, Martin Pool, Mark Triggs, Robert Widhopf­Fenk*, 

Masatake YAMATO, Milan Zamazal

The developers of XTLA enriched this niche category.*Joined to XTLA without being recruited.

After that...● Enough  developers  that  we  wanted  to  have  agreed  to   

merge  their  code  and  work  together,  so  there  was  no need to recruit another any more.

● The end of April 2004： Set up  the project at gna.org. Gradually went back to Open Source development style. 

● May 24, 2005 : Version 1.0 was out.

Recruiting Source Development Method

Recruiting Source Development (RSD)● A Special form of Open Source Development(OSD)● Taking action to recruit developers, not  just waiting 

for them to join the project.● From "to be chosen" to "to choose"

– OSD： People decide whether to join or not by evaluating  publicly available source code and its project theme.

– RSD：WE decide whether to recruit him/her for our project  by evaluating his/her source code and project theme.

Selection of developers

● Do they have enough knowledge and skills in the area?  (example: Emacs lisp, GNU arch)

● Can they share the development goals with you? (in this case:  Did they know about pcl­cvs and want to develop a similar project?)

● Are they willing to cooperate in order to achieve the goal as soon as possible?

When contacting to a prospective developer*

● Carefully review the developer's work, and clearly explain to him/her the significance of merging.

● However, do not put so much pressure on that developer.

*From the interview with Mr. Foobar

After recruiting ● Encourage the recruited person to develop actively.● Recruiting activity should not be time­consuming for 

recruiters.● Helpful software：

– QuickML: Easy to use, and it provides a smooth process from recruiting to inviting a prospective developer to the mailing list.

– GNU Arch● Developers can work at their own pace.● Developers can look into peer's work very easily.

Conditions to apply RSD● Members agree that they want their products to be used 

by many people, and provide it as soon as possible.● The category should be young (not mature).

– RSD works well only among young projects.– Offer to merge from mature project to young project  threat.→

– Offer to merge from young project to mature project ridiculous→

● Members share the development goal.– When recruiting, it is easy to communicate using proper words.– Development speed may differ, but all developers look at the 

same direction.

Conclusion and future issues● Recruiting Source Development was proposed. ● The development process of XTLA was 

introduced as the project managed by RSD method.

● RSD method is not a perfect solution to the whole “dead­end”  category    problem.    However,  I would like to raise the awareness of this problem and introduce this method to the world.

Acknowledgments

The author would like to express his thanks to...● Shigeru AOSASA who encouraged me to publish 

the idea of RSD.● XTLA developers who gave me a chance to go 

through this advanced development process. ● Mr. Foobar who agreed willingly to be 

interviewed by the author.