Point 2: VISTA Requires Many Code Repositories, Not One

Dear Reader,

VISTA's bigger than you think it is - vastly bigger - by scales of magnitude. None of the numbers you can put next to it (files, programs, lines of code, function points) comes remotely close to its actual complexity and sophistication. The interaction of its intricate integration with its unparalleled extensibility creates intricate effects that VISTA depends on but that we don't begin to know how to measure. Fortunately we don't have to.

We just have to understand that it is very, very big, too big to be effectively managed as a whole, unlike most software in the world. Bluntly put, as a whole VISTA is unmanageable. If you try to manage VISTA from a single code repository, your VISTA codebase will stagnate and your productivity will fall over time. You'll know you've begun to grasp the scale of VISTA when the idea of a single, central code repository for managing VISTA literally makes you laugh. Until then, you're not even close.

Fortunately, you don't need to begin with a single code repository to manage a shared VISTA code base. The VISTA lifecycle sure doesn't.

Instead, we follow the traditional divide-and-conquer strategy that makes computer science possible. We break up VISTA into packages and manage each package with its own independent code repository. In our experience, this reduces the scale of the problem enough that a highly expert, dedicated team can almost - almost - keep up with the problem of managing just that one package.

So, throw away the idea of beginning your VISTA lifecycle management with a single, complete gold account, and replace it with the idea of many gold accounts, one per package.

Yours truly,
Rick

Point 1: VISTA Requires the VISTA Software Lifecycle

Dear Reader,

Over the thirty-two years of VISTA development, many, many different software lifecycles have been tried with it, and all but one of them have failed, sometimes subtly, sometimes spectacularly.

Interestingly, for the last fifteen years no one has consistently tried to follow that one proven model, and during that time every VISTA adopter has struggled with VISTA. Those who have deviated the least from the model, like Indian Health Service, have enjoyed the most success, and those who have deviated the most, like the Department of Defense (DOD), have suffered the most. Veterans Affairs (VA) makes the best test case to prove this point, since they have been at their most productive with VISTA when they followed the model, and at their least when they didn't.

From studying VISTA’s rich and varied thirty-two-year history, I draw this radical proposition: we should take the plunge. We should end the fifteen-year drought by completely following VISTA's own software lifecycle model, the one that worked.

Getting to know the VISTA software-lifecycle model will take time, because it is sophisticated, complex, undocumented, and no example of it exists today, but I am confident that the more you get to know it, the more you will come to agree with me that the weird qualities of this model exactly support the weird qualities of VISTA in a way no borrowed or adapted model ever can.

Of these first eight points, this is the simplest, the most important, and the least likely for anyone to believe. I wish that weren't true, because this is the crucial missed point at which most VISTA adopters went off the tracks since 1994. If you can resist the urge to "improve" a model you do not yet understand, if you can compel yourself to study it patiently as though it were complex enough to deserve your attention, then you can buck the odds and reap the rewards that come with it.

Yours truly,
Rick

Eight Essential Points

Dear Reader,

Let's begin with eight important points about the VISTA lifecycle, which I presented remotely at WorldVistA's nineteenth VISTA community meeting at the National Library of Medicine in Bethesday, Maryland. I lacked the time during that presentation to fully introduce these points, so let's do it here over the next eight days.

These points are:

1. VISTA requires the VISTA software lifecycle.
2. VISTA requires many code repositories, not one.
3. Managing VISTA requires many authorities, not one.
4. Users must directly control VISTA's software lifecycle.
5. Users and programmers need a shared forum.
6. VISTA's software stream requires many tributaries.
7. We should restart the lifecycle with just File Manager and Forum.
8. We need to declare interdependence and form a confederation.

Yours truly,
Rick

VISTA Lifecycle: Let Us Begin

Dear Reader,

"VISTA is a process, not a product," say VISTA hardhats, but what do they mean? Let's find out.

The process is called the VISTA lifecycle, and it only superficially resembles any other software lifecycle. To follow it, you have to change everything about your software support and development - how you fund it, how you design it, who's in charge, how training takes place, and more. If you're willing to make these profound changes you can accomplish amazing things with VISTA.

Although the VISTA community depends on this lifecycle, no one has documented much of it. Let's do it.

It's a complex subject. My best guess is that it'll take the rest of 2009 just to finish a first draft. Rather than wait while I write and publish a refined explanation, let's sort it out in the open, together, here, in this blog.

