The Plug-ins Strategy

Desire lines: use of the platform, and organic self-organizing activity among members advocating for improvements or enhancements within the platform, generates “desire lines” that indicate how the users want or tend to use this (open-ended, co-created) vehicle. Beyond its core platform offerings (see The Five Pillars, etc.), Cosmos would rely on emergence and the collective genius to “crowdsource” its own internal initiatives for better serving members. This is referred to as the Plug-ins Strategy.

It is considered a virtue in Open Source (OS) to have a light but extensible core, and a myriad of apps/plug-ins. The core is usually maintained by core developers—these individuals are the most trusted, most expert. Whereas anyone is welcome to experiment with plug-ins. Plug-ins may become successful and become adopted into core. These basic tenets hold true for how Cosmos approaches the “fleshing out” of its mission and value proposition on the platform, as follows.

Cosmos encourages its members to engage in abundant peer-to-peer interactions and creative productions (on Cosmos’ platform, but not through a centralized [Cosmos-centering] “frame”). The general concept of the Plug-ins Strategy is that members would self-generate, self-resource and self-validate various products or services that they could put “on offer” in the Cosmos realm. This might take the form of a product or service that one member “publishes” autonomously on the platform, making it “for sale” to other members—and wherein user acquisition of and engagement with that product becomes a prime indicator of its relevance and salience to the community.

Indeed, one of the great values of Cosmos is the “playground” or “amusement park” like experience, where users can interact directly with each others’ offerings, and can configure their own arrays of resources on the basis of their individual needs and desires. Cosmos prioritizes the autonomous movements of its members among different levels—yet Cosmos also appreciates (literally, actually) when members move to higher degrees of activity (I.e. greater intensities of engagement/participation). Configurable “plug-ins” may make up 90% of a users actual experience of and interactions with the platform!

Ultimately, we envision that “plug-in” products and services in Cosmos are made available in a modular fashion: treated as distinct items, which can be chosen from a menu or acquired in coordinated “packages.” Whether an option is presented by a peer, a team of peers, or formally through the framework of Cosmos, members—beyond their basic member dues—can opt-in (for additional cost) to as many configurable “plug-ins” as they desire. Each product or service is made available to members at appropriate costs ($, LC, C>, or other barter, gift or trade type arrangements). To engage with a plug-in one must pass through a payscreen, wherein members can purchase the service. Some plug-ins could be merit-based, and thus require additional screening, e.g., an application process, to access.

This process extends to how Cosmos may generate new platform-embedded (aka “core”) utilities, features and fixes, as well. As much as possible, Cosmos resources the generation of solutions and ideas for improvement from its own member base. That means the platform would expand and grow through the creation of a diverse array of modular, optional “plug-ins” that users can select from to augment and enhance their experience in Cosmos. The most popular, well-used products and services may indicate “desire lines” to Cosmos, and Cosmos may therefore explore formal, system-wide adoption of those components, officially “adopting” it into “the core” making it a part of the goods and services Cosmos formally offers to all members as part of their membership.

Note that a determination of whether certain features have enough “critical mass” (in terms of anticipated usership or adoption) to warrant Cosmos resourcing their fulfillment in a centralized way (I.e., at the organizational level) versus allowing users to engage in processes of investing in, voting for, and otherwise managing their own “demand” for features in a decentralized way—this will depend on various factors and analysis that are not yet testable. The general principle represented by the Plug-In Strategy, however, with user participation informing the selection of some from among many proposed methods and mechanisms for meeting users needs, remains a fundamental component of how Cosmos the platform would be developed.

Here’s how it would work:

● Cosmos itself wouldn’t “produce” stuff without member community validation (I.e. ample feedback), which occurs through 1) products gaining traction and adoption by a subset of members who have opted-in to it via the peer-to-peer marketplace, 2) proposals for addressing issues or improving the platform that are attached to fundraising/support-raising campaigns.

● Proposals are generated when users or Cosmos worker-users articulate an unmet need or an issue on the platform that they see needing to be addressed. The “feedback” registered that there is a problem—or an opportunity—on Cosmos would come into Cosmos in various ways: through active community discussion of the issue, through help desk “tickets,” through requests for features, through the organic creation of prototypes of solutions and via engagement with developer-partners, etc. In most if not all cases, discussion and deliberation about the issue or opportunity would occur in stakeholder groups. In the process, one or more proposals may be generated—an abundance of possible “responses” to the “feedback” of pain points and desire lines.

● Plug-ins are developed in accordance with user-expressed needs and aspirations—more likely to receive support (of all kinds) if proposed in response to explicit user stories/expressed needs. Cosmos will make any of its user requests and demands transparent, so creative visionaries in our midst can choose to produce a proposal or prototype in response to these yearnings at any time. Member needs are likely to be in line with the Five Pillars, insofar as the community of Cosmos members gathers around the purpose of fulfilling those creative needs. Cosmos may even centrally produce requests for proposals and enable fun competitions or fundraising challenges in order to resources its most urgent/salient platform build-out needs.

● There would be a template for formal proposals which users would then implement to “voice” their proposal to the broader community. These proposals would be structured so that users could allocate resources of their own (in the form of C>, Litcoin, or other) to show their “backing” for this idea. Proposals may have various statuses including “in discussion,” “seeking sponsorship,” “ready to implement” etc. Raising support in various capital forms is crucial to the realization of proposal. We may establish (or simply encourage) proposals to have “drop dead” dates so as to avoid “zombie” projects that hang around forever, tying up its sponsors’ capital while being highly unlikely to reach the threshhold needed to become realized. Eliminating zombie projects will help ensure creative, responsive salience of proposals to the latest, sensed needs.

