by Well, I’m back. It was an incredibly hectic week at LISA, and I’m still digging out at work from being gone for the week. I hope to finally get all the pieces of this essay done in the next 2 weeks.
There have been lots of developments in the USENIX, SAGE and LOPSA relationships. I won’t try to cover any of them yet; the situation is still very fluid, and it remains to be seen how all this will pan out. I would have to say that overall, based on discussions I’ve had with various USENIX Board members, that I’m very optimistic that we will see significant collaborations between USENIX and LOPSA, going forward.
However, all this is playing out in the historical context of USENIX, SAGE, UNIX and the Internet. Seeing how we got here is still important, as LOPSA must take all this into account as it charts a new course for serving the system administration profession.
Remember that much of this was written months ago, so it does not fully take into account the recent events of LISA, USENIX, SAGE and LOPSA. It was written long before a lot of LOPSA planning had taken place, too.
Here is part three of why the USENIX and LOPSA communities are complementary and need each other. That the two organizations and communities will collaborate is as inevitable as their need to be independent to meet their proper goals….
(And drupal needs a spell-checker module!)
!! Trends, Forces and Outcomes
The communities and the organizations are the current outcome of years of technological and societal trends and forces.
In the past 30 years we’ve seen a lot of cycles. There have been several business cycles, certain technologies and themes have fallen in and out of favor. We’ve gone from completely centralized systems with dumb terminals, though fully decentralized (standalone desktop PCs), through specialized client/server architectures back to essentially centralized servers with dumb terminals (web browsers).
One theme that has run through all this is the movement of various flavors of a technology out of the lab, consolidating into fewer variants and becoming easier to use, and finally seeing wide adoption of a specific flavor in the mass market. This is a commoditization of the technology.
Some of the trends are easy to see, such as more computing power closer to the user, although now we use most of the client power to either play games or display data from a central service (the Internet). We’ve seen an ongoing commoditization of both hardware and software. From every vendor having multiple CPU architectures (in the 70s and 80s) we’ve come to the near-total dominance of the x86. From that it was a short step to the ubiquitous “1-U” server, all of which are nearly identical, available from hundreds if not thousands of vendors.
UNIX (or Linux, or POSIX) and Windows are the total commoditization of the software platform. Pretty much all that is left is either Windows or descendants of UNIX. Whether it’s Solaris, AIX, IRIX, *BSD or any of a dozen Linux distributions, it’s the only game in town, unless you want Windows.
It will be useful to look at the key technologies that concern USENIX and SAGE (and LOPSA): operating systems, especially those based on UNIX. We could also look at “Internet adoption”, but the history of UNIX-related technologies are much more important to the earlier history of USENIX and SAGE. Comparing the life cycle of these two technologies to the previously-identified communities might also shed some light on the ongoing rift between the core competencies and goals of USENIX and the interests of the system administration community.
And note especially: although UNIX-related technologies drove the creation of USENIX (and SAGE), LOPSA is explicitly stepping outside this box to address the needs of all system administrators. This was one of the fundamental reasons that a new independent ogranization was needed.
! The UNIX operating system and its descendants led inevitably to USENIX
UNIX began as a research project. If you want the whole story, its creators are USENIX members, and there are lots of books and articles detailing the humble beginnings. UNIX was not a product, it was built by and for programmers, or more specifically, by and for ”’researchers”’.
As UNIX escaped the laboratory and found a wider audience, it needed additional work to become more useful to more people. There was little documentation, and it was still quite rough around the edges. The UNIX community came together to ”’develop”’ UNIX into a technology that could be used to build systems to solve problems. As this community became larger and slightly more formal, USENIX was born. USENIX was truly one of the first virtual organizations that was created to develop (in the business sense of “bring to a widely useful state”) UNIX (and later UNIX-related) technology. The seeds of the Open Source movement were certainly planted and nurtured in USENIX soil, by the way.
As USENIX succeeded in its mission to make UNIX more useful, other people began to create ”’engineer”’) solutions using UNIX technology to solve real world problems. Electronic mail, FTP, software development environments: all were solutions built on UNIX technology (and some others, of course).
As the technology evolved, we saw it commoditize: variants came and went, a few survivors were more widely adopted, more people began to depend on it, and eventually UNIX (or at least its children) came to be a major part of the infrastructure we call the Internet. Along the way, the ”’operations”’ community came into being to deploy, monitor and repair all these critical services that were now running on UNIX technology.
See a pattern here?
(There were lots of social and legal drivers here, too, but those are fodder for some other essay, some other day.)
The USENIX community was there from the beginning, and they’re still around, still vibrant, still producing amazing results, but their roots are firmly planted in the academic and research soil in which they were born.
! Widespread deployment of “Information Technology” leads to SAGE (and then LOPSA)
As UNIX technologies, the Internet and “Information Technology” evolved, the USENIX (and others, like the “mainframers”) communities were evolving, too. More importantly, though, was the evolution of business and organizations as they embraced this new way of doing business, discovering new services they needed (or could sell).
In other words, what we (some of us) call “IT” has evolved in almost exactly the same way as UNIX technologies. It has come out of the research labs and become a critical infrastructure for most of the developed world. People depend on the Internet (and the underlying “IT”) for important tasks in their day-to-day lives.
IT came out of the bookkeeping and engineering and operations departments to become the backbone of most of today’s organizations. IT was commoditized. Some might argue that “IT” is really the engineering and operational layer of computer science, and that’s not a bad way to look at it.
! As USENIX was born from the evolution of UNIX, SAGE (and LOPSA) were born from the evolution of IT
As IT became more widespread, we needed people who were not researchers or developers to handle its care and feeding. Systems programmers (developers) in many cases evolved into system administrators, who took on the roles of engineering and operations. As USENIX members (researchers and developers) introduced their new systems into more and more places in their organizations, they either became or handed things over to system administrators, who took on the engineering and operations roles.
As USENIX members took on these roles, or brought people in these roles into USENIX, there came a need for a different kind of organization to allow the engineering and operations communities to organize and share information (mostly about UNIX technologies) just as USENIX had done for the research and development communities in the early days of UNIX.
USENIX ran its first system administration conference, the first LISA, as a workshop in 1987. SAGE was organized and created in 1992 as a “special technical group” within USENIX. There were never any other STGs.
And so SAGE, “the System Administrators Guild” was created, by the system administrator sub-culture within USENIX. (How did “SAG” become “SAGE”? Where did that “e” come from? That’s also another story…)
! The Triangle Changes
Over time, the ratio of people at the Research end of the triangle to those at the Operations changes. This is due to wide adoption, which requires more Engineering and Operations people, while the Research and Development communities grow much less quickly, or even shrink as those people move onto new and different topics. You might get something like this:
|>
(Note that this is not the same scale as the previous triangle. We’re looking at qualitative issues here, not quantitative.)
”’The most important thing to note is that the ratios between the research/development and engineering/operations practitioners have changed dramatically.”’ This is one of the most important themes of this entire essay series, and recognizing and responding to this demographic shift may be the most important thing that USENIX (and LOPSA) will need to do to survive and thrive.
The net effect of this is a demographic shift in the community. This implies that any organization that was designed to serve the original community size and demographic mix will not be properly organized for either the scale of overall community or designed to deliver the right services to the majority of the community. In other words, an ever-increasing majority cannot be served by the original organization, without major changes. Organizations that try to change to serve the new demographic mix will likely serve their original members less and less well, and run the risk of betraying their core values, mission and original members.
! The USENIX/SAGE connection
SAGE came into being as a subgroup of USENIX for several reasons, sparked in large part by the activities of a local group, BayLISA. Member of BayLISA joined with a few other members of USENIX to create this new organization to focus on the needs of the system administration community. Based on conversations I’ve had with some of the original “gang of thirteen”, they intended SAGE to be independent from the beginning, but it was faster and more expedient to launch as part of USENIX.
First and foremost, the creation of SAGE was a reaction to a need of some USENIX members (and others using UNIX) so USENIX was a useful catalyst for creating the new organization. Second, the focus was on UNIX system administration, so again, this was seen as a sub-culture of UNIX users (USENIX). Third, this allowed the fledgling organization to leverage the existing back-office of USENIX (at least in theory). Fourth, this later allowed the system administrators within USENIX to consider the USENIX LISA conference as “their” conference.
The contributions of BayLISA to the creation of SAGE must not be overlooked, and re-emphasize the importance of local groups in supporting the community. As LOPSA moves forward, they must ensure that this lesson is not lost, and seek to support, nurture and collaborate with local affiliates wherever possible.
! USENIX/SAGE and the difficulty in embracing Windows admins
This early focus on UNIX system administration and the ongoing focus of USENIX on UNIX technologies has been a source of constant tension in later years, as non-UNIX (Microsoft Windows) operating systems gained their own “engineering and operations” communities.
Although workshops and conferences (NTLISA) were held, they never attracted a wide following. Anecdotal evidence was suggests that this was due to the “Windows crowd” never feeling welcome at an event sponsored by a (very) pro-UNIX organization. Since there was (reportedly) a flavor of “how do we make these new Windows toys work in ”’our”’ (UNIX) environments and work with our real (UNIX) computers” in the workshops, this may in fact be the case. Personally I think that the Windows crowd was not ready, due to the lack of Windows ”’server”’ technology available at the time. They didn’t have the infrastructure mind-set, being limited by the Windows technology of the day.
In any case, as Windows has added server capabilities and infrastructure features, that community has grown, and is now facing many of the same scaling and overall system management issues that were conquered by the USENIX/SAGE communities years ago. Combine this with the near-universal acceptance of Windows on the corporate desktop and the end of the UNIX-only environment, it was clearly time for SAGE to embrace their cousins in the Windows world.
But, this was difficult, due to the heavy bias in the USENIX community, and its (quite proper) focus on UNIX-related technologies. As long as SAGE was a subset of the USENIX community, this could only remain status quo.
This bias remains to this day, and dealing with this issue will be very important for LOPSA’s success. If LOPSA is truly to be the professional association for all system administrators, they will have to truly embrace those who admin Windows, web servers, “storage” and networks as well as those who man help desks provide other front-line support.
In the next installment, I’ll talk about just why the USENIX and SAGE/LOPSA goals were incompatible, and how this has affected the USENIX/SAGE relations over the years. And then, in the final installment, I’ll talk about why USENIX and LOPSA are so important to each other, and describe some ways they might serve the community, together, in the future.
Thanks for staying tuned so far…. Part Four should be up in a few days…