One caveat: everything in VISTA's lifecycle is connected. Anything that seems to make sense by itself is really part of a far more complex system, and the meanings of things deepen and change when you come to understand how they relate to everything else.

This is a deep subject that needs and deserves patience and persistence, that rewards them with the ability to change the world for the better.

Yours truly,
Rick

Small-capital Confusion

Dear Reader,

When I wrote "Capital Confusion," I was only able to demonstrate the use of small caps back to the Domesday book of 1086 AD, leading me to believe along with Robert Bringhurst that they were added to our standard writing system after lowercase was invented.

I have since learned that smallcaps go back much further than a thousand years. Indeed, they predate lowercase. The creation of lowercase by Dark Age scribes took centuries, with numerous alphabetic inventions along the way. Although most of these intermediate alphabets fell by the wayside once Alcuin and other Carolingian scholars refined the lowercase alphabet to something like its current form, two of them survived.

Uncial, also called insular, a unicameral alphabet, was developed largely by celtic Christian scholars and remains to this day associated strongly with Ireland, Scotland, and other celtic countries. If you look at an example of it understanding its status as an intermediate development between upper and lower case, you can see how it contains elements of both. It was not folded into our culture's standard suite of alphabets, but remains to this day a specialty alphabet used to create an emotional or cultural effect in the text.

Long before uncial, however, small caps were developed as one of the first of these intermediate alphabets. If you search diligently, you can find examples of ancient Roman inscriptions set in caps plus small caps. Unlike uncial and the other intermediate alphabets, small caps remained a standard part of the scribes' toolset, and later became a standard typographers' tool as well.

The small-caps alphabet's apparent obscurity or optional character today is a conceptual illusion created during the industrial, reductionist craze of the nineteenth and twentieth centuries, when small caps and lower case figures temporarily fell out of fashion. (In case you think the industrial attempt to purge these two elements of our writing system was reasonable, consider that they also tried to purge lowercase as well, to reduce writing back to all caps. DOES THIS IRRITATE YOU? HOW ABOUT NOW? HOW MANY PAGES OF THIS SHOUTING DO YOU THINK YOU CAN READ WITHOUT GETTING A HEADACHE?)

The absence of these two important typographic inventions was reinforced starting in the 1870s when Christopher Sholes's QWERTY keyboard became the basis for typewriter key layouts, which in turn became the core of the design for computer keyboards. This crude design omits numerous typographical characters - including text figures and small caps - leading the overwhelming majority of people to believe by default that Mr. Sholes's invention somehow defines the official character set of the English language. It does not. Many essential elements of our writing system - including entire alphabets - are missing from modern keyboards.

Small caps and text figures are essential to protecting the readability of the modern Roman alphabet, especially when we have come to rely so heavily on acronyms and numbers in our writing. The absence of small caps and lowercase figures appears normal to us only because we have become habituated to it. Type designers are decisively ending this industrial-era experiment in reductionism by including small caps and lowercase figures in most serious, professional typefaces produced since the 1980s.

Hence, if my recommendation in "Capital Confusion" to use small caps (when available) to set acronyms like VISTA appears eccentric or needlessly fastidious, I encourage you to broaden your horizons, to learn a bit more about the history of your own writing system, to remove the blinders you have taken for granted, blinders imposed on you without your knowledge or consent by people who did not have your best interests at heart.

For an excellent eighty-three-page introduction to typography, a quick and illuminating read, try Finer Points in the Spacing and Arrangement of Type by Geoffrey Dowding (ISBN 0-88179-119-9).

A better known and highly respected, more in-depth guide to typography is Robert Bringhurst's The Elements of Typographic Style (ISBN 0-88179-206-3).

Yours truly,
Rick

Postscript: Learning is good. Learn more.

Postpostscript: Questioning authority is good. Start with the authority your own assumptions, biases, and habits hold over your mind. Wake up.

Postpostpostscript: Subtlety, nuance, and mastering the details are good. Sweat the little things. Pay attention.

Postpostpostpostscript: The deeper point of this and the previous post is that we know much less about the world and ourselves than we think we do, that not only are we liable to make mistakes about complex subjects like VISTA, we cannot even get right such simple subjects as how to capitalize it properly or even the nature of our alphabet. An open and inquisitive mind eager to explore the unknown and to discover its own errors in fact and judgment is far better preparation for dealing with VISTA than any amount of confidence, experience, money, or political power.

