The Evolution of the Encounter, Engage, Exploit Model: From Microsoft to FOSS
In the world of software development, understanding user behavior is crucial for creating effective products that meet their needs. The Encounter, Engage, Exploit (EEE) model has been a valuable tool in this regard, helping developers create engaging and exploitable experiences for users. In this article, we'll explore how Microsoft evolved this model and its subsequent adoption by the Free and Open Source Software (FOSS) movement and partly the misuse and havoc it created. Finally, we will discuss a solution, for community driven development.
Microsoft's EEE Model
In 2001, Microsoft researcher Dan Russell developed the Encounter, Engage, Exploit framework as a way to understand user behavior in various contexts. The model posits that users go through three stages when interacting with software:
1. Encounter: Users first encounter an application or system, often driven by curiosity or necessity.
2. Engage: As they explore the product, users engage with it, forming mental models and expectations about its capabilities and limitations.
3. Exploit: Once engaged, users exploit the features and functionality of the software to achieve their goals.
Russell's EEE model was designed to help Microsoft developers create more user-centered products by understanding how people interacted with them. By recognizing these three stages, designers could optimize each phase to improve overall usability and satisfaction.
But Russell, wasn't the first using EEE at Microsoft.
Though not acknowledged, EEE had internally quite a different meaning at the Microsoft HQ. Microsoft used the Embrace, Extend and Exterminate principle, as it was found by the U.S. Department of Justice when there was a case against Microsoft[1].
In this case it's about Embracing all participants, then Extending the community and then take over (Exterminate) the community. This is how Microsoft planned to take over the Internet. Luckily for us, it didn't work[2].
FOSS Adoption
As FOSS projects began to gain popularity in the early 2000s, the EEE model became a valuable tool for community-driven development. Open-source software often relies on user participation and feedback to drive its evolution. By applying the EEE framework, FOSS developers could better understand their users' needs and behaviors.
The first significant adoption of the EEE model in FOSS was by the GNOME project, an open-source desktop environment. In 2004, the GNOME Human Interface Guidelines (HIG) incorporated the EEE model as a core principle for designing user interfaces. This integration helped ensure that GNOME applications were more intuitive and responsive to users' needs.
FOSS Evolution
As FOSS projects continued to grow and mature, the EEE model became an integral part of their development processes. For example:
1. Ubuntu: The popular Linux distribution incorporated the EEE framework into its design process, ensuring a user-friendly experience for new users.
2. KDE: Another prominent open-source desktop environment, KDE, also adopted the EEE model to improve usability and accessibility in its applications.
The FOSS community's adoption of the EEE model has led to significant improvements in software development practices. By understanding how users encounter, engage with, and exploit their products, developers can create more effective solutions that meet real-world needs. But the sun doesn't shine always, does it?
Misusing the EEE Model: A Threat to Community-Driven Development
The Encounter, Engage, Exploit (EEE) model has become a valuable framework for understanding user behavior and improving software usability. However, when applied incorrectly or with ulterior motives, this model can be misused by software companies, undermining community-driven development and the very principles of open-source collaboration. Turning into the Microsoft Embrace, Extend, Exterminate invention.
Misuses of the EEE Model
1. Encounter (Embrace): Manipulating First Impressions
Companies may use the encounter stage to manipulate developers initial experiences, creating a false sense of familiarity with the scope of the software project, that can lead to unrealistic expectations. This tactic can result in developer frustration and disappointment when they discover the project's limitations.
2. Engage (Extend): Fostering False Engagement
By trapping developers in a foss project, drive the free development and getting a huge stage for the initial foss project. Building a huge dependent community (Yes Odoo, it’s also about you). Creating an enthusiast community which thrives on the foss message.
3. Exploit (Exterminate): Exploiting User Trust
When the project has a thriving community and customer base, just blatantly start with a partial proprietary version or options to make money on the back of the entire community without sharing the profits. This really sounds more as Exterminate to me. Take over the entire project, change the license for the future versions when possible. Like the good old days, or how Apple used OpenBSD.
Consequences for Community-Driven Development
When software companies misuse the EEE model, it can have negative consequences for community-driven development:
1. Lack of Trust: Users may become skeptical about open-source projects or even abandon them altogether due to perceived manipulation.
2. Misaligned Priorities: Companies' focus on exploiting user trust and manipulating first impressions can lead to a lack of genuine engagement with the community, resulting in poor feedback loops and inadequate feature development.
3. Stifling Innovation: By prioritizing proprietary interests over community-driven innovation, companies may stifle the very creativity and collaboration that open-source projects are meant to foster.
But luckily there's one positive aspect: forking. Because the base software is free and open source, the community can fork the code, which frequently happens. Hey Redis do you hear me!
Now we have to answer the question, was this evil by design?
To be evil by design, the EEE model needed to be used strategically on purpose to mislead developers, to create a product for the proprietary company. In all honesty, I don't believe lots of these cases are strategically planned and done on purpose (Except Microsoft[1][2]).
I genuinely believe it just happens due to the success of the project, and the greed which many of our fellow humans have.
Then we need to answer the question of how can, communities make sure this won't happen to their project?
The first step I think is being a community driven project, not a business driven project. Next, I suppose it's all about selecting a good foss license which prohibits this kind of actions.
So what kind of foss license do we need?
We need a license that allows adaptations of the code, forking of the code. We need a license that forces developers in sharing all code based on this project. We need a license that forces developers, which develop add-ons or modules to use the same base license.
The license which meets all these requirements is the AGPL[3]. So if you want to use Encounter, Engage, Exploit, but you don't want some company hijack the project into Embrace, Extend, Exterminate than an initial AGPL license could be the solution. The main advantage is that AGPL forces all derivates to maintain the same license.
[1] https://www.scribd.com/document/471571328/Embrace-extend-and-extinguish-Wikipedia-pdf
[3] https://www.gnu.org/licenses/agpl-3.0.html