Unlike the two previous blog entries which dealt with the rationale for our business model this blog entry is about the mechanics of the model. I will not waste a single sentence in explaining the why of the business model. I therefor highly suggest reading the two previous entries before reading this one. Also as promised I will give the details about how to get involved with the community of like minded micro-ISV's and their users bases.

Even though the details get rather messy without some kind of automated record keeping, the general idea behind the model is the same as equity shares in a company. Instead of having shares in the company the contributors (for the purposes of the math all members of the community are contributors) have shares in the project.

If we define every member of the community as a contributor then we need to define two classes of contributors:

• Work in kind contributors
• Monetary contributors

Obviously, someone can be in both categories. For the sake of simpler record keeping this fact is not factored into any of the formulas used in the process of rewarding people who did work in kind. In other words, if you are a monetary contributor and have also done some work in kind then any payment you get for doing the work in kind is 100% separate, from the accounting point of view.

As discussed in the second blog entry in this series in order to have stable vendors/projects money has to be involved. In the case of FloSoft Systems lead projects this means paying for the right to execute the software (see the Fair Source License 1.1 (FSL) Attachment A for details). Since I have hopefully made it extremely clear that in theory FloSoft Systems is not the only "contributor" (as defined by FSL) we need to divide the funds received in an equitable way among all the contributors. The details are described in the next section.

Any funds received have demands placed on them in the same manner any business would. Namely we have certain overhead expenses plus setting aside money for marketing, R&D and any other activity that we may undertake to make the "promises" sustainable intellectual works (SIW), as defined by the Miai Foundation for Sustainable Works (as expressed in the certification agreement between us and them for our products), come true. In short we are not a bunch of idealists who think the world would benefit from our SIW'ed software. We are business people who have decided that SIW is the best business model to use to meet our long term goals.

One of the nice features of SIW that often gets overlooked, even by the SIW community, is that work in kind contributions can be taking any of the above services off our hands and/or supplementing them. This means someone who does some marketing for one of our projects is as much of a contributor as the person who wrote the core code of the project.

For all the reasons above and in the previous blog entries in this series, to put this into practice we need some way to fairly evaluate the value of different contributions. Like shares in a company when a project is started, the Initial Developer (ID) does 100% of the work; they are naturally entitled to 100% of the revenue. As the project matures the ID is doing less then 100% of the work needed to make the project a success thus they are not entitled to 100 of the revenue. The only fair way to figure out how much they are entitled to base it on the percentage of work they do. For example if FloSoft Systems only does 90% of the work on thisTest then we are only entitled to 90% of the revenue from monetary contributors.

The remaining amount gets divided among the non-ID contributors using the same basic formula. Namely if A does 7% and B does 3% of the remaining 10% that FloSoft Systems does not do, the RCS split will be as follows:

	FloSoft Systems: 90%
	A:                7%
	B:                3%

There are two complicating factors to the above model:

• External services (ones not directly supplied by community members) have a fixed cost in most cases (such as web hosting, rent, etc.)
• It possible for a project to be a contributor to another project

The second item is easier from a conceptual point to handle then the first, so we will tackle it first. In the case of one project contributing to another project the contributing project is treated as a contributor to the "top level" project. In other words regardless of how project B is structured internally if it contributed 5% to project A then it gets 5% of A's revenue; how B divides that among their contributors is not A's problem.

In the case of external services the difficulty comes in to play when they are not all handled by the ID. Namely one of the non-ID contributors contributes the marketing; more specifically the web site, its hosting and pays any out of pocket expenses for any paid ads the project may have. There are two possible ways to handle this. The first is to simply reimburse the contributor for any out of pocket expenses before the RCS's are calculated. The other is to treat each contributor as a supplier to the project and thus any expenses in supplying the service are just one of the costs of doing business.

FSL leaves which model to use up to each project's community. Among other things this means that the exact mix of the two above approaches is likely to always be in flux. In order to keep things simple all FloSoft Systems originated projects will use the second approach initially. Specifically all contributors, including us, are treated as separate business entities for the purposes of accounting and any expenses in supplying services to the project are the contributor's responsibility. It is interesting to note that it is theoretically possible for the community to take certain actions that make it so the ID can no longer be a contributor. For example FloSoft Systems' RCS for thisTest might at some point become so small that we lose money no matter how many copies are sold; thus from a purely business point of view we should step out of the business of supporting thisTest and hand it over to the community. The amazing part of this is that unlike a closed source vendor doing this, i.e. making their product open source, the total community revenue will not decrease. Namely the monetary contributors will not notice any difference in the level of services provided by the community, assuming that it is worth someone's while to provide the service. The bottom line is the project has not suffered at all from the ID abandoning their portion of the work.