Indeed, as we will explore in this blog, the greater your success with other ventures, the greater your odds of failing with VISTA, exactly because your success leads you to overconfidently trust in tried and true ways of looking at the world that fail badly when applied to VISTA.

Capital Confusion

Dear Reader,

The abbreviated name of the Veterans Health Information Systems and Technology Architecture, VISTA (named in 1996), is not the same as the unabbreviated word vista, meaning a view or prospect, an avenue or passageway opening onto such a view, or a mental view. Nor is it the same as the second word in the name Windows Vista (announced in 2005), which is a proper-noun form of the unabbreviated word, as is John Wall's business software and services company, Vista (formed in 1999). In English when we convert an unabbreviated noun into a proper noun, we capitalize just the first letter, as Microsoft and Wall have done here.

Our VISTA is like the abbreviated names for Volunteers in Service to America (formed in 1964), Ventura Intercity Service Transit Authority (formed in 1994), Visible & Infrared Survey Telescope for Astronomy (announced in 2000 and due to be completed this summer), and the emerging market Vietnam, Indonesia, South Africa, Turkey, Argentina. All of these names fall into that special class of abbreviations known as acronyms, words formed entirely of the initial letters of other words and hence capitalized entirely in uppercase, or smallcaps, or (as I will propose) in special cases in smallcaps with the first letter in uppercase, but never with a mix of upper-and-lower case.

That is, the name of our software is not and never was properly capitalized in text matter as VistA, despite the widespread practice even by the Department of Veterans Affairs (VA), WorldVistA, the VistA Software Alliance, and others.

Written English words appear in two different contexts, text settings and display settings, for which typesetters understand there to be two different sets of rules. Text settings adhere to the rules of English grammar, including capitalization. Display settings, such as advertising, title pages, logos, and so on, fall somewhere between text and art; the typesetter understands that the rules may be bent or stretched to adjust the emotional or aesthetic impact of the words. Although a great deal of thought goes into the design of display settings, so does a great deal of fad and fashion, which pass through the practice of display typesetting in waves so pronounced that most such work can be precisely dated later on. That is, what seems fresh today tends to seem fresh to everyone all at once; today's fresh is tomorrow's cliche. Current crazes include all-lowercase names and titles, rounded, wide, thin, sans-serif typefaces, and happy, shiny, friendly text treatments like reflections, glows, and shadows (spend some time searching the web for famous logos redone in Web 2.0 format, and you'll see what I mean; I'm especially fond of the Quaker Oats spoof).

Good or bad, all of this play with the rules is permitted in display settings such as logos, but not in text settings, not even with names in text. The logo of the television show Planet Earth may be in lowercase Helvetica Extended Thin, but in text matter the name is capitalized like any other proper noun. The film with the name Seven had a logo in which the v was replaced with the numeral 7 like this: SE7EN; this distinction between names and logos so confounds most of us that to this day otherwise educated fans of the film will pounce on anyone who spells the name correctly and insist they misspell it as the logo does. When this kind of confusion occurs, when a writer loses track of the difference between a name and a logo and begins using logo treatment in text, the result is called a logogram, a logo masquerading as a word. In The Elements of Typographic Style, master typographer Robert Bringhurst sums up the problem with logograms like VistA:

Logograms present a more difficult question. An increasing number of persons and institutions, from e. e. cummings to WordPerfect, now come to the typographer in search of special treatment. In earlier days it was kings and deities whose agents demanded that their names be written in a larger size or set in a specially ornate typeface; now it is business firms and mass-market products demanding an extra helping of capitals, or a proprietary face, and poets pleading, by contrast, to be left entirely in the vernacular lower case. But type is visible speech, in which gods and men, saints and sinners, poets and business executives are treated fundamentally alike. Typographers, in keeping with the virtue of their trade, honor the stewardship of texts and implicitly oppose private ownership of words.

Logotypes and logograms push typography in the direction of hieroglyphics, which tend to be looked at rather than read. They also push it toward the realm of candy and drugs, which tend to provoke dependent responses, and away from the realm of food, which tends to promote autonomous being. Good typography is like bread: ready to be admired, appraised and dissected before it is consumed.

