The Software Observatorium

Google's Summer of Code 2006

Fri, 14 Apr 2006 21:56:27 GMT

It looks like Google is hosting another Summer of Code. From the FAQ:
Summer of Code 2006 is a program that offers student developers stipends to create new open source programs or to help currently established projects.

It was reported as big a success last year and there is already a bit of excitement on the IRC channel. If you are interested in participating as a student or a mentor, check it out as the deadlines for applying for both positions are fast approaching. Yay for open source!

Candidacy Paper Abstract

Thu, 08 Dec 2005 03:38:10 GMT

From the paper that won't end, I bring you, an abstract! There are three topics: data available in OSSD, processes executed in OSSD, and tools/techniques that might help analyze the data to extract the processes. The horrid length of time it's taking me to write the paper can be blamed directly on this three-pronged attack and the time spent weeding out would-be fourth (and beyond) prongs. Without further adieu...

In their 1993 study of software process capture and analysis, Alex Wolf and David Rosenblum argued that a hybrid, manual and tool-aided, approach to capturing process data is necessary because purely automated approaches are “intently biased towards the computerized aspects of processes, while purely manual approaches are inefficient for high volumes of data.” [Wolf and Rosenblum, 1993]. Since the time this statement was made, more and more aspects of development have become computerized. This is especially true in open source software development communities where most if not all development is computerized. With computerization came tools for analyzing structured aspects of the new data., including workflow mining tools such as Balboa, developed Dr. Wolf's future student Jonathan Cook. Worklow mining efforts produced many fruitful results in the latter half of the 1990s and beyond, and is well complimented by a flourishing breadth of tools mining other dimensions of software repositories. These tools, however, fail to incorporate unstructured data in software repositories, thereby providing an incomplete characterization of the processes (and other phenomenon) they discover. The purpose of this paper is to examine tools and techniques for automating the analysis of semi and unstructured data to compliment the results already achievable via structured analysis of software repositories in order to discover software development processes. In doing so for the reasons above, and more explained below, this study also takes in in-depth look at data available and processes enacted in open source software development (OSSD). The goal is not to prove that discovery is completely automatable for any or every process, but merely to see what can be achieved with current unstructured data analysis technology.

Open Office Migration

Wed, 12 Oct 2005 21:11:23 GMT

I've recently decided to try making the switch to open office, with the upcoming release of version 2.0. For my purposes, it seems to have a lot of potential, but the learning curve has proven steeper than I'd hoped for. As I'm prone to forget how to solve the various challenges I've faced thus far, I'm going to try documenting them here. In no particular order:

