<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:SimSun;
panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
{font-family:SimSun;
panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:"\@SimSun";
panose-1:2 1 6 0 3 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
{mso-style-priority:99;
mso-style-link:"Plain Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
span.PlainTextChar
{mso-style-name:"Plain Text Char";
mso-style-priority:99;
mso-style-link:"Plain Text";
font-family:"Calibri","sans-serif";}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoPlainText>Part 2<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>Claire also mentioned the interoperability of FLEx, and I'd like to talk a bit about that. And I’ll watch my pronouns this time.<o:p></o:p></p><p class=MsoPlainText><span style='color:black'><o:p> </o:p></span></p><p class=MsoPlainText><span style='color:black'>The lack of interoperability has been my largest concern since I left the FLEx team 6 years ago. Before we can talk usefully about interoperability, though, I think we need to step back and find out how FLEx ended up less interoperable than it might have been. In my view, the largest factor is that we followed our customers blindly.<o:p></o:p></span></p><p class=MsoPlainText><span style='color:black'><o:p> </o:p></span></p><p class=MsoPlainText><span style='color:black'>If we look at the early posts in this thread, we see some agreement that it would be nice to have a do-it-all linguistic application. This fits squarely with what the FLEx team hears constantly from its users. Ask a group of users "would you like our app to also do X, or would you rather use a program designed especially to do X really well?", and in my experience the vast majority will say "build X in, please. We don't want to learn another program". And so FLEx set out to get all the our data in one pot, all the tools in one place. This appeared to be common sense at the time. After all, you could then have all the data nicely linked together, data could be normalized so that everything was always consistent and representative of your very latest analysis, etc.<o:p></o:p></span></p><p class=MsoPlainText><span style='color:black'><o:p> </o:p></span></p><p class=MsoPlainText><span style='color:black'>But there are many downsides to that approach. And now that FLEx has succeeded in terms of “market share”, these problems are even more clear. They include:<o:p></o:p></span></p><p class=MsoPlainText><span style='color:black'><o:p> </o:p></span></p><p class=MsoPlainText><span style='color:black'>* It is difficult to give each area the attention it deserves when you try to do many things in one free product, developed by volunteers, and can't add development staff as the product grows. So some areas remain shallow. Enough to tantalize, as others have indicated, but not enough to satisfy many.<o:p></o:p></span></p><p class=MsoPlainText><span style='color:black'> <o:p></o:p></span></p><p class=MsoPlainText><span style='color:black'>* The code itself can become so large and overwhelming that your open-source efforts don't pay off; no one has the time to get their head around enough of the system in order to contribute.<o:p></o:p></span></p><p class=MsoPlainText><span style='color:black'><o:p> </o:p></span></p><p class=MsoPlainText><span style='color:black'>* It is difficult for others, more passionate or knowledgeable about an area, to contribute a tool which does go deep in some area.<o:p></o:p></span></p><p class=MsoPlainText><span style='color:black'><o:p> </o:p></span></p><p class=MsoPlainText><span style='color:black'>* When others do manage to create complementary external tools, the tight integration of data makes it difficult to interoperate with the external data. The models never quite match, the notion of ensuring data consistency is challenged, etc.<o:p></o:p></span></p><p class=MsoPlainText><span style='color:black'><o:p> </o:p></span></p><p class=MsoPlainText><span style='color:black'>Borrowing metaphors from a well-known essay on the Open Source paradigm, I began thinking of FLEx as a <i>Cathedral</i>, when I wanted to be shopping among stalls in a <i>Bazaar</i>. We started talking internally about the downsides of our customer-driven cathedral tendencies, recognizing the benefits of a bazaar eco-system of interoperable linguistic software. Though their customers surely would not agree, many of my colleagues/superiors came to share this perspective, and now lend their support to opening up FLEx while stopping its expansion into new territory. Unfortunately, we now are faced with whole new sets of engineering problems that few users would understand, and which I won’t bring up here. If any of you are into <i>ontologies</i>, we’re looking at the promise of RDF, OWL, etc. as an alternative to traditional xml models in order to facilitate interoperability.<o:p></o:p></span></p><p class=MsoPlainText><span style='color:black'><o:p> </o:p></span></p><p class=MsoPlainText><span style='color:black'>Ok, so some of us have come to think that our customer is actually best-served in a healthy ecosystem of interoperable choices, and we can point to some movement away from the kitchen-sink approach. FLEx was too complicated for non-linguist native speakers, so a couple of us created WeSay (which interoperates with FLEx using LIFT xml). FLEx lacked phonological analysis, and happily two of my colleagues instead built a new Phonology Assistant, which interoperates with FLEx & Toolbox. Our target users needed a different approach to language documentation software, but we started SayMore instead of adding features to FLEx. There are a couple of us arguing that syntax and discourse analysis should be spun out of FLEx into their own programs, where they can grow with more individual love and attention.<o:p></o:p></span></p><p class=MsoPlainText><span style='color:black'><o:p> </o:p></span></p><p class=MsoPlainText><span style='color:black'>Now, so long as the only things that SIL apps interoperate with are other SIL programs, we don't really have a bazaar. A tiny shopping mall, maybe. <o:p></o:p></span></p><p class=MsoPlainText><span style='color:black'><o:p> </o:p></span></p><p class=MsoPlainText><span style='color:black'>Why is this important? For one thing, when FLEx’s model doesn’t fit the needs of the language under study, then those researchers are stuck; it’s all or nothing. Maybe they go back to the trailer park, maybe they lose an important distinction and their analysis suffers. That’s one of the reasons why, as we added annotation features to SayMore, we went with ELAN’s existing file format rather than enhancing FLEx’s nascent xml interlinear format. We know that we don’t want to provide ELAN’s power or flexibility. So by using the same file format, it’s easy to organize your media, metadata, & informed consent with SayMore, even do annotation there, but if you need more power, great, a double click opens the annotation file in ELAN. But we were lucky… it’s not often that we find that a format designed for one program that suits the needs of another.<o:p></o:p></span></p><p class=MsoPlainText><span style='color:black'><o:p> </o:p></span></p><p class=MsoPlainText><span style='color:black'>Another reason is that there’s not enough programmers in this space to do several kitchen-sink applications, targeting different personas. As a software designer who spends half my time designing for subsistence farmers and the other for researchers, let me say that it is rather difficult to make great tools if you target too wide a range of users, particularly with limited resources. SIL's developers are volunteers who make a fraction of market wages and have to raise all of that money themselves, even giving 10% of our income for administrative overhead. It should be no surprise, then, that there are few of us, and we don't have the resources to serve the needs of every kind of user. A healthy software ecosystem, then, must have SIL as just one source among many. Where our software raises the "cost of exit" by making it hard to move your data elsewhere, it is harming that ecosystem. Where it promotes existing open file formats (ELAN), or promotes new ones (LIFT) it's helping that ecosystem.<o:p></o:p></span></p><p class=MsoPlainText><span style='color:black'><o:p> </o:p></span></p><p class=MsoPlainText><span style='color:black'>One last note, <a href="http://scholarspace.manoa.hawaii.edu/handle/10125/5239">raised by Christopher Cox</a> at the LD&C conference in February: it can be hard to fund software maintenance long-term with normal research funding models. To encourage diversity, I would like to see others, without SIL’s odd funding system, have a way to be paid long term to develop, maintain, and support linguistic software. I would like to see linguistic research proposals include funds to give to the developers of the tools used, to fund further development. <o:p></o:p></span></p><p class=MsoPlainText><span style='color:black'><o:p> </o:p></span></p><p class=MsoNormal>John Hatton<o:p></o:p></p><p class=MsoNormal>SIL International Language Software Development, <a href="http://palaso.org/">PALASO</a>, and <a href="http://pnglanguages.org/">SIL Papua New Guinea</a><o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoPlainText><span style='color:black'><o:p> </o:p></span></p></div></body></html>