● Cosmos would promote/support/etc. its members’ proposals and campaigns by providing the formal proposal template mechanism and then making proposals available to all users to see/search, transparently. There may dedicated spaces within Cosmos to review proposals by name, issue addressed or keyword. It may be that a proposal needs a certain threshhold of buy-in (that is, support) from its immediate stakeholders or community before other users will be able to find out about it (ala Reddit). Furthermore, that the more popular a proposal becomes, the more likely users might be to “encounter” it in their feeds. Based on popularity or urgency of proposals, Cosmos’ algorithms may be more likely to “push” (notify) its members of them. This is basic behavior patterned after many crowdfunding sites.

● Cosmos may also put up a “matching” fund (sourced from its reserves) that a proposal is able to access if it garners sufficient validation (via C> and LC and other commitments of capital to the proposal) from the community. The matching fund would be attached to projects with a high degree of likelihood for meeting collective-scale needs or that would advance the mission of Cosmos significantly (helping it to level up).

● However, some proposals may only need a minimal amount of capital—and, some, only in the form of “people power” (that is, skilled human resources attached to the project who can produce a prototype) before the proposal is essentially “fulfilled” in prototype form. In such cases, users can interact with and test out various options of potential features (e.g. in Alpha or Beta form), and give feedback on what they like and don’t like and would adopt the most. The most popular prototypes would be eligible to attract Cosmos direct funds, as well, either beforehand (capitalization to bring the product to scale) or after-the-fact (royalties from adoption of the tool by the platform and a portion of wealth generated tied to value-creation from user utilization of the tool). This is not unlike Google Labs.

● At the early stages in which Cosmos may be led by a small team of highly-engaged people, the “core services” are selected by default: the team is focused on creating a “minimum viable product” of a platform that will allow Cosmos to have sufficient capacity for sufficient members. Therefore, templates or products created in the early stages of Cosmos’ development may be considered prototypes for functionality Cosmos ultimately hopes to expand upon—the prototype being one tangible step toward providing benefit to members in early stages. E.g. treating Metapsychosis, currently Cosmos’ only fully functional online journal/magazine, as a prototype (or template) for how a collaborative online journal could be run within Cosmos; the learning from this process would get reflexively captured in the Playbook as a template to enable other members to potentially innovate on what has already been done. Note: Whatever does get produced and promoted through ad hoc leadership will have feedback effects on Cosmos. That is unavoidable yet historically significant, so the sooner participation and influence can be expanded without compromising the structural integrity of the early-stage system, the better overall.

● Cosmos may invest directly in promising early-stage projects or talented individuals, essentially directly “incubating” ideas that it views as having high potential to better serve the collective membership. This is like the research & development department in large organizations.

● The various emerging products (the “plug-ins”), enabled by this process, become decoupled from the organizational core— except insofar as they grow to be “officially adopted” by Cosmos and are thus supplied with ongoing resources based on their salience to the Five Pillars and love from the community—I.e. they become integral to how Cosmos fulfills its mission and delivers value . Today, there is not much of an apparent distinction between Cosmos, Metapsychosis, Infinite Conversations, Litcoin, etc. But eventually Cosmos would constitute the meta system (the MindfulAI / outward-facing brand / interwoven co-op-community-platform systems) that contains these smaller, more focused units of: spaces, projects, discourses, plug-ins, etc.

● Note that it may be much more efficient to leverage digital software/platform products already constructed and in active development by peers and prospective partners in the Open Source arena. As part of Cosmos’ ethics, it would seek to find out about, and validate, peers’ dedicated work in amenable areas whenever possible, rather than creating “our own” “from scratch.” Cosmos would seek collaborative relationships with such partners in which we are communicating closely about our community’s needs and determining fit (or augmentation to enable fit).

● Cosmos would seek to conserve its members’ resources through efficient “smart contracts” enabling Cosmos to make use of various apps and integrate them into a decentralized platform structure. When it comes to Cosmos adopting certain user-generated options into its “core” platform functionality, the co-op could always modify or terminate these agreements if they find more efficient, effective or otherwise better ways of meeting crucial platform needs. Thus each adoption of a plug-in into the “core” platform may come in the form of a “smart contract” with terms including expiration, so Cosmos can always opt-out of official adoption after a trial period.

● The Plug-ins Strategy is designed to be facilitative and invitational, and looks like mycelial or brain networks: coordinating resources within the system to produce tangible services and products (potentially—at its mature level, like a DAO).

Software development workflows that we will borrow from:

○ Core & plug-in model (see above). Certain essential functionality is core (e.g. maintaining a forum, maintaining a video virtual meeting service & enabling access to it, maintaining a blog system), then people can build atop it.

What is core, and what is plug in? We structure the revenue flows so core is getting funding from the retained capital acquired from member dues. Plug-ins, however, are funded through LC funds, C> funds (reflecting patronage and internal “votes” on platform augmentations), and the collaborative, consensual agreements of members—plus a potential “matching fund” deriving from Cosmos’ retained capital resources. We structure the plug-ins so that people can gather resources for their projects directly—and sponsor projects directly. If there is a group or committee that wants to build out a feature, it can resource that independently (self-funding, self-staffing and self-promoting).