1. The Style Manager governs all.
Never forget this. If you're planning on working on a decent sized document, don't even bother trying to change things willy nilly using the font size, style, and so forth on the menus at top. That will only lead to headaches down the road. The Style Manager governs character formatting, paragraph formatting (which includes character formatting of its own- not sure this was a good design decision as it could lead to confusion; I just mirror paragraph and character formats to be safe, which I probably don't need to do). It also governs page layout, including margins, lists (you can create your own list styles!), and whatnot. In that sense, it's very CSS-like. The result is that you must use these styles religiously. This also means that a good template will serve you well. I'm not quite sure what happens when you create a document from a template and later change a style within the template, if that gets reflected back into the document. But, since I'm only using my template for one paper, I'm not terribly worried. On the subject of the style manager, I found that sometimes my custom styles didn't appear at random times. This appears to be a minor UI glitch that is easily solved by selecting another style category and then going back to the first. It's more likely that I'm really seeing the wrong category in the list box, but I've not given it enough though to investigate. No worries.

2. Modularity and Master Documents
My current paper is a survey of the background work needed for my future dissertation on discovering open source software development processes. It has certain sections, an early outline of which appeared on this journal. I decided that since they are in decent depth of their own, to make them chapters. Now, rather than have one long and complex document, it seemed a master document would be a better way to go, with subdocuments for each chapter (and, of course, the title page and references). This led to a several hour project to try to get the pagination and page formatting correct. It happens that page styles from imported documents into a master document aren't applied when the documents are imported. Nor do page breaks. There are ways to hack this using Text sections, but that's not the right way to solve the problem. The right way to solve it appears to be using paragraph styles. Since I wanted the title page to have thick margins on top and bottom (rather than using lots of newlines), I had to specify that the first paragraph style on the title page (in this case, I'd defined a paragraph style for the title itself) begin with a page break (styles & formatting->Paragraph Styles->{Style Name- in my case, Title}->Modify->Text Flow->Breaks, Insert Page Before, with Style {Title Page Style}). Double-clicking on the Title Page style in the Style Manager won't do it. Thus, if you want your first chapter to also start on a different page than the title page, you need its opening paragraph style to specify that it starts on a new page (with the appropriate page style for a chapter, or in my case, the first page of the chapter, since it has a different style than the rest of the pages in the chapter- no header and a thicker top margin; in this case, I had to specify that the {Chapter Page 1} style is followed by the {Chapter Page} Style and I believe this is done in the page styles section, rather than the paragraph styles section, but don't quote me on it). Also worth noting is that the master document styling supersedes all styles defined in subdocuments.

3. Headers and Footers
A nifty feature of open office that I couldn't figure out so easily in MS Word is how to select which pages get headers. In open office, however, you can specify whether a page style has a header or footer. I know it's possible in both Word and Open Office to have separate sections of page numbers for separate sections of text (e.g. use roman numerals for the preliminaries [such as the preface] and arabic numerals for the body of the work [starting again at 1]). I figured out how to do this quickly in Word, but I haven't yet figured out how Open Office does it (though, importing the Word document kept the numbering faithfully). I don't need this particular functionality for my candidacy survey, but I will for my dissertation. If I figure it out, I'll post it here.

4. Adding an underline to an entire line of text (without using spaces)
Style Manager->Paragraph {Select desired style}->Modify->Borders

5. Indenting a paragraph
Don't mess with tabs or the margin ruler at the top of the page. Stick to the style manager here too. That's all for now. I'll update with more as I go along. There are also several sites that do a decent job explaining how to use OOo, and forums for the gotchas. But if you remember only two things, remember Styles! and Templates! Word allowed me to get away without these (and frankly, they only got in my way), but no more.

Brief Updates

Wed, 14 Sep 2005 23:26:51 GMT

Well, I'm back after an internship hiatus. Sad to leave, as it was a good experience, but I have lots of work to do now that I'm back. My project updates page is up and running (and no longer static) and I'm turning my full focus towards my candidacy paper until that finishes. As such, development work is on hold. I'm hoping to have my candidacy paper finished by the end of October and my topic defense by the winter holidays. Still working on the precise schedule, though. I'll also have to see about committee member availability.

A brief bit of research related stuff- I read the chapter on "The Open Source Process" (don't get me started on that title) in Sean Egan's book on Gaim development and, interestingly enough, it features an organizational structure as a pyramid, in contrast to the onion diagrams we typically use. Interesting that he self-identified (perhaps even unknowingly ;) their organizational structure that way. Richard Gabriel and Ron Goldman also talk about the onion diagram in their book, "Innovation Happens Elsewhere: Open Source as Business Strategy."

Candidacy Paper outline

Sun, 07 Aug 2005 22:03:15 GMT

As part of my degree, I must write a survey of my field of study. In my case, the topic is discovery (and modeling) of open source software processes. I've included Free/Libre in the subsection titles, but I haven't studies free/libre projects much thus far. What follows below is my working outline (.doc version here. Feedback is welcome, by which I mean appreciated. I apologize for the formatting and the length. Keep in mind, it's a draft :)

Open Source Software Process Discovery
1.Abstract
2. Introduction
3. A Brief Tour of Traditionally Held Notions of Software Development Processes
3.1.Measurement ? {CMM, COCOMO}, Lifecycles, clean-room, Agile Methods {XP, scrum, the agile process, more…}, RUP (rational unified process)
3.2.The focus here should be on lifecycle models and modeling, rather than measurement
3.3.Intraorganizational processes
3.3.1.Intraorganizational
3.3.1.1.Technical
3.3.1.1.1.As below in OSS processes
3.3.1.2.Sociotechnical
3.3.1.2.1.As below…
3.3.2.Interorganizational
3.3.2.1.Technical
3.3.2.1.1.As below in OSS processes
3.3.2.2.Sociotechnical
3.3.2.2.1.As below…
4.A Primer on Open Source
4.1.Vary in size (LOC, number of individuals, etc)
4.2.Vary in motivation
4.2.1.Free Source
4.3.Open Source
4.4.Licensing discussion?
4.3.Vary in openness
4.4.Vary in terms of community composition
4.4.1.Unincorporated individuals
4.4.2.Foundations
4.4.3.Corporately-led/backed communities
4.4.3.1.NetBeans, Open Office, Eclipse, Apache & Mozilla?
4.4.4.Open source corporations (i.e. Mozilla Corp)
5.Software Processes Under Investigation
5.1.Intraorganizational
5.1.1.Technical
5.1.1.1.Requirements and Release
5.1.1.1.1.How are these processes different from traditional/textbook development processes?
5.1.1.1.2.Implications for process discovery
5.1.1.1.3.Implications for process modeling
5.1.1.2.Quality Assurance
5.1.1.2.1.How are these processes different from traditional/textbook development processes?
5.1.1.2.2.Implications for process discovery
5.1.1.2.3.Implications for process modeling
5.1.1.3.…
5.1.2.Sociotechnical
5.1.2.1.Role Migration
5.1.2.1.1.How are these processes different from traditional/textbook development processes?
5.1.2.1.2.Implications for process discovery
5.1.2.1.3.Implications for process modeling
5.1.2.2.Leadership
5.1.2.2.1.How are these processes different from traditional/textbook development processes?
5.1.2.2.2.Implications for process discovery
5.1.2.2.3.Implications for process modeling
5.1.2.3.Conflict Negotiation
5.1.2.3.1.How are these processes different from traditional/textbook development processes?
5.1.2.3.2.Implications for process discovery
5.1.2.3.3.Implications for process modeling
5.1.2.4.Control
5.1.2.4.1.How are these processes different from traditional/textbook development processes?
5.1.2.4.2.Implications for process discovery
5.1.2.4.3.Implications for process modeling
5.1.2.5.Collaboration
5.1.2.5.1.How are these processes different from traditional/textbook development processes?
5.1.2.5.2.Implications for process discovery
5.1.2.5.3.Implications for process modeling
5.2.Interorganizational Processes
5.2.1.Technical
5.2.1.1.Similar to above
5.2.2.Sociotechnical
5.2.2.1.Similar to above
6.Existing approaches to process discovery
6.1.Manual
6.1.1.Field-Study Ethnography
6.2.Automated
6.2.1.Event capture
6.2.1.1.Cook/Wolf
6.3.Hybrid
6.3.1.Inadequacy of existing approaches for FLOSS Process Discovery
7.Existing approaches to process modeling
7.1.Informal
7.1.1.Narratives
7.2.Semi-Formal
7.2.1.Flow graphs
7.3.Formal
7.3.1.Petri-nets
8.Requirements for Discovery and of FLOSS Process Discovery Techniques
8.1.AKA The framework
8.2.AKA Motivation for a Multi-Modal Approach to Discovery and Modeling of FLOSS processes
8.2.1.AKA The dissertation prospectus
9.Requirements for Modeling of FLOSS Processes
9.1.Towards a Multi-Modal Approach to Discovery and Modeling of FLOSS Processes
10.1.Discovery
10.1.1.Process Meta model
10.1.2.Process reference model
10.1.3.(Partially?) supervised index-based learning from events capture in context.
10.2.Modeling
10.2.1.Narrative
10.2.2.Rich Hypermedia + Use Cases
10.2.3.Flow Graph
10.2.4.Formal Model (PML)
11.Preview of A Promising Implementation (AKA Future Work)
11.1.PADME – Process Architecture Discovery and Modeling Engine
11.2.More on this in the Topic Proposal
12.Conclusions
13.References

Publication archive move...

Sun, 10 Jul 2005 21:49:17 GMT

Due to technical buggery, I've moved my publications to a server I have more space and control over. I've meta-refresh redirected my main publications page to the new server, but if, for whatever reason, you'd linked directly to a file, it's now broken. I tried to have apache redirect all queries to the new server, but it seems that functionality is disabled. Such is life. The new server is:

http://rotterdam.ics.uci.edu/papers/

I'm betting that no one with access to the machine will mess with things and they can live here happily ad-infinitum, so cross your fingers.

On a separate note, I'm going to go live with a more day to day research journal (rambling about design issues in my code and such) in September when I'll be able to set up the database on my server (it is remote from me at present and I disabled remote access) and keep this one for larger announcements. For now, the frontpage is here (with non-working links):

http://rotterdam.ics.uci.edu/journal/

ProSim05 paper

Sun, 26 Jun 2005 18:37:46 GMT

It occurred to me that I never posted my ICSE-ProSim paper to my pub list. Here it is:

» Jensen, C. and Scacchi, W. Modeling Recruitment and Role Migration Processes in OSSD Projects, Proceedings of the fifth workshop on Software Process Simulation and Modeling ICSE-ProSim, St. Louis, MO, USA, May 14-15 2005. (Abstract)[March 5, 2005]

Google Summer of Code

Sat, 18 Jun 2005 03:44:45 GMT

In case you haven't seen it, Google has expanded their Summer of Code program to allow more projects. I'm not sure if they're accepting more applicants or if they're handing out more awards to applicants who have already applied (my guess is it's the latter). Either way, it looks to be a great opportunity and I'm excited to see what comes of it.

Wil van der Aalst: Workflow Mining

Tue, 07 Jun 2005 03:09:14 GMT

Wil van der Aalst has done a lot of work in mining workflows. It's about time I put the link up to his research page. Vladimir Rubin and Wilhelm Schafer are doing workflow mining of source versioning repositories inspired (I think that's the best term based on our few brief conversations) by this work and business process mining, though I don't know if they have a research project Web presence yet. Enjoy!

SPW 2005

Mon, 30 May 2005 00:24:35 GMT

I've posted photos from SPW 2005 and my afternoon at the Summer Palace (after the workshop ended) here.

I'll have a writeup on the experience when there is more time (and more photos when I receive them).

Mon, 02 May 2005 20:59:03 GMT

Many of us have talked a lot about hosting snapshots of OSSD project repositories to share data sets among researchers, but I haven't heard of much in the way of action being taken. Certainly, there are issues associated with it (e.g. privacy). However, if we can overcome these, I'd like to make a list of web sites where researchers can go to grab a copy of these snapshots. If you've got such a snapshot and don't mind sharing it, drop the link in a comment below. I've got a server with a tiny bit of space if hosting it is a problem. If you're an open source project manager and are interested to know what the research community at large has to say about your project, send us a snapshot, and if we can, we'll put it up somewhere. With enough interest, these projects can serve as benchmarks for OSSD research down the line. One caveat- I'm not interested in hosting live projects. Try sourceforge for that.

Planet Floss is reporting that the OSS Conference in Genova has posted the program. It looks like our (Walt's, my, John's, and Margaret's) paper on Multi-Modal Modeling, Analysis, and Validation of Open Source Software Development Processes is being presented first on 12 July. There look to be a lot of exciting papers there and I can't wait to read the proceedings.

New versions of Lucene and Luke

Wed, 27 Apr 2005 18:41:38 GMT

I've posted jar files of my edits of Lucene 1.4.2 and Luke. They are works in progress and I've neither deleted out the half-implementations that didn't work nor commented it properly. But these should give you an idea of where I'm at. I'm thinking of putting some of the IndexCommander functionality into a Luke Plugin and incorporate the changes in Luke 0.6 at some point. Pre-indexing items (e.g. mail box spool splitting, etc) are still a work in progress. The same rules for executing the jars should still apply. Let me know if you have trouble. Lastly, be careful about outputting the list of terms (printdictionary) in the index... a 2GB corpus would have taken 4 years to output...

Jars you would need on your classpath:
junit.jar (JUnit - the highlighting and mbox mail spool splitting classes use this, though I could see eliminating this dependency)
ant.jar (Apache Ant)
log4j-1.2.8.jar (Apache Log4j)
PDFBox-0.6.7a.jar (PDFBox - for indexing PDF documents)
mysql-connector-java-3.1.6 (Mysql Java Connector - Used to output results to mysql)
mail.jar (Sun JavaMail)
activation.jar (JavaBeans Activation Framework - JAF)
eyebrowse.jar (Tigris eyebrowse project - used for parsing MBox mail spools)
commons-collection-3.1.jar (Apache Commons Collection)
velocity-1.4.jar (Apache Velocity)
jakarta-oro-2.0.8.jar (Apache-Jakarta Oro project)
geoserver.jar (Geoserver - I don't recall why, but I had trouble running it without geoserver once)

ISR Graduate Student Research Forum

Thu, 21 Apr 2005 19:55:54 GMT

The Institute for Software Research is hosting a graduate student research forum on 3 June 2005 from 9am-1pm. All graduate students from every university and stage of the degree program are invited to submit 3 page position papers to spark lively discussions at the student only event (no advisors allowed!). The web site also claims the following:

The primary goal of the Forum is to foster community and expose possibilities for inter-disciplinary collaborations by providing an opportunity for students researching various dimensions of software and information technology to come together, meet, interact, and discuss their activities with a diverse group of their peers. Specific areas of interest are listed below, but generally fall in the broader categories of software engineering, human-computer interaction, ubiquitous computing, social computing, and arts computation and engineering.

Participating students will receive valuable feedback useful in shaping their current research and informing their future research activities. To further promote interaction, we will also be hosting a competition for "Best Inter-Disciplinary Project Idea" among all participants and attendees focusing on the formulation of novel research directions.

Submissions are still being accepted! It's sure to be a wild and crazy time.

Brief project update

Tue, 29 Mar 2005 21:06:46 GMT

I decided to split off some of the pre-processing related tasks (e.g. decompressing archives and dividing mbox mail spools into individual message files) as a separate operation. Whereas previously, this was done during the indexing process, it makes better sense to have a pre-processing stage, where I prepare the corpus for indexing. This is followed by the indexing process, which turns each file-system document into a lucene document, and then there will be an analysis process, which looks at the lucene documents in terms of software artifacts, and outputs the development process. Such a breakdown makes sense both technically (it reduces resource requirements during each stage) and logically. In the provided examples, there is a long switch statement in lucene to process files according to their extension. However, it makes more sense to use a plugin scheme, where each plugin decides whether it should do something with a given file or not, and if so, it does it. In this setup, a file could be processed by multiple plugins (which may prove useful), there is great flexibility in extending processing methods for additional documents/software artifacts, and it simplifies the interface. The main operation iterates through the directory tree and calls the appropriate plugins for the current analysis stage (corpus preparation, indexing, or process mining). From a design perspective, the "everything is a plugin" strategy looks like it will work for corpus-preparation and indexing though I'm somewhat concerned about the process mining stage.

In other news, I've got parsing and splitting of mbox mail spools down, thanks to javamail and the tigris eyebrowse tool. I may not need eyebrowse at all, but the parsing methods it provides are what I was looking for. There are always trade-offs when deciding whether to implement my own solution to various development tasks. But in this case, the existing solution was easy enough to learn and the task had enough pitfalls that it didn't make sense to spend any more time reinventing the wheel. There's still a small bug for messages with unhandled character encodings that I have yet to work out. For some reason, when I get the message content via an input stream, a small portion of the middle of the message is appended to the end. It may be something small that I've missed or a bug, but my favorite search engine didn't find anyone with a similar issue and for my purposes, it's not going to make a big impact on the results. Most messages I've been looking at are properly encoded, so the resulting data noise is not significant. As such, I'm content, for the moment, to leave it as a known bug and move forward with development and camera-readying my ProSim, OSSC, and SPW papers.

Several small updates

Sun, 13 Mar 2005 02:03:43 GMT

Firstly, Walt's, my, John's, and Margaret's paper got accepted into the OSS Conference in Genova. This pleases me muchly. I'm a little bummed that I wasn't able to get a PhD symposium submission off to it, but there will be other opportunities for that. Final revisions are due by April 1 (that's not far off). Our ICSE-ProSim submission has been accepted and camera-ready copies of that are due April 7 (not much farther off). And, I've got to finish writing the addendum that didn't make our SPIP submission (SPIP FOSS submission- the director's cut featuring such deleted sections as "6.1" and "6.2"). It's a whirlwind sometimes.

Some interesting stories from this week on Slashdot:
Sociotechnical issues being wrangled in Mozilla. These observations strengthen our argument about Collaboration, Leadership, Control, and Conflict Negotiation Processes in NetBeans. Hence, I'm excited to have a rare peek behind the firewall (firefox?). I believe this also plays well into Margaret's work. Perhaps my addendum will address this.

Apparently, women are leaving IT. I know our institution has strongly encouraged women in computer science and there are a number of conferences, symposia and so forth devoted to this topic here and elsewhere. It seems to be a noteworthy topic of discussion. That's all I've got to say about that.

Social Structure and Centrality in FLOSS

Sat, 19 Feb 2005 20:45:47 GMT

Kevin Crowston and James Howison have an article on First Monday on social structure in free and open source projects based on a study of a number of sourceforge projects. It's good reading.

Useful references

Fri, 04 Feb 2005 22:12:19 GMT

UC Irvine ISR Open Source Software Development Research
MIT Open Source Research Repository
Syracuse Free/Libre Open Source Software Research
USC Information Sciences Institute

Rediscovering a good paper

Fri, 04 Feb 2005 02:15:18 GMT

While meandering around el internet looking for references for an upcoming paper, I came across a paper I'd already read before: "The Architecture of Cooperation: How Code Architecture Mitigates Free Riding in the Open Source Development Model" by Baldwin and Clark. It's a shame I didn't wander across it a while back when I was writing my HICSS paper, as I can see a great tie-in to some stuff I was trying to get at there. It wasn't a major point, by any stretch of the imagination, but I'm writing this as a note to keep the reference filed away should I ever revisit the HICSS topic. If the title sounds interesting, you can find the paper at the MIT Open Source Paper Archive here. That's all for now.

Lucene-Luke context searching and document opening complete

Mon, 24 Jan 2005 03:54:33 GMT

After some futsing (sp?), as Jack would call it, I've extended the Lucene-Luke tool with the highlight functionality. The upshot is that you can do a search for terms in the content of the document (still some gui connection stuff to work out on the analyzers and so forth of the search tab and searching other fields of the document). The table will show the "sentence" containing the term(s) you searched for (read a few terms prior to and following the keyterm). The prefix goes in one column, the term in the next, and the suffix in another. Double clicking on the row will open up the document in a Web browser. So much effort for so little. I'm putting it on my site, though, keep in mind that it's a beta. I should probably make the tab a plugin, but so it goes. Come to think of it, I should probably move some of my other lucene index commanding code to Luke plugins, but that will have to wait till there's more time. To run it, you need my current mangled copy of lucene 1.4.2 (I think I added all the changes to 1.4.3, but it's safer calling it 1.4.2- let's just say it wouldn't be pleasant to merging with the latest CVS) and my Luke 0.5x on your classpath. Then, just run java org.getopt.luke.Luke. Load an index. Maneuver to the 'kwicSearch' tab. Enter a term. Click 'search.' And, let me know if you find anything funny going on I haven't already commented on. Lastly, I don't advise using either of these jars for anything else. Stick with the official distros. I've got half implemented stuff in there, abandoned stuff, and a really cool index commander command line tool I've not finished yet (well, I like it- not finished and no documentation though). Stick with the official stuff. Seriously.

The Mozilla Release Process

Tue, 18 Jan 2005 21:04:03 GMT

I was glancing over Slashdot this morning and came across a post on the Mozilla release process. The Slashdot link is here. Asa Dotzler's blog with questions about the process is here. The answers are at this link. Good stuff.

Upcoming paper deadlines

Tue, 11 Jan 2005 07:10:45 GMT

The following deadlines may be of interest:

21 Feb 2005 Second International Workshop on Mining Software Repositories (ICSE-MSR2005): Submissions due
21 Feb 2005 Fifth Workshop on Open Source Software Engineering (ICSE-OSSE2005), St. Louis, MO, 17 May 2005: Submissions due
28 Feb 2005 ProSim 2005: Acceptance Notifications
21 Mar 2005 2005 Software Process Workshop (SPW2005), Beijing, China, 25-27 May 2005: Acceptance Notifications
21 Mar 2005 Second International Workshop on Mining Software Repositories (ICSE-MSR2005): Acceptance Notifications
21 Mar 2005 Fifth Workshop on Open Source Software Engineering (ICSE-OSSE2005), St. Louis, MO, 17 May 2005: Acceptance Notifications
04 Apr 2005 The fifth joint meeting of the European Software Engineering Conference and ACM SIGSOFT Symposium on the Foundations of Software Engineering
(ESEC/FSE2005), Libson, Portugal 5-9 September 2005: Technical Papers due
7 Apr 2005 Sixth International Workshop on Software Process Simulation and Modeling (ProSim 2005), St. Louis, MO, 14-15 May 2005: Camera Ready Versions Due
25 Apr 2005 2005 Software Process Workshop (SPW2005), Beijing, China, 25-27 May 2005: Camera Ready Copy Deadline
06 May 2005 International Conference on Information Systems (ICIS), Las Vegas, Nevada USA 11-14 December 2005: Paper Submission Deadline
15 Jun 2005 Hawaiian International Conference on System Sciences (HICSS-39), Kauai, HI USA 4-7 January 2006: Paper Submission Deadline

Aloha from HICSS 38

Wed, 05 Jan 2005 03:55:39 GMT

Hello all. In a fortunate twist, I have Internet access. Photos of the experience are being posted at here. The talk went splendid and I'll soon post it to my site. After the talk, we had a most gripping discussion of, among other things, the observance that publications in OSSD and new venues of publishing research in OSSD (e.g. FirstMonday) don't count for anything tenure-wise. Another topic of discussion was attempting to distribute data sets for papers along with papers. This, my colleagues(and I) believe will provide opportunities for extending the analysis of the data, leading to new and exciting insights. Our organizer, Kevin Crowston offered to use his wiki as a place to post links to interesting OSSD research and so forth. I'll post a link to it when he sends it out. Additionally, Walt and Les Gasser have been working on an article detailing with requirements for an open source data repository. It should be out in the next week or so and posted to the wiki. I'll have a link to this, as well, when one is available. While the MIT open source digital library has cataloged some really important work, I think it's essential that the workload of maintaining an online research forum (term used loosely) be distributed. For starters, it is tedious to maintain with the growing body of work. Secondly, an open content management system will help further develop a sense of community among researchers outside of conferences and workshops. And, if it isn't tied to one individual or organization, there's a greater likelihood that it won't die when that individual moves on to other work, retires, or the server in his basement/garage dies. But that is just scratching the surface. I guess we'll have to wait for the report as it's been too long since the Continuous Design workshops for me to remember every detail of the discussion as I first heard it. I'm highly interested in Greg Madey and company's work identifying linchpin developers across multiple communities, as well as the discussion on reuse. I'm hoping that this work will provide me with additional insights into discovering evidence of process integration and conflict as we see it in software ecosystems. I'll have cites to these when I have more time to write. While I'm at it, I'll also post dates for upcoming paper submission deadlines, as they may be of use to others of you in the research community. FYI there were 17 papers submitted to the HICSS OSS minitrack and nine were accepted.

The HICSS-38 Open Source Minitrack

Why do people make Open Source Software

Sat, 25 Dec 2004 05:45:35 GMT

Since this question comes up so often, I did a little googling this evening and as I come across good papers on the subject, I'll post cites to them here. If you've got a good cite that I'm missing, gimme a holler.

Hars, Andrew and Ou, Shaosong. Working for free? Motivations of participating in open source projects. System Sciences, 2001. Proceedings of the 34th Annual Hawaii International Conference on , 3-6 Jan. 2001 Pages:9

Bonaccorsi, A. and Rossi, C. (2004) `Comparing motivations of individual programmers and firms to take part in the Open Source movement. From community to business', Working paper Sant'Anna School of Advanced Studies Pisa, available online at http://www.druid.dk/ocs/viewpaper.php?id=15&cf=1

Yunwen Ye and Kouichi Kishida. Toward an understanding of the motivation Open Source Software developers. ICSE '03: Proceedings of the 25th International Conference on Software Engineering. Portland, Oregon. 2003. 419--429

On PhD Milestones

Fri, 10 Dec 2004 02:14:35 GMT

As I promised Andre (and since I have a headache and can't think about real work at the moment), here are some tentative notes on what are required of Software PhD students and when, as best I recall from my experiences and various discussions with others. As usual, the comment link is in the corner. The major milestones are as follows:

Milestone</font>	Details</font>
The Coursework	Learn the background work in software engineering.
The Phase 2 Exam	Exam testing ability to reason and analyze about software engineering issues.
The Survey Paper	A review of the literature/work in your area of interest in software engineering.
The Candidacy Exam	A talk, essentially defending your survey paper.
The Topic Defense	A talk defending the topic you plan to write your dissertation on.
The Dissertation	A paper discussing your contribution to the body of research in your field.
The Final Defense	A talk defending your dissertation.
The PhD Completion	Revision of the dissertation and submission to the university archive (library).

</p>

The Coursework

During the initial period as a grad student, your mission in life is to take classes. These courses will give you a solid background in the research in the different areas of software engineering. The coursework required can be found here. It looks like new students will be held by the Informatics-Software guidelines, however. In any case, beyond the required Software courses, there is a set of breadth courses that all grad students must complete. The list can be found here. Essentially, students need to take a Theory class and an Architecture/CAD/Hardware course, and a Software and Systems course. Software folks will, of course, fulfill the Software and Systems breadth requirement with their Software based coursework.

A tricky thing about taking courses is planning what to take when. Graduate courses can sometimes be offered haphazardly, though the faculty are working to better the situation. However, some, particularly specialty courses (e.g. 280 series Software courses) may be offered quite infrequently, such as once every two years. Others may only be offered once, period, due to shifting interests of faculty and students.

As exciting as taking courses may be, PhD students are also typically obligated to participate in the joy of teaching assistantship. The requirement, when last I checked, is three quarters of TA-ing, but I've heard rumors that it may have been lessened. I'm sure this is a written rule, but I can't find where it's written. The coursework page linked above, however, does state a requirement of having a paper of publishable quality. I'll just comment that if you finish your dissertation without having written at least one other paper of publishable quality, there's likely some larger problem that needs to be addressed.

The Phase 2 Exam

To complete the master's degree, students must finish their coursework and take either the phase 2 exam or write a Master's Thesis (in addition to completing coursework). PhD students are required to take the phase 2 exam.

The phase 2 (qualifying) exam is aimed at testing your knowledge of software engineering. It is generally taken once you complete your coursework (often at the end of your second year), but there's nothing stopping a student from taking it the first time it is held. On that note, it is currently held twice a year, generally at the beginning of December and again in June. In fact, it was held today. I honestly expected there to be more elation among the people who had just completed it, but maybe it hasn't sunk in yet. The exam, itself, consists of two sessions of question answering with a lunch break in between. The morning session features two questions, both of which must be answered. These are meant to be more general, in nature. The afternoon session features a number of questions on specific topics in software engineering, of which two must be answered. It's possible that the format could change, but the professor proctoring the exam will give you the specific parameters some time before the exam. Topics on the exam have included Software Architecture, Requirements, Testing, Safety, Processes, and more. The point of the exam is to judge how well students are able to think and reason about problems in software engineering. The Phase 2 reading list consists of several tens of important/influential papers and a few books as background material.

The reading list is updated from time to time, but its purpose is to provide students with a solid foundation of software engineering topics and developments. Rarely are exam questions directly focused on one particular paper or book, but the papers are often useful as cites in responses. Summaries are your friends. They don't have to be long and detailed, but a poll of one student taking the exam showed summaries to be highly effective as a method of retaining the information of any given paper, as compared to merely reading the paper without summarizing it. One exercise I found helpful when I was preparing was to come up with a thread or story that linked together several papers, even across subdisciplines. It also helps to do timed practice questions. Amazingly enough, it's fairly easy to come up with some good ones after going through the reading list and the exercise will also show you just how little time (and exhausting) an hour and a half per question can be. Most of my fellow students and I found that it took about three months to adequately prepare for the exam. Having a study group meeting every few days also kept me on top of the reading list. After the exam, the software faculty will score them and return the results to you. Much like rebate submissions, expect results within 6-8 weeks, though it's not all that rare for them to take longer. The faculty are working to keep this in check, as well. The scores given are as follows: No Pass, Master's Pass, and PhD Pass. A PhD Pass is required to continue on the road to your PhD. A Master's Pass indicates that your responses were good enough that you be granted a Master's Degree, but not continue on toward the PhD. In other words, (as I recall), you are familiar with the work that has been done, but did not do much with that knowledge. Another fatal flaw is writing a lot but failing to answer the questions. There may be other reasons yet for granting a Master's Pass, so if you find yourself on the wrong end of the grading scale, talk it over with the faculty. It is possible (and not unusual) to retake the exam once. Retaking it twice requires clearing some additional hurdles. My advice is to plan on passing the first time. To receive the master's degree, the student must file for graduation at the student affairs office once the requirements for the degree are complete.

The Survey

By now, you should be up to your elbows in research. Narrowing your research focus in scope further, the survey paper is a literature review of the important research that has been done in your particular niche of software engineering. In my case, it will be on software processes and open source software development, most likely. Maybe it will include some literature on existing methods of software process discovery if I decide that's the particular thread I want to pursue in my dissertation. There are a couple topics (not covered in my first post) that I have available to me given the work I've been doing. There isn't a set format to speak of for this paper, but often it serves as a starting point in the 'related work' section of the dissertation. By the time you finish this paper, you should be an expert at what has been done in your field. The next task, will then be to do something new (or finish doing something new and writing it up). This paper is followed by the Candidacy Exam.

The Candidacy Exam

The candidacy exam is a talk generally covering the body of work described in the survey, as I understand it. Students stand before a panel of five (the committee!) faculty members, one of whom must be from outside the department (school of ICS?). I believe the outside faculty member is there as a sort of quality control mechanism, or so it was described to me once. Faculty will ask pointy questions. The student will answer. Hopefully, someone who has gone through this pleasant experience will chime in with how long their talk was and how long the discussion lasted (hint). Then, the committee meets to determine whether the student knows the material properly. If so, the student is forthwith advanced to candidacy.

The Topic Defense

The topic defense is a talk proposing the topic for your dissertation. In some institutions, there is a paper associated with this talk. However, (correct me if I'm wrong) that is not the case here. The student is put before a committee of three faculty members, generally chaired by the student's advisor. If the committee is satisfied that the topic will sufficiently contribute to the body of work in the student's field, the student may proceed with the work.

The Dissertation

Your dissertation is a long paper detailing your contribution to the field of study. Your survey paper is often the basis for the related work section (chapter 2), but I believe it's possible to change your focus even after your candidacy talk. I don't have a lot to say about this step, as I'm not very close to it. That said, it's important to keep in mind what you want to do with your career after you graduate when selecting a dissertation topic. Some topics will be better suited to interests of academia (and certain parts of academia, at that) and other topics will be better suited to industry (and similarly, certain parts of industry). My advisor has always tried to set me up with flexibility in my career path. This is good as the further along I get in my work, the more open I become to different types of careers (e.g., academia, industry, and government work). There is quite a debate over the best tool to use in creating a dissertation. In many fields, Latex is the standard, though Microsoft Word is also common. Framemaker is also popular among certain colleagues of mine. From what I've heard and experienced, they are all subject to their plusses and minuses. These have led me to my current paper writing approach- using a word processor to do word processing and adding in the formatting, images, and other tricky things later. Until I get ahold of something better, I'm using Word. For the open source crowd, I'm not yet satisfied with Open Office to use it as my weapon of choice. Additionally, most publishers I submit to ask for Word documents (if not just pdf). As frustrating as it might be at times, I'd rather fiddle with Word directly than play the conversion game. My preferences, not yours. It's also strongly advisable to send drafts of your work to your committee members as you go along. This helps avoid costly and ugly surprises during the latter stages, in much the same way that it's good to have your users/clients see your software system before you deploy it on them. Some committees are faster at getting feedback to you than others. So there's that, too.

The Final Defense

The final defense is a talk on your dissertation, given after you submit it to your committee. The talk, itself, is about 45 minutes, if I recall correctly. The committee will then ask questions about the work and make sure that the work you've done is substantial enough to warrant granting you a PhD. When the question answering is complete, they will deliberate your fate. Regardless of whether they pass you, they usually have a set of revisions that must be made to the dissertation before it can be submitted to the university archives and all the paper work completed. If you planned ahead, you may have gotten much of this feedback early on in your writing phase and given a practice defense and the list of changes will be shorter, rather than longer. I'm told there's a dissertation manual at www.rgs.uci.edu, which is fairly complete. Go see that. Go now. Hurry along.

The PhD Completion

When all the requisite changes to your dissertation are complete and your committee is satisfied with your work, they'll sign off on the paperwork. You'll submit this to the appropriate authorities, and finally, you'll hand over a pristine copy of your final draft of your dissertation over to the library. Now, this is a complex task- enough so that the library offers workshops on the final administrative tasks of your PhD career every quarter. They send out an email about it in advance. Maybe someone who has experience with this workshop can chime in about it (hint hint). I'll assume your job search has already concluded and you have secured employment somewhere by now. I've heard of many students who have actually started these jobs before the paperwork is completed. That's a tricky situation. Oh, and don't forget to request an official letter from RGS that you're done and get a transcript and file for graduation so you can actually get your diploma. Finally, go nuts. It's over!

I don't get it! What do you do again?

Tue, 07 Dec 2004 02:11:35 GMT

It occurred to me that most people I interact with have no clue what I study. Goodness knows I don't keep my web page up to date, and few dare to read my papers. Hence this journal. The goal of this first post is, thus, to try to spell out in simple terms where my interests lie. Keep in mind that these will shift with time. But hopefully even the non-software inclined people out there in Internet-land will be able to get a basic idea. If not, there's a little link to post comments in the bottom corner. You can even post anonymously. So, here's your chance to ask questions. Have at it. You know you want to;) So with that in mind, let's begin. Oh, and don't expect this journal to have anywhere near the polish or coherence that my papers (hopefully) have.

The short version is that I'm interested in learning the steps by which developers within and between open source software development organizations make software. Read on for the longer version.

If I had to come up with some sort of hierarchical classification for my work, it would look something like this: computer science->software engineering->software processes->software process discovery->software process discovery within and between open source software development (OSSD) communities. For the moment, I will assume that you can figure out at least computer science and software engineering. If not, holler. So what are software processes, then. Software processes are business processes. They consist of the activities including planning, designing, building, testing, delivering (and other words ending in "ing") of business products- in this case software and the various resources that accompany it (e.g. user manuals). Process discovery involves figuring out what activities were/are/will be involved in the creation of software systems. As if that wasn't asking a lot to begin with, I'd like to know what order these activities were performed in.

So what about the within and between open source software development communities part? Not enough has been said about OSSD (and it's a good thing, too or else my work wouldn't be all that interesting to anyone, let alone you), and don't expect it to be said here either. Political, economic, and most other considerations aside, the idea behind OSSD is that software source code (the semi-human-understandable instructions that software engineers write to tell the computer what to do and when to do it) should be available. Available to whom, under what conditions, and why are all interesting topics of discussion, especially because there is little consensus on these matters. Moreover, there is a plethora of assumptions, which are quite incomplete, if not inaccurate about the hows, whys, and wherefores of OSSD. Before you ask, yes, it is possible to make a (comfy) living as an OSSD software-engineer, especially in the larger communities that have corporate sponsors (Netbeans, Mozilla, Apache, and Linux, to name a few). A lot of people are surprised when I inform them that OSSD communities do, indeed have software processes, which I find mildly amusing, if not a little discouraging. There may or may not be a process written down anywhere in OSSD communities (or within non-OSSD organizations, for that matter). But there are still processes. And these processes can be discovered. And we can compare them to whatever process-like documentation there may be written down. And these may not be identical. And that is interesting (at least to me). To discover these processes, we first looked over the web pages of a few well known communities (Netbeans, Mozilla, and Apache's HTTP server) and tried to piece things together. We examined web pages, email archives, bug reports, and anything else we could get our hands on. It was quickly apparent that this manual searching deal wasn't much fun, due to the effort-intensive nature of analyzing the massive quantity of data required to make projections about what process is being followed. This led us to seek ways of automating process discovery, by using software tools to do as much of the grunt work as possible. This will be the topic of most of my future posts, I imagine.

I digress. Few software development organizations operate within a vacuum, building everything from circuit boards to software systems from the ground up to be used within that organization alone. Therefore, organizations within any given industry that don't fall into the category above interact with one another. These relationships may be direct, explicit collaboration, competition, and coordination, or indirect or implicit, in causing and reacting to changes in the industry ecosystem. The degree of coupling between organizations seems to have implications for the degree of process integration between organizations. Additional information on these process relationships can be found in my ICSE-ProSim 2004 paper, so I won't get into too much detail here, given the SPIP revision is forthcoming. However, I've noticed that these processes are often difficult to observe, since much of the interesting stuff results from indirect and implicit process interaction.

There you have it. Now, find that comment button. It's just a little down and to the right.