Section 5.4. BUILDING COMMUNITIES

5.4. BUILDING COMMUNITIES

Communities rarely happen spontaneously. It takes time and planning to create and expand them. The AOP group at PARC has put a significant effort in building communities around the technology. Lots of people outside our group were instrumental in helping clarify the concepts by providing alternative technologies and all sorts of feedback. There were/are two kinds of communities: researchers and practitioners. The bridge was built by very special people: early adopters, those people who work in industry but have the curiosity and the will to try out beta systems.

5.4.1. Researchers

As mentioned earlier in the paper, in October of 1996, we held a workshop at PARC to which we invited researchers we knew were working in similar things. There were about 15 people in that meeting. The goal of that workshop was to discuss the major characteristics of and compare the work we all were doing. That included AOP (i.e., the PARC people), subject-oriented programming (Ossher and Tarr), Composition Filters (Akit and Bergmans), Reflection (Matsuoka et al.), and adaptive programming (Lieberherr). It was a fruitful workshop. One of the outcomes was the plan for a larger workshop associated with ECOOP97, with the title "Aspect-Oriented Programming." That workshop attracted over 40 people and was a big success. AOP felt like the new kid on the OOP block. After that, there was an AOP workshop at ECOOP every year and one AOP workshop at ICSE'98. At every workshop, I always met new people whose work would fit and enrich the separation of concerns/AOP umbrella.

5.4.2. Practitioners

Building communities of users, especially the "real" ones, is much harder than building communities of researchers. By "real" users, I mean software engineers developing products in companies. Researchers thrive on ideas; practitioners thrive on solid systems that solve their problems without introducing new problems. Nobody in the industry will use a system just because it embodies an interesting idea that will potentially help him or her.

Our first users were graduate students linked to the research community. They were the only ones who were motivated enough to skip through all the bugs! They weren't really using the language to build anything; they were using it as a reference point. Our first "real" users started to show up in the beginning of 2000. At this point, the compiler was solid enough to handle a few hundred classes. The first users who contacted us had read about AOP, had played a bit with the examples in AspectJ, and wanted to try it in parts of their projects with our support for debugging aspects.

Early adopters are essential, but they are also hard to deal with. They try something and they either like itpushing it to the limit and asking for moreor silently drop it. A handful of early users were patient enough to point out defects and weaknesses and persisted in using AspectJ until it got a lot more solid. The vast majority was put off by the beta-ness of the language. Given that I left the AOP project later that year, I can't say much about what happened next. Based on the traffic in the mailing list, the articles in industry magazines, and the third-party IDE support, it looks like AspectJ has been embraced by a large community. Some of the AOP ideas are here to stay!