Business Arrangements
SDxWiki

DWM:

Based on my own judgement of consensus, I think that most of us are interested first in doing something fun and educational, and secondarily in seeing it eventually turn into a business. For some of us, these two main motivations may be closely balanced, but overall I think the fun part weighs more heavily.

Personally, I would in fact like to see this grow into a business, so that I can have fun full-time. I am not dissatisfied with my current employment (or at least much less so than I was two years ago), which is perhaps why I haven't pushed Spooky Distance along as hard as I might have. But working full-time on a complex networked simulation would definitely be my idea of lots of fun.

But even doing something fun, and succeeding at it, requires some discipline and commitment. So let's talk business.

I am not in a hurry. I have a very strong preference for growing Spooky Distance (or whatever it's eventually called) into a business by starting from a low-budget garage operation, without the involvement of meddling investors until absolutely necessary (if ever). I would like us to own the company if it grows into something worth owning. This could take many years.

That approach immediately puts more pressure on the participants, exactly because there will be no pressure from outside forces. Any discipline and motivation must come from within. Also, eventually some financial investment will be needed -- maybe even soon. Two of us can trivially afford to keep this hosted Web site. But we also need a source code repository, and in the not-too-distant future we will hopefully be needing a reliable game server that we all can access at any time. Renting a dedicated server is considerably more expensive than a virtually hosted site -- about $250/month, or $3000/year, here at http://www.liquidweb.com. (Which seems like a decent deal compared with others, but I'm still poking around.) Maybe we could get away with a dedicated server at one of our broadband-connected members' homes, but is anyone really willing to commit to providing admin services, such as regular backups? And will connectivity really be what we want it to be, given the limitations that broadband service providers try to impose? $3000 per year is still not a bank-breaking amount, but it would most likely have to be spread around a bit to avoid causing spousal strife. :)

And once we start talking about money, we need to consider some formal business arrangements. Assuming we operate as some sort of partnership, how do we assign ownership percentages? I suggest that we begin to track time investments, on an honors system, based on guidelines that we develop together as to what constitutes 'billable' time. We could then use cumulative time as a basis for share ownership. Since we are all (except Istvan, I guess) senior software developers with considerable experience, (though I top you all in that regard due to my age) I'm willing to start with everyone's time valued equally - it will make things much simpler. I'm not sure how we factor in money invested. I suppose we need to put a monetary value on time investments so that the two can be combined.

Is all this scaring you? Good. Is it scaring you away? I hope not.

This may be your last chance to argue in favor of an Open Source, not-for-profit project. Nobody has come out strongly in favor of this so far, but it is a possibility. In that scenario, we would postpone the possibility of forming a money-making venture until we actually had a useable software product, at which time we could consider trying to form a company based on providing services -- consulting, or running trusted game servers, whatever. Once we got to that point, we would start at ground zero without consideration of time put in. (Since code ownership would not be an issue, there would be nothing to own at that point.) If we decide to do this, we might want to open this wiki to the public.

Thoughts? Reactions?


Istvan:

I am likewise interested in participating in something that eventually becomes a small business, for much the same reasons Dan described.

I would advocate organizing a project plan, and a Business Plan, agreeable to the participants before anyone be expected to financially contribute. I took my original annual cost estimates for Ecliptic to a couple of knowledgeable people (one an experienced high-end IT project manager, the other a financial analyst and CPA married to a senior Java developer), and they altered key areas, and both recommended that "garage operation" was the better way to go than the naive and overzealous approach I had written up. My model had been NetDevil - but they started with significant capital from a prior windfall. A garage operation saves considerable cost. However, my cost estimates had also assumed hired employees, resulting in the need for serious capital. If the majority of participants are volunteering a few hours a week, at least at start, the greatest cost factor (salaries) is set aside and we only need to provide for our own communal infrastructure requirements.

Also, I would consider code-hours higher value than other participation, and I propose double-value. The real object here is to generate and test some code. We can all type on the Wiki for hours, and that has some value, but I feel that those able to contribute real substance are contributing the greater value. Note that someone will need to be responsible for tracking 'billable' time contributed, if only for record-keeping. I am unopposed to using contributed time as a basis for 'share' ownership, if we choose some sort of partnership arrangement.

I am also unopposed to contributing toward a share of monthly infrastructure costs, as Dan suggested, but I'd like to see a preliminary 'garage' business plan and a budget before I commit a number of dollars per month. All those interested in forming a partnership might consider, as part of the initial business plan, an initial small outlay ($100-200?) that would give the partnership a small fund which could be held by a custodian and used to defray early surprise costs. In addition to infrastructure (server leasing and hosting at least, perhaps necessary software not in the public domain), there might be minor legal fees and fees tot he state involved in setting up a Limited Liability Partnership. I have a contact that might be available to provide advice on financial matters, though I don't think she can help with any legal issues. We should be prepared to compensate her for time, however.

Worth stating up front - setting up a small company (and that's what a partnership will be, even if it operates on a shoestring and volunteer time) is not get-rich-quick scheme. Especially considering our purpose. Selling broomsticks would be more profitable. This is also not an entity that would ever be taken public.

DWM I thoroughly agree with Istvan that at least preliminary development and business plans should be in place before any financial commitment is requested. However, even those take a significant effort to develop, hence my interest in first seeking agreement on equitable compensation. Talking about this up front can spare us heartache later, should someone go sour on the project, so I'm glad to see that at least a couple of you have responded thoughtfully to this. Regarding the value of different kinds of time spent on the project: If a few more people chime in positively on the basic idea of a partnership with ownership according to time & money invested, then we should start a separate page to hash out the details. Dave Hettmer I sympathize with Dan's interest in developing a well understood compensation plan, but I'm not sure the SDx infrastructure is well defined enough at this point for anything other than generalities. Especially considering at this point that we don't even have a design other than "JG but more better" (my southern Indiana roots are showing in my grammar). We don't have a single line of code written, or a completed graphic. I'm drawing from my film experiences to give me a feel for where we are right now. Not all of the shows I worked on were as high-concept as Army of Darkness; my name is in the credits of a few low-brow klunkers, too. :-) In order to proceed we need a driving force and a defined goal. Once the target is defined, even as poorly defined as Frostbiter: Wrath of the Wendigo, we can identify the roles needed to reach the target and their value. For example, my contribution to that film was initially fairly well-defined: animate the title character. For that I received a paltry sum plus 1/8 of one percent of the profits remaining after all the debts were paid off. Needless to say, I'm still waiting for that percentage amount. And my role expanded somewhat; I provided and puppeteered a snake demon for a scene that was ultimately cut, plus I set up all of the post-production optical effects. But all this was done without knowing if the film would ever be sold, much less make a profit. It was "guerrilla filmmaking", to be sure, and everyone knew it going in. Then there was Mosquito, a film I was only on the periphery of, contributing only a handful of shots. This was a more organized show, and the contracts were better defined. Yet there was more strife and strain due to the writer/director/producer's lack of management skills; he was more of a dictator than a collaborator. So what's the point of this rambling? We need a plan. We need a goal. And we need a driving force. Even then there will be tension; it's unavoidable. But we can't devise a mechanism that is designed to survive such difficulties until we have an idea how much wiggling room we have.


JDH:

First some random (sometimes conflicting often unrelated thoughts) - followed by some more direct responses to what Dan wrote (it doesn't take into account Istvan's views - I haven't read them yet - we both edited the page at the same time).

DWM (I know you're not done, feel free to reorg this paragraph if necessary.) Organizing and agreeing on goals is imperative; Istvan's push in this direction is much appreciated. I'll post some information about the XXXDb thingie: RRDBAPI. The reminder of loans is a good one, but I think this (important) financing detail wouldn't have to be debated until we had something to roll out and thus needed a lot of capital. In any case, I doubt you can get a bank loan without significant assets to show in the first place, since banks are quite risk-averse. The choice between the two might also be influenced by the financial climate at the time. Istvan What Dan said, with the caveat that no one should be contemplating adjusting their salary. Rather than jumping off a cliff, which is the wrong way to start a small business, I think we should walk, jog, then run before we try to fly. The 'garage' approach keeps everyone doing what they are doing for months, perhaps even years, before there is a viable and mature enough operation to have full-time employees with salaries.


Frank_Swierz: I too prefer the garage approach for all the stated reasons. Realistically, the chances that this venture will lead to anything meaningful are small, no matter how well intentioned we are, and the garage approach allows us to keep our investment very small. I know, I know, it's important to have a positive attitude, but we also don't really need to get ahead of ourselves either. Following the JumpGate model, I think a smashing success would just be to develop a game that hundreds of people play (for free) on the net. I'd be thrilled if we get that far! If we actually got to the point where people like the game well enough to pay for it. Well, there I go getting ahead of myself.... :)

Along that line of thinking, I believe we can postpone the hosted server as a code repository for a long time if we take advantage of those of us with persistent internet connections. Jim already keeps a machine running 24/7 as a game voice server. We might be able to con him into storing our source control system as well. I also would be willing to park a machine in my basement for such uses. I don't have an extra computer, but we could always scrape together a box from spare parts. Obviously once we get to the point of public betas, we'll need a more professional approach. At that time, I'd be more than happy to pay for one of the hosted arrangements that Dan was referring to.

As far as ownership goes, I generally agree with the comments made by Dan and Istvan. We certainly don't want hard feelings about ownership. And the further down this path we travel the more potential there is for hurt feelings. Not to mention legal hassles. Certainly not what Dan and I envisioned so many months ago. Of course when I'm cruising around in my new Ferrari, I don't want people to get all jealous... Opps there I go getting ahead of myself again.

I'm not in favor of assigning ownership of the company based on hours served. To me that would feel like I was turning in timesheets, and I hate that. My vision of our nirvana game programming company wouldn't work that way. Why start now? Also, it's hard to quantify and qualify the hours that people spend on various projects. For example, I haven't done much recently but in the past I spent some time learning some DirectX based game programming. So it was coding. But it was also learning. So how much does that count? What if some of the code that I wrote makes it into our actual system? Does it then count for more? Also, I purchased the book I used to educate myself with my own money. Does that get me a few extra percentage points of ownership in our new company? I know that I seem a little flip, but I'm trying to illustrate what I think the flaws are in this line of reasoning. Instead here is what I propose, I'm sure that you guys will poke some holes in the idea, but that's kinda the whole point. Let's come up with an arrangement we can all agree with. Here goes -

Here is what I like about my proposed solution -

Istvan (Frank, feel free to reorg this comment out of existence.) Aspects of Frank's egalitarian plan appeal to me, but I worry about how the group would be able to deal with situations such as if two participants are pouring considerable effort (say ten or twelve real hours of work weekly) into the projects, while perhaps three others are "coasting" at more like one or two hours per week, on average. If one lower-rate contributor is removed (voted out), will resentment be created? What about a lawsuit? I suppose in such a case we'd have to protect ourselves with internal, agreed-upon bylaws, with documents everyone has to sign as part of setting up the partnership. And similarly, there should probably be a minimum level of participation and regular contact set as expectation at the onset, so no one is put in that position in the first place. What about people who leave the project, down the road, for what we see as legitimate reasons? Is it fair to assimilate their contribution without any option for eventual compensation (this is one reason why even in private companies, the share distributions get weird: often some principals drop out, and cease accumulating shares, but even in an inactive state they retain some small interest in the future success of the organization).

While we're tossing ideas around, I propose a compromise egalitarian approach in which contribution-months are rewarded through an ever-accumulating number of shares. If someone essentially contributes nothing for six months, they simply don't accumulate shares during that time, while the others do. The non-contributor could even resume participation at a later point, and again accumulate shares. The non-contributor's share total would simply be lower than those of continual contributors. Decisions, of course, would be made on the basis of simply voting blocks of shares, if simple consensus is not reachable.


JDH I'm back from NYC! (the new terminal at Detroit sucks :-( ) I'm just going to post responses to everything I see on this page rather than go back and edit my other stuff.

(Oh, one other thing to consider: if we start off with an open-source effort we can take advantage of source forge and the like to help provide some common infrastructure bits).


DWM

Excellent, the dam broke. The only members not weighing in so far are Andy & Jim. (Andy wasn't at work today either, was he? I hope all is well with him.) Jim responded verbally with his infamous ambivalence. ;-)

Regarding Open Source: Once the software is out there as Open Source, you can't change your mind and take it back! To use SourceForge, you have to select an approved Open Source license, and agree to let SourceForge expose your source code. No retreat possible. (JDH I considered this and came to the conclusion that perhaps there are portions of our work which we'd be happy to make OpSrc but the secret ingredients we'd keep to ourselves.)

Regarding servers: After talking w/ Frank & Jim about this today, I suppose that a server at someone's house will be OK. I'm also interested in keeping costs low. Whoever hosts it will just have to be either very conscientious or very tolerant of being badgered about regular physical maintenance, like backups. Perhaps we can all pitch in to buy the server machine. It could be at least partially cobbled together from parts, no doubt - it doesn't have to be a super-machine to support an (initially) small source code control system. (If the money will still be a problem, we could look for more people to join in?) I recommend a Linux server, because our options for Open Source software will be greater, the software will be easier to set up (although server admin in general won't be), and remote administration will be easier. I'm not a pro Linux administrator, but I'm OK with most of the basics, having run a small server at home for several years.

Regarding plans & goals: Yes, we need plans and goals, but I think we can carry on these discussions concurrently. Developing plans and goals is effort invested, too, and I just want to make sure that we have at least some general explicit agreement on ownership issues before we get too far along. Doesn't have to be formal or detailed yet. I'm not looking for agreement on these issues within a matter of days, that's for sure.

Regarding ownership apportionment: I offered up the recording of hours as a strawman to get the ball rolling. Looks like it succeeded. Good!

Personally, I would like something that gives us incentives to actually work on the project. I think it would be helpful for me, personally, during those times when I don't feel very motivated, and (less important) it would make me feel better to know that everyone else has the same incentives. On the other hand, I dislike timesheets and such, too, and I don't want a system where it's easy for someone to start feeling like they're being left behind during a (hopefully transient) personal slump.

On the other claw, the idea of 'voting someone out' doesn't sound good to me. I wouldn't like it if my only remedy to someone's slacking off is to punt them out entirely -- it seems too drastic, and for that reason it seems unlikely that we would ever get enough people to agree to do it. JDH It never would be one's only remedy but it represents the ultimate stick to deal with an unreasonable intransient member (and becuase we're all such super guys we'd probably never have to resort to it, right?) - having said that I've no particular problem with the compromise idea (suggested by Istvan and mentioned by you below) - and once a quarter seems a reasonable compromise for the frequency.

I like Istvan's compromise idea. Pick an increment, say every three months, to get together and discuss whether anyone should be denied their 'share increment' for that quarter. We could agree on numbers for base investment (divided evenly) and quarterly increment however we like -- the relative sizes would determine how quickly someone could fall behind if they're not participating. Hey, at our meetings we could also decide to grant extra shares to someone that put in an unusually sustained effort -- that we could be good guys to each other, too. :-)

To avoid any headaches with money, I agree that we should keep costs minimal initially. Additionally, should endeavor to share equally in any significant costs that we ''do' agree to incur.

Hopefully it'll be a long time before we have to worry about the dark side of share ownership -- potential liability for debts. :-) (Istvan: As I understand it, the purpose of registering a L.L.P. or L.L.C. is to protect the principals from debt obligations adherign to the company - that's why the term is "limited liability".)


ABC

Excuse any typos, please, I do have a cat reading over my shoulder, but she does not seem to be catching all of my mistakes tonight. But enough about Anna the Spellchecker, on to the business at hand. I would ideally prefer the version of ownership Frank put forth. It is much more to the Three Musketeers ideal that I am hoping for. I think that we all are tired of working for The Man every night and day. If we are ever to succeed, we must be in it together, "All for one, and one for all." This method, all of us having equal pieces, flies in the face of all those whom we work for who try to quantify our value based on number of production updates, or hours worked (OT), or any other tangible, but meaningless, number they can get their hands on. This is our chance to acknowledge the intangibles. To recognize that if we do not have everyone participating in some way, whether it be in churning out LOC or playing cheerleader to waning interest co-founders, SpookyDistance will never take off.

That is if we were developing in an ideal world. But, we do not code in a vacuum. I will go along with whatever method gains a plurality. As I see it, I'm already hanging on to the coattails of more talented, more experienced developers, there's no way I'm letting go now.

One further note, I do not like the idea of convening every quarter to put who deserves more options to a vote. Sounds too much like needing to prove your innocence before a jury of your peers. If we choose a method that involves an aggregation of options, I would prefer to elect a CEO that makes the decision of who gets options for the quarter. Putting a leadership role upon one of us may not be a bad idea, anyway.


Istvan: Well, Andy went there first, and I think he's right. Someone probably needs to be acclaimed as leader - if only in a coordination role.


JDH: Now that most people who are likely to weigh in with an opinion have done so can we try and summarize the positions? I'll try and do so in a list form please feel free to add to or modify the list and add your opinion about each point. Perhaps that way we can approach an agreement (or it may become apparent that we're not ready to reach an agreement yet). So here goes, they're presented in no particular order if you want to order them then feel free and if you want to restructure then do that too. I'm trying to shift into a different Wiki mode here - rather than discussion based I want us to produce a shared summary of our current issues along with a summary of each individual's position. I've tried to keep opinion out of the first list and confine it to the second list - please edit appropriately. Thanks.