The VA's first VISTA logogram in which the "IST" are sloped smallcaps (which cannot be reproduced elegantly on the web without a picture) is the fault of the VA, which introduced it into its documentation shortly after the name was announced; it would have been fine (if not especially effective) as VISTA's logo, but it was hardly ever used as such, mainly as a logogram in text settings. It also was not presented as the abbreviated name, which had already been established to be VISTA, but instead was inserted without explanation in most text settings in place of the name. Although individuals, organizations, and their commercial products are legally allowed a wide latitude in how their names are capitalized, in practice even if you include all the name syntax variants of all cultures that use the Latin alphabets, there are still only a narrow range of variations in capitalization; if you capitalize very much outside that narrow range, the results are unnatural and distracting. This first VISTA logogram is well outside the natural range of capitalization for names, as are e.e. cummings and WordPerfect (the proper capitalization for each stage in the evolution of such a compound word would be from Word Perfect to Word-Perfect to Wordperfect; cf. Coca-Cola). Further, if you look closely you will notice that the middle three letters are not just smallcaps but sloped, i.e., pseudo-italic; requiring italic or sloped treatment of letters is perfectly permissable in logos but well beyond the pale for names.

The web version of the VISTA logogram (which the VA currently uses on its VISTA Monograph Homepage and elsewhere) unable to reliably produce smallcaps in a webpage, keeps the sloped capitals for "IST" and bolds the "V" and the "A." Go look at the text on that webpage now to see how the resulting logogram, especially its first and last letters, dominate the surrounding text, utterly distorting the flow of the text.

The logogram "VistA" is largely my fault. When I was first exposed to VA's VISTA logogram, I knew little about typography and had been steeped enough in commercial culture to accept such grammatical violations, so when I referred to VISTA in e-mail settings lacking the capacity for smallcaps or italics I coined "VistA" in an attempt to capitalize VISTA "correctly." In the roughly ten years since its introduction, I have written and taught a great deal about VISTA, and I'm afraid I've been something of a Johnny Rotten-Appleseed where the proliferation of this third VISTA logogram is concerned. I could trace out the sequence by which first many hardhats within VA, then WorldVistA, then VA itself, and then the VistA Software Alliance adopted my incorrect approximation of VA's logogram, which itself was poor grammar to begin with, but to make a long story short, I hereby formally apologize for leading us all further into grammatical error.

As penance, I pledge to work to educate people and organizations as to the correct capitalization of the name of our software and our new organization. The following guidelines apply to text settings, since in display settings you are restricted only by the bounds of creativity and (if we are lucky) good taste. The VISTA Expertise Network does not insist others follow these guidelines, only that we do.

First, it will probably never be proper to use roman lowercase anywhere in the name VISTA. Although laser and radar traveled the road from allcaps acronyms to lowercase unabbreviated words, they were neologisms and so did not have to displace existing English words to make their metamorphosis from acronymic abbreviations to unabbreviated words. VISTA by contrast deliberately echoes the English word vista, and so cannot ever lose its capitals without creating confusion. This rules out our software ever being referred to as vista or Vista, and the rules of good grammar rule out any logogrammatical mixtures of upper and lowercase such as VistA.

Second, it is always acceptable to fall back on the default capitalization for acronyms, all uppercase (aka "allcaps"), such as VISTA. In inadequate text settings that offer only a bicameral alphabet (upper and lower cases), we are forced into a choice between overly emphasizing acronyms with uppercase and confusing them with unabbreviated nouns with lowercase; the noise of distortion is preferable to outright confusion, so allcaps is the preferred capitalization of the name VISTA in bicameral settings such as e-mail and websites.

Third, to blend acronyms like VISTA with surrounding lowercase text without introducing confusion, smallcaps are the preferred capitalization. Although typewriters, keyboards, and English teachers would lead us to believe that English is a bicameral alphabet that marries an uppercase and lowercase to create a whole alphabet, English is actually tricameral, including a third case: small capitals. That case has been with us for at least a thousand years, almost as long as uppercase and lowercase have been married (only about two hundred years longer); for example, a close examination of the Domesday book of 1086 reveals the use of smallcaps in place names throughout the text. English has been tricameral (upper, lower, and smallcaps) for five- to six-hundred years longer than we've had italics (introduced in the late fifteenth-century Renaissance) and about nine-hundred years longer than we've had boldface (introduced during nineteenth-century industrialization). In ordinary usage we tend to ignore the smallcaps case, mostly out of ignorance but partly out of sloppiness; however, when setting type carefully, the third case becomes useful for subheads and other special kinds of emphasis and essential for properly setting acronyms within lowercase text. True smallcaps, carefully designed to match weight and color with the other two cases, are vastly preferable to the spindly pseudo-smallcaps word processors tend to generate when you "apply the smallcaps attribute" to lowercase letters, but even pseudo-smallcaps are preferable to allcaps because at least they eliminate the shouting effect of allcaps acronyms. In this era of proliferating acronyms, unless we want our text pocked by shouting allcaps acronyms or whispering pseudo-smallcaps, we need to choose typefaces that include the capacity to properly render all three cases of English, and we need to choose document formats that preserve our typeface choices.