A brief note on the technicalities of the RCS formula. In the most general case a multiproject RCS accounting system will resemble a "web" more then it would a "tree". In computer science jargon this means it is a graph problem and thus in its most general case creates some very "interesting" computational problems, specifically the general formula is NP-Very Hard (note: our managing partner believes that there are no NP-Complete problems; just ones that no one has found a non-NP solution for).

For the technical reason above and various privacy concerns the SIW community differs widely on how "centralized" or "decentralized" the stereotypical interproject RCS web should be. By centralization we mean how much of the physical payout is based on a single entity doing the math. In most centralized cases there is one entity that does all RCS computations and gives its "customers" (the community for each project) the ability to adjust the RCS's for its project. Namely if project A has a 10% RCS in B and B has a 50% RCS in C then for every copy of C "sold" A gets 5% of the revenue. In the most decentralized case each project keeps all its own records and handles whatever payouts need to be made on their own. The current consensus in the SIW community is for the most decentralized model. Editorial note: Our managing partner is the main advocate for a centralized system. I suspect that once SIW becomes more wide spread one will see a mix of the two models.

An other aspect of the RCS model that is not completely stated in any official manner is establishing the "price" that monetary contributors pay. The SIW community has established some guide lines in this respect. For example the ID is not allowed to unilaterally change the pricing structure for any particular type of "economic use" (monetary contributor in our case); new versions are defined as a new type of use for this purpose. As with other areas that give the ID some flexibility, FloSoft Systems has reserved the right to set these prices for the base product on all projects we have originated. Namely we establish the "wholesale" price of the project and resellers (if any) are obligated to pay that amount for all copies sold (whatever markup they put on it is their business).

The question of who determines who gets what RCS is a critical one. Like the cases above there are several ways of doing this. For example the most democratic but likely the hardest to manage is do it by community consensus. At the other extreme the ID just assigns RCS values unilaterally. As with the case for external expenses all FloSoft System originated projects will initially use a case by case value agreed to by the ID and the non-ID contributor, as per FSL 1.1 Attachment A. As the project matures the community can of course "revolt", if it thinks it has enough political pull to make it work, and force a more democratic model on us. Even though not stated officially anywhere I make the following personal promise on all projects that I am the "inside" ID (i.e. the very first person, at FloSoft Systems, to do any work on it): if a new contribution has a large enough RCS to radically alter the entire RCS formula I will consult with all contributors to establish new RCS's across the board.

In fairness to the rest of the SIW community it should be mentioned that RCS as described here is entirely the creation of FloSoft Systems and only loosely based on our interpretation of the SIW community's consensus. There are other possible business models that have little in common with RCS that are also accepted as being SIW compatible, such as Jahia Software's "counterparts" model.

The above gives a non-mathematical overview to our business model. The second goal of this blog entry is to give the reader the resources needed to get involved with the SIW community. If you are reading this and are considering a similar business model for your own work you should contact the SIW community directly and not FloSoft Systems.

Historically the SIW community has gone through 3 main phases, each with all the same core members. The first phase was build the consensus on what exactly we meant by "SIW" (even to this day different members use different terms to mean the same thing for example Stephane Croisier [Jahia Software] tends to privately call it "collaborative development"). The second phase was hammering out the exact technical definitions needed to create SIW'ed products and licenses. Also in this phase it was decided that a central "certification" group should be established to act as a unified front for the SIW community. Thus the third phase was the creation of the Miai Foundation for Sustainable Intellectual Works and several other more specialized sites to manage the process of certification and marketing the SIW concept.

Each phase has produced its share of web resources and thus for clarity reasons it is better to list them chronologically by their creation date:

The orginial "Software Developers Coop" (SDC) mailing list on Yahoo! Groups:
http://tech.groups.yahoo.com/group/softdevelcoop/

The SDC web site and internal (non-Yahoo) mailing list: http://www.softdevelcoop.org

Jahia Software hosted Sustainable Software site: http://www.sustainablesoftware.info/jahia/Jahia

The official coordinating hub for all SIW activity and only certifier of SIW products (The Miai Foundation for Sustainable Intellectual Works): http://www.flosoft-systems.com/miai/index.php (temporarily hosted by FloSoft Systems for technical reasons)

Note -- for technical reasons all Miai mailing lists are temporally inactive.

Currently the core SIW community is made up of the following people:

Aryeh M. Friedman

VP of Miai and Managing Partner of FloSoft Systems

Henry Pjiffers

President of Miai and a freelance programmer

Marius Amado Alves

Director of SDC and a freelance programmer

Stephane Croisier

Director of Sustainable Software and CEO of Jahia Software