OK I ran out of steam with this stuff - someone take over (if you think it's worth it) ... (Istvan: Thanks for doing this, it was well worth it)

  1. Ownership
  2. Initial Stake: The only suggestion so far appears to be that the initial stake should be divided equally among the current protaginists that choose to sign up to whatever agreement we reach.
  3. Future Stake: There appear to be two main models suggested.
    4. The first is that the initial principals stakes remain constant, costs are shared if we choose to offer options to future members then we do so from a seperate pool (presumably ensuring that the principals always maintain the controlling share).
    5. The second model recognizes that each of us will make a different level of contribution to the project and wants to take that into account - primarily as a motivational tool so the more you do the more you potentially get. The pros of the first approach are it's egalitarian feel and the recognition that it's difficult to guage the worth of someones input; the cons are that it might not address one of the main aspects of coming up with an agreement - the equitable distribution of some unknown amount of gain at some unknown point in the future. The pros of the second approach is that it attempts to address the future distribution issue but the con is that it's difficult to measure the effort - especially in an adhoc garage operation.
  4. Accounting of Contribution: This section only makes sense if we decide to adopt the second model of determining future share. There appear to be three contenders: 7. Hours-Based: Pretty straight forward concept but hard to monitor and doesn't take into account the intangibles of the worth of a contribution. It also smacks too much of timesheets which we all love to hate. 8. Quarterly review of contribution: (or some other reasonably long period of time). The idea here is for the group to "meet" once a quarter and review participants contributions for that period. Pros are that this may be lower overhead and more flexible than hours based. The main con stated is that it may feel like you have to prove yourself every quarter. 9. Elected leader assigns options for the period: To avoid the feeling of a trial by ones peers an elected leader could decide upon option assignment for the period.
  5. Assets How should we pay for them? Who should own them?
  6. Achieving goals
  7. Defining Goals 13. Marketable software development - RRDBAPI 14. MMOG development
  8. Business Plan (Draft document in progress -Istvan)
  9. Leadership
  10. Organization - Formal Types
  11. Leadership
  12. Open source v. closed
  13. Assets

Ownership

DWM: Istvan, I'll post more on this tonight. (I'm still at work atm.) Short answer: yes, I think you're the only one advocating this level of formalism at the moment, although I'm sympathetic to it. Perhaps we could talk on the phone this evening? I'm usually up pretty late, so the time zone difference should be manageable. Feel free to call me. Istvan: Afraid teaching tonight will kill the evening, though I might try to call in the next few days, if you'd like me to. I'm not disturbed if I've been the only one advocating formalism - I just wanted it in the open. If the consensus is not to organize in any formal way, I'll bow to it. However, I'm motivated to at least understand the process of organizing a small business under Michigan law, so we have a procedure we can choose to follow or plan for, or not, as we see fit. DWM: By all means, call anytime. I often work late, getting home 7-8pm EST, and am usually up until at least 11:30, often later. By all means continue researching if it interests you; I hope fervently that it will eventually be critically important information to have! Achieving Goals

In regards to goals, I'm personally very interested in contributing everything I can to a game design and development project. I'm less interested in the more practical goal of producing other software, because I am less able to contribute direclty to such efforts, save perhaps as a technical writer, unless I dramatically educate myself. That said, I support the idea of developing marketable software either prior to or in parallel with game design work, because marketable software represents potential cash flow that could enable more focused development efforts in the future. Organization