Fourth, likewise, when acronyms like VISTA appear in boldface, the preferred capitalization is boldface smallcaps; when in italics, sloped smallcaps are preferred. In either situation, when smallcaps are unavailable, bold or italic allcaps, respectively, are acceptable if not optimal. Very few typefaces include true sloped smallcaps, but given their importance for setting text that includes both acronyms and italics, it is worth choosing one of those typeface for such text; very few support bold smallcaps, even fewer support both bold smallcaps and sloped smallcaps, and only very unusual typefaces (like Optima nova) support both those and bold-italic smallcaps. The OpenType font revolution is increasing the availability of such typographic features but still has a long way to go to reach the full needed range of features to gracefully handle acronyms in all text situations.

Fifth, given the use of smallcaps to handle acronyms with the goal of achieving textural compatibility with lowercase, I follow another guideline I have seen no one else advocate: capitalizing the initial letter in an acronym when it would have been capitalized had the word been lowercase, such as at the beginning of a sentence, at the start of a quotation, when set amid titlecase unabbreviated words (such as certain titles, heads, and subheads), and so on. It completes the blending of acronyms with unabbreviated words to have them both follow the same rules for capitalizing the word, and is certainly less disruptive than either reverting to allcaps or to remaining strictly smallcaps in situations that cry out for an initial capital.

After all this discussion about capitalization, some of you are wondering "Why bother? Who cares? It's just nitpicking. Don't sweat the little stuff." The answer is that you care, whether you realize it or not, for three reasons.

The rules of capitalization evolved to reduce the strain of reading, which is after all an unnatural act. Through trial and error, we learned that lowercase roman is easiest on the eye, and the other cases and styles need to be used sparingly, especially uppercase, each to perform its own specialized modification of the text. The proliferation of acronyms has increased the irritation of reading text in which they occur, like little pointless shouts, overly mannered and exaggerated. Proper use of smallcaps with acronyms helps soothe that subtle irritation, and after all, we do not particularly want the name of our software to be irritating if we can help it.

Also, the rules of good manners evolved to reduce the strain of interacting with other human beings by having them show you little courtesies in any interaction, a show of respect, like spelling and capitalizing your name correctly. If others cannot be bothered to get your name right, it means they do not respect you enough to make even a minimal effort at courtesy, so any further interaction would be a waste of your time. If, on the other hand, you cannot be bothered to get your own name right, well that leads to my third point:

Finally, sweating the little stuff distinguishes engineers from civilians. The craft of engineering is the art of achieving a big-picture accomplishment by attending to all the small-detail steps correctly. If engineers did not sweat the little stuff, you would be dead many times over by now. If we care enough to get the details right in our engineering, then it behooves us to get the details right in our communication so that we correctly convey to our audience our passion for excellence and our attention to detail. There's nothing like misspelling your own name to make others wonder if you really know what you're doing.

Sincerely yours,

Rick Marshall
Executive Director
VISTA Expertise Network

Postscript: For a fairly extensive listing of all the vistas out there, check out Wikipedia's page at en.wikipedia.org/wiki/Vista.

VISTA

Dear Reader,

The subject of this weblog, VISTA, has no name. The name "VISTA" names part of this subject for part of its time, but it does not name all of it nor even most of it, and it has not always been the name of that part nor even for most of its history.

In the beginning it had no name. Amazingly, those who fought their David-and-Goliath battle to bring VISTA to the world merely described it rather than naming it, almost unthinkable in this era of branding urges so powerful we had to coin the term "vaporware" for our empty software names. Instead, the fathers of VISTA offered us abundant anonymity, a wealth of medical informatics with no name.

