As discussed in my previous blog entry on FloSoft Systems' business model I gave a compelling case for why both open-source (FOSS) and closed source business models are inappropriate for most Micro-ISV's. In this blog entry I will explore the qualities that any middle ground model should encompass. Next week I will detail how FloSoft Systems implements these principles and provide a brief introduction to the community of like minded Micro-ISV's and their user bases.

I make two assumptions about who the reader of this blog entry is:

• You're a professional software developer and/or manager of a development team
• You have at least passing experience in using both open and closed source products

As professional software developers we know of no deeper frustration then finding a bug and/or needed feature in one the critical tools we use everyday. This frustration usually turns to something like rage when the tool vendor (assuming they are closed source) fails to see stuff our way (i.e. it is not a bug and/or worth fixing, etc.).

Typically this is the point where we start exploring various FOSS alternatives to the tool in question, assuming that we are not FOSS loyalists already. The general idea is that if we find a similar bug/needed feature and the core developer reacts the same way our closed source vendor did, we can trust that someone in the community will make the needed corrections and/or worst comes to worst we can do it ourselves. Namely we replace being at the mercy of the vendor to being at the mercy of the community.

While having some community support can lessen the above issues it does not solve them. In a sufficiently large community, such as the FOSS UNIX-like operating systems out there, someone will likely agree that such a bug/feature needs to be handled and will help you incorporate it into the tool. But, don't forget the person doing this is often doing so for idealistic reasons and if push comes to shove they will pick between their own personal interests (such as keeping a roof over their head) and their "duties" to the community.

In large FOSS projects it has been recognized that not everything that needs to be done can be done using the above model. Namely the demands the project places on core members of the team is sufficient enough to force them to choose between "eating" and working on the project. Since the Open Source Definition (OSD), as discussed in the previous blog entry, and the general nature of the economic forces at work in the FOSS world make it so they can do this by selling the program in any form. Thus one often sees a mix of asking for donations, a non-FOSS version (which is an improved version over the "community" version), selling various "branded" mechanise, support services, etc. For reasons hinted at in the previous blog entry this is very awkward for smaller projects, such as the ones that most Micro-ISV's start their business with.

At the same time most Micro-ISV's do not have the in house staff to really compete with the likes of Microsoft for the secondary services needed for commerical software such as tech support. This combined with the fact that programmers are by nature believers in the free flow of information and community building, it would be very harmful for the vendor to abandon all the benefits that FOSS offers everyone in the equation. Sadly OSD gets in the way again, as discussed in the previous blog entry. Unless there is a middle ground model available this forces the vendor to do some of the "bizarre" funding tricks in the above paragraph or become closed sourced.

Such a middle ground model, commonly refered to as being "community oriented" and/or "sustainable", is actually easier then one thinks. All that has to be done is slightly rewrite OSD to allow for discrimination between commerical and non-commerical use. On the surface this is very straight forward but it does raise some issues that took the sustainable community 4 to 5 years to basically reach consensus.

As soon as the need to make a living enters the equation we need to face a question that traditional FOSS has managed to avoid because there was no money involved. Namely it is very unfair to the community if the "core developer" makes a living from working on the project, but everyone else who has made contributions gets nothing. In other words everyone involved with a project, even just as a end-user, has some duty to make sure the project survives.

Even though not required specifically by the concept of a middle ground model the sustainable community has generally come to accept that there is a "contribute or pay" paradigm to the model. Namely everyone either fills their duty to the community by contributing work or money.

On paper this works very nicely, but it assumes that everyone's contribution is equal in value. This is obviously not the case. For example as the core developer of most of "FloSoft Systems" products FloSoft Systems has done a huge amount of work on the product. This means in almost all cases that we, and since FloSoft is a one person company so far this means me, are responsible for 80% or better of the work involved in the product. This means I am entitled to only 80% of the resources of the community. The other 20% is given out to who ever made contributions. It is only fair after all, doing anything else just replicates the "Red Hat problem" discussed in the previous blog entry. The practical implementation will be covered in the next blog entry.

Since there is now money involved in the equation the user benefits from all the normal things a traditional closed source company needs to do to justify the cost paid for their products. Namely we need to offer "real" tech support, be responsive to bugs and issues, and in general the customer is boss not the developer. If you trust in the market to work and lead to stability then you must also come to the conclusion that forcing vendors to do all this actually makes them more stable.

Even though the above makes it sounds like the vendor of sustainable works can pull the same tricks that people like Microsoft pull to force you into using their products exclusively. This is not true because the code is now 100% open and anyone can start a competing product and/or deal with the vendor abandoning the product. Of course since there is now money involved the orginator of the idea needs to be compensated like any other contributor would be.

In the next blog I will discuss the reasoning behind FloSoft Systems' business model, generically known in the sustainable community as Relative Contributed Share (RCS), and look at a few other business models used in the community. I will also discuss how you can get involved with the sustainable community.