Ted O'Neill and Marty Johnson, two of the fathers of VISTA, called the software their team built "MUMPS systems," since they were written in the American National Standard (ANS) dialect of the Massachusetts General Hospital Utility Multi-Programming System (or Standard MUMPS, now also referred to as Standard M); they also referred to them as the "VA MUMPS medical systems." They also called the various VISTA packages "hospital-based programs," to distinguish them from the programs developed by their central-office competitors, the Office of Data Management and Telecommunications (ODM&T, also called "the enemy" by the brave hardhats of those lean years). The hardhats sometimes referred to their work as "committing portability," again to distinguish their work from the vendor-specific, nonportable software created by the ODM&T bureaucrats. Sometimes they referred to their work as the "DM&S systems," referring to the Department of Medicine and Surgery (comparable to today's Veterans Health Administration, VHA) within the Veterans Administration (VA, today's Department of Veterans Affairs) and thereby to their own work created by DM&S personnel to meet their own needs. The DM&S office Ted, Marty, and the early hardhats worked out of before being driven underground was called the Computer Assisted Software Staff (or CASS), so sometimes today we refer to their work as the "CASS system." Although CASS was a centralized office within DM&S, most of its developers worked remotely in the field at VA Medical Centers, so they often referred to their software as the "field-developed systems" or the "DM&S field-developed systems." The generic term Marty Johnson used as the subject of his historic June 10, 1981 memo was the "DM&S Medical Information Systems," and he described the emerging MUMPS medical applications as making up a prototype "VA Health Care Information System" (HCIS).

Today, the terminology needed to describe the approach they used has become much richer—eXtreme Programming, rapid prototyping, user-driven development, open-source development, and on and on—but at the time their work was original enough that their theoretical framework was described in terms of the papers, memos, and studies that guided them to attempt what they did. At the time, they often used the general term "the VA approach" to sum up their strategy, though that has to be understood as in contrast to "the official VA approach" of expensive, vendor-dependent, piecemeal juggernauts created by ODM&T. The absence of a name compelled them to discuss and consider the significance of what they were doing, leaving them rich in understanding but poor in such public-relations tools as branding.

In 1982, the VA rebranded the VA MUMPS systems as the Decentralized Hospital Computer Program (DHCP), and in 1996 re-rebranded them the Veterans Health Information Systems and Technology Architecture (VISTA). Sometime in the 2000s, VA re-re-rebranded the system HealtheVet (pronounced Healthy Vet), and then later re-re-re-rebranded it HealtheVet VistA (or HealtheVet-VistA, the punctuation varies), with an additional re-re-re-re-rebrand aimed beyond the VA called HealthePeople-VistA.

The VA's version of VISTA is just one dialect of a family of related medical information systems all ultimately derived from the CASS team's work. When the U.S. Indian Health Service adopted VISTA, they named their revised version of it the Resource and Patient Management System (RPMS). When the U.S. Department of Defense adopted VISTA, their revised version of it was named the Composite Health Care System (CHCS). The Finnish consortium that adopted VISTA before even the VA did named their version of it MUSTI. The Nigerian consortium that adopted VISTA named theirs the Made In Nigeria Primary Health Information System (MINPHIS).

When WorldVistA began working on VISTA outside the VA, they called their work OpenVistA, the name that the Medsphere Corporation trademarked and made their own. When the U.S. Department of Health and Human Services (HHS) launched their initiative to make a free version of VISTA available for clinics and doctors' offices, they dubbed their version VistA-Office EHR. Later, after commercial EHR vendors politically sabotaged the VistA-Office EHR initiative, WorldVistA built upon that work to create WorldVistA EHR, the name of the version for which WorldVistA has had responsibility ever since.

There are more dialects of VISTA than this, and more names, but surely this is enough to understand why there has been a backlash against this balkanization of terminology and against the VA's passion for rebranding. The community has embraced the name "VISTA" reflexively, out of resistance to this pointless confusion, in an effort to nail down a coherent, sufficiently embracing identity for this vital legacy of software and culture. It is not good enough, not complete enough, does not clearly enough put its nominalist finger on the core of that identity, and it has to struggle against the partly negative, obscurantist intentions that led to that rebranding, but it partly transcends these things, has a positive enough connotation, was coined by worthy and well-meaning people, and in the end above all, VISTA is a good enough name for us to build our identity around. So we have.

Sincerely yours,

Rick Marshall
Executive Director
VISTA Expertise Network