PDA

View Full Version : One programmer shop considerations



Mike Cooper
15-Mar-2010, 02:43 AM
Hi All...

I am not sure how many of you are in this boat, but it is an issue that I am continually coming up against (and quite frankly tired of it).

Having been in business for over 20 years and still will some of most of my original customers, I know that the customers I deal with feel that they are the most important people in my day... however, new prospects of course don't have the benefit of that longevity AND often have been bitten by the "my last programmer moved to an ashram full time... or died... or went hiking in Italy for 2 years"

More recently, my company lost two contracts, one for a modest $10,000 and another for approximately $600-900K!

Anyway, despite all of the assurances that our company has a survivorship plan that includes 6 shareholders and source code is owned by the company not me, it seems difficult for the prospect to find comfort in the fact that our company has a single programmer (me)... now let me interject....

ALL of my competitors in 20 years have either gone out of business OR been sold more times than an RV which of course leave those users out in the cold way more than my customers who have never had to find a new way to support their software.

Seeing the names in the NG as I have over the years, I can't help but to think that there are others who hear this as a familiar tune.

My idea or concept is a way to create a formal relationship with another developer (or two) which would serve as a way for us to give a concrete solution to this fear that many prospects have.

It could be done in a couple of ways...
Option 1: A trade of shares between like companies... ie I would trade 100 shares in my company for similar value in another company. This way we could both say we have 2 programmers who are shareholders in the corporation.

Option 2: Surprisingly more complex from a legal perspective, would be to create an autonomous Member Organization with appropriate legal counsel to "bank" source code and a valid list of programmer members etc.


My choice would be Option 1. Overall, easier to maintain between 2 or 3 parties... For 100 shares (roughly a $100 value), no source code would have to be shared, dividend outflow would be minimal (for example, we just declared a $0.045 dividend per share)... Easy to trade for equal value with another VDF based company (share trade)... If I kicked off or decided to count the ceiling tiles in a mental hospital, then the company would already have a VDFer who could likely jump in as principal.

(PS... I am healthy as a horse)

Any thoughts, ideas, feedback, discussion?

Mike Cooper
www.grasp.ca

Michael Mullan
15-Mar-2010, 07:03 AM
Mike,

this is kind of what the NEDC (http://www.nedataflex.com/NEDCtestGM.asp?pageid=2)does, in the Northeastern US. I haven't joined (yet!) but only because they are just little bit too far north for me.

Michael.

Hendrik van Niekerk
15-Mar-2010, 07:35 AM
Hi Mike

I suggested this a few years back, only, my idea was to form a consortium of VDF developers. Something like co-op. where developers can join and be sured of work and also avoid the, "oh but what happens when you are hit by a bus" syndrome. Many of developers that I know are one man shops! Not many organizations tend to opt for that sort of situation. But with a 'VDF Developers, Inc" with a workforce of many developers one has a better chance.

With times, such as they are, cost cutting and downsizing, more and more of us are having to look for more hours. I'm sure there are the fortunate ones that have too much work, lucky for them, that with this sort of set up the work can be shared and time lines could be met, confidence in a larger workforce, and opportunity for more work/contracts stand a better chance etc.

But, sadly, I had no response, to my posting.

Mike Cooper
15-Mar-2010, 07:53 AM
They are a bit south for me, but maybe I should look at it again...

M

Mike Cooper
15-Mar-2010, 07:59 AM
It seems so obvious to me that small companies service their customers way better than big companies, but I've been thinking of recording my voice to play when people raise this...

Often it isn't an objection that amounts to much since most of my customers are from referral anyway, but for relatively little effort we could easily cover this base...

I mean, It would be easy to issue enough shares to amount to 1% of the corporation simply to poise another VDF programmer in fold... and it would be equally easy if that programmer did the same with me... Neither of us would have to let go of our source code or any money... We would simply receive company information on financials, products and whatever dividend declarations there would be....

Any interest out there to talk further on this?

Mike

Hendrik van Niekerk
15-Mar-2010, 08:17 AM
What is this, 'let go of our source code' issue that Dataflex programmers have? I can't understand it!

This is why our community is in the state its in, and it's something inherited from the mentality of DAC, "we will do it our way", until they saw the light a number of years back whet they dropped the 'we will do it our way' to 'doing it Bill's way' and see how far they have come! A product that they don't have to re-invent the wheel each time a new feature or new object/class needs to be developed.

This is why the Dataflex developers are so concerned with "my code" we have this attitude that our way is the best. Take an example from the Linux crowd! They collaborate and share, just look at 'ubuntu' in a few short years they have become a major force with their distro! Have a look at their forums and see how these guys share their code, Yes share their code! and how they assist and help each other. The world is too small, now a-days to do 'your own thing'.

Just think on collaborating, and sharing, code, ideas etc. sometimes our solution is not always the best, but with a team of developers, and sharing of ideas, a better product evolves and ALL get the credit.

Also, what is with the, 'problem of having to be there?' With telecommuting a developer can be anywhere in the world and work on code, and communications today are not an issue anymore either.

Just some thoughts....

later..

Garret Mott
15-Mar-2010, 08:21 AM
Good Morning -

As a member of the NEDC, I can speak to this a bit. First - credit goes to Peter Donovan for creating/pushing the concept. Distance is a problem. I drive 3.5 hours to meetings, but most of the rest are under 2. We don't have as many meetings as we used to, but that may be because we're speaking (emailing, Skyping, etc.) to each other weekly if not daily working on projects.

We are a far less formal group than what you've suggested. 1) We all decided that we could trust each other & 2) we didn't want the expense/hassle of forming a corporation somewhere. The former is important - just as it is to have the customer trust you & vice-versa. The latter was particularly because we're in several states - so what state would you put the corp in?

We share jobs based on need, skills & availability. 2 might work for one customer, a different 2 or 3 for another. So far it's worked extremely well. Not to say that there isn't an occasional rough spot - we are independent developers after all - but we've been able to work things out. The person who brought the customer in generally acts as project lead & sometimes we bill separately, other times we bill the lead & he bills the customer. There was one customer who asked for a change in the lead, but that's only happened once. Yes - that was one of the rough spots. :o

Customers love it. They get more done more quickly & don't have to worry about the "hit by a bus" syndrome.

It takes some time to get to a comfort level working with someone else - especially after 25 or so years of working alone. Since we've been doing this for 5 years now (I think that's right - time flies when you're having "fun"), we've developed a good understanding with each other. That's not to say it's for everyone, though.

Cross-border could get more challenging - but I wouldn't think it's insurmountable.

Garret Mott
15-Mar-2010, 08:28 AM
I agree. The NEDC has an FTP site where customer code is stored. We also have an SVN repository for one customer. That's only for one because the developer set it up on his own server & doesn't have room for the rest. I think I can safely say we've all learned a great deal by sharing code.

As far as being there goes: I won't do work for a customer I haven't met face to face. However, once we've met, Terminal Services, etc. work beautifully. Heck, I have what I think of as local customers (50 miles away or so) set up on TS. Makes my life easier & costs them less - no travel time. I still like to see them every so often & sometimes it's far more efficient being on-site. Just got back from Illinois for a week where I was putting a new module in & being there made a huge difference.

Hendrik van Niekerk
15-Mar-2010, 08:41 AM
The point you make about the customer is valid. The point I'm trying to make is once the customer has been met, face to face, by one of the consortium members then the project is defined and the scope is out there, developers can then share the load. The member, who met the customer, is the contact person, he is the one that does the deploy and updates etc. Now are all SQL experts? no, but we have them in the group, are all class writers, no, but we have them in our group. Web guys? on and on... Can one man accomplish all this? No (unless his name is Wil van Antwerpen!) but for the majority, collaboration is best.

Sharing the code can be done 'in the cloud' there is plenty of storage out there, ask Google! Something like $25 for 50 gig! So storing of projects can easily be maintained out there and not be dependent on a one man developer shop that has a cranky server out there with enough space to store a few projects. Think about 'uptime', 99.99% is hard to beat!

So where do I sign up? lol

later...

chuckatkinson
15-Mar-2010, 10:46 AM
We tried some to do this kind of thing in Dallas. David King has a fairly complete accounting system. The concept he was pushing as recently as a couple of years ago at DISD was for other developers to build bolt-ons to his base accounting modules to be able to sell a complete package (which most businesses need). The add-on developer would get his/her money from the add-on and pay a fee for the accounting package.

IMHO it never really took off due to the licensing and fee structure with David.

On a similar topic I remember a long ago conversation I had at DISD with Chip just before VDF 8.x came out. Some of us will remember the economic hit DAW had with VDF 7 with no runtime fees. I suggested that DAW contact the bestest and brightest minds across the VDF-world and bring them in-house to design a mid-range ERP package which DAW could market against SAP, JDE and M$ products. Thereby turning all us VDF developers into SAP/ABAP-like consultants.

Oh well ... it was an idea spurred on by knowing some SAP consultants pulling down about $2K a day.

Mike Cooper
15-Mar-2010, 02:54 PM
Thanks to all that answered...

WADR... While sharing is good, I believe that source code is owned by those who develop it.... otherwise, why invest your resources if you are just going to give it away??

My intent was to focus on a resolution to the "hit by the bus" syndrome that many of us answer daily... Somehow shooting our source code out there isn't going to make my customers happy nor secure.

So here are the three things that we talked about here, see what sounds better when you say it to a customer

OPTION 1: Our company participates in a worldwide consortium of programmers any one of whom could pick up the pieces if "croak"

OPTION 2: We are partnered with another development company who is aware of our products and is in a position to take over our software products if our company closed.

OPTION 3: Our company has 6 shareholders, 2 of whom are active programmers.

What's your vote?

Mike

chuckatkinson
15-Mar-2010, 03:13 PM
Why not start an actual poll here ?

Also I had one more tidbit. I had it written in my contracts with customers that the program source was placed in an escrow in the name of the customer in event of the company or my demise.

Jim Albright
15-Mar-2010, 03:27 PM
WADR... While sharing is good, I believe that source code is owned by those who
develop it.... otherwise, why invest your resources if you are just going to give it away??

Well, maybe. If you are a contractor and someone pays you to write them a program, then the source code and program belong to them legally. On the other hand, if you write some program and sell it "off the shelf" then the source code is your property but you had better copyright it. Since many of us write custom software for each of our clients, then in essence they are paying for our services of writing the code/program for them. I always leave a copy of the "their" source code in their possession so that I avoid the "hit by a bus" complaint/query. Perhaps some day I might lose a customer to another VDF programmer but in 26 years that has not happened to me. I have clients that have been with me over 20 years!

I do use some pieces of my source in more than one client's system. I could perhaps retain that but then that would defeat the purpose of leaving the source code with them. They would only have some of the code which would not be usable as is.

Peter Brooks
15-Mar-2010, 04:41 PM
In Victoria Australia, we have our own meetings (not very often), between us we have discussed this same issue and we can call on each other as support and the 'fall under a bus syndrome' to keep the customer happy. If I do a project for a customer I always make sure they have a copy of code that can compile on site. That makes them happy. Keeping it up to date is another issue! I also pass on another name for technical support (not normally programming) when I'm off the air.
With my own membership product, where I never give out the code, I became concerned about this great product dieing off with me. I would like to find a marketing/sales company to take over.. Any young people out there looking for a business opportunity? Best I get off my bum and go look!
I am not a formal kind of person and believe in trust when dealing with source code, and sharing. Oh and did I mention not paying money to lawyers.

PS Chuck what are the poll questions?

Peter Brooks
www.membershipadmin.com
www.membershipadmin.com.au

Mike Cooper
15-Mar-2010, 04:45 PM
Thanks Chuck

I actually advise anybody that asks that we are a corporation with 6 shareholders. As such, the corporation owns the source code and if any one shareholder dies or departs, their shares have natural survivorship through whom ever they have named in their will or in the absence of will, through the proper legal conventions that govern such a circumstance.

Since the corporation does not "die", it is up to the remaining shareholders to decide what to do ... ie hire or find a programmer (if it was I to die)... sell the source code to another company .... sell the source code to the customers ... give the source code to the customers... or whatever.

The point that I make to the prospective customer is two-fold:
1. The corporation continues to live with sufficient succession mechanisms in place to add reasonable insurance that their investment will likely continue through such a lost (no guaranties but reasonable assurance).
and
2. If I just got hit by a bus, I would be having a far worse day then they could possibly be having...

These are most often enough to answer their genuine concerns, especially when I point them to our referral list which includes customers that I have serviced faithfully for over 20 years.

BUT.... wouldn't it be way easier to say, ... "Yes. We've got that covered, there are two programmers who are owners of the company."

If you were to own part of my company, it could be done simply by the company issuing you about 100$ worth of shares (roughly 1% of the company). You would get quarterly financials, invitation to the annual shareholders meeting (which by law we must hold once a year), and dividends whenever we declare them.

Risk is virtually non-existent since you would be a minority shareholder and behind the scenes, we could share details such as source location/safe-house etc..

Point being that if you and I each have a company with the same "hit by the bus" question that you keep trying to answer... it seems a pretty simple and honest fix.

Cheers,

Mike

Mike Cooper
15-Mar-2010, 04:48 PM
Hi Peter...

I agree with all you've said.

When we do a custom project then the customer always has a copy of the source as well (although asking them where it is at any given moment can be quite an interesting experience!)

But for out OTS (Off the shelf) products... we DO NOT give the source code.... Hey, its for sale though if somebody really REALLY wants it.

Thanks for your input

Cheers,

Mike

Hendrik van Niekerk
15-Mar-2010, 04:49 PM
We can learn much from these blokes; http://www.canonical.com/

And they make money!

Garret Mott
15-Mar-2010, 04:55 PM
Thanks to all that answered...

WADR... While sharing is good, I believe that source code is owned by those who develop it.... otherwise, why invest your resources if you are just going to give it away??

My intent was to focus on a resolution to the "hit by the bus" syndrome that many of us answer daily... Somehow shooting our source code out there isn't going to make my customers happy nor secure.

So here are the three things that we talked about here, see what sounds better when you say it to a customer

OPTION 1: Our company participates in a worldwide consortium of programmers any one of whom could pick up the pieces if "croak"

OPTION 2: We are partnered with another development company who is aware of our products and is in a position to take over our software products if our company closed.

OPTION 3: Our company has 6 shareholders, 2 of whom are active programmers.

What's your vote?

Mike

I have to agree with the post that says that software written for a client belongs to the client. However, I certainly feel free to use portions of code for other clients - as long as nothing proprietary is shared. All clients (IMO) gain from this.

None of the NEDC members "give away" their code. IMO (once again) if you can't trust someone not to steal your code, you shouldn't be working with them.

re: having DAW put together an ERP system & us then being consultants like SAP: No way - for several reasons: 1) I don't believe the SAP model works in the best interests of the client (too expensive for too inflexible a system, etc.) & 2) you have to remember that not only is DAC our supplier, but our competitor as well. If they were to put together a system that we base our work on, I believe the potential for conflict grows too high.

My 2 cents....

Chip Casanave
15-Mar-2010, 11:15 PM
What an interesting thread! The issue Mike raises is important and worthy of careful consideration - coming up with good solutions for it could mean better business prospects for developers of all sizes and better protection and satisfaction for end user organizations utilizing (and relying upon) the expertise of the developer community and DAW products.

In my opinion, the customer/prospect concern driving Mike's message is valid and prudent regardless of the developers' size or financial success - it's not just applicable to "One Programmer Shops". Some large VDF developers have had prospects or customers seek various forms of continuity protection as has Data Access. In my opinion, this "concern" is just good business and good business continuity planning on the part of a user organization. Simply, if your server goes out, you have spares or a service contract; if your developer goes out, you have [???].

As I see it, the key continuity elements that bring comfort and confidence to a prospect or customer relationship to help grow new sales and business opportunities are: availability of product source code under specific, pre-determined conditions (death, disability, bankruptcy, etc.) and the availability of competent resources that have sufficient familiarity with the application to be able to do something with the source code on behalf of a licensed end user if such assistance is needed.

With that as background, some comments on the posts in the thread...

It is important to distinguish "product" source code (typically property of the author) from custom developed application source code (in most cases, property of the client paying to have it written). As has been expressed, custom code can be (and IMO should be) archived with the customer and is therefore a non-issue as to availability. Only when a developer is not able to service his/her users is product source code needed.

I don't favor the exchange of shares approach as a means of protecting customers' interests and (maybe) providing source code access. Reason: it doesn't solve the risk/uncertainty problem for the customer; all it does is transfer to a party unknown to them (the developer's share-holders) the right to determine what might (or might not) be available to the user that heavily relies on the application software. Not very comforting in my opinion and it introduces a lot of formalities, complexities and overheads for participating developers.

Escrow agreements can make source available with much less overhead than share-swapping and they provide customers (the group that needs to be served/satisfied) with certainty about the conditions under which they would get the code. That's comforting and confidence building.

For products, giving a customer access to the source is just that - access to the source. Unless other entitlements are specifically defined, all "access" means is that the source can be modified or extended if/as needed by the customer. Access to the source does not, on its own, create any new or extended entitlements to use the source code for any purpose other than what was originally licensed to the client; agreed access via an escrow certainly does not make the code available for transfer to a third party. Also, customers can be made responsible for protecting the confidentiality of the source if it is released to them.

Organizing competent assistance to use released source code and provide on-going customer support is a bigger challenge. I think the consortium/co-op idea Hendrik refers to and that the NEDC guys are executing are heading in the right direction. Pulling it together and dedicating the resources to professionally deliver on the concept is not easy and would require considerable discipline over time. Difficulty acknowledged, it could be a valuable element of providing prospects and customers with the confidence buy products and services particularly in the current economic climate.

Garret Mott
16-Mar-2010, 07:16 AM
Chip makes some good points.

Source Code: my personal method is to keep up to date code on the customer's computer when it's custom code. For code that is not purchased (such as in a package I sell to a # of people), I have a contract with each customer that current source will be kept in a safe deposit box & upon either notice or my death, they have full access to it.

Continuity: The "confederation" concept of the NEDC has been working well for about 5 years & I don't see major changes down the road. However, looking far enough ahead, we do have a problem: we're all in our 50's & 60's. Since we're independent, sole proprietors (mostly), we don't have the resources (or inclination) to bring on a junior programmer. This is something we'll have to deal with.

Hendrik van Niekerk
16-Mar-2010, 08:39 AM
talk about a gift that keeps on giving! (' feel free to use portions of code for other clients'). :-)

I have an issue with DAC poaching clients!!! Also very weary of software the they promote e.g. Cross Merge, Btrieve, the big push with IBM DB2 (a few years back), and a few more I can't recall right now. But they all fell flat!

Maybe they should stick to developing tools, as they often tell us they are, 'tool builders.' leave the customers/clients to the developers that use their tools.

Sorry for the vent, but it is a touchy subject...

Mike Cooper
16-Mar-2010, 08:52 AM
Thanks for jumping in Chip...

I agree with your assessment of what "shares" actually mean... but my guess is that people (for some strange reason) think that the bigger the company, the safer their investment is. Actually I disagree with that point because the bigger the outfit, the less likely they are to be concerned with your individual wants. We see this all the time, where a large company will simply abandon a project or product because it is simply not profitable enough. One of the products that I compete with has changed ownership at least 4 times in the 20 years that I created the original substance of what is now Visual Grasp Accounting Software out. It means that my customers have simply called on the same support point whenever they need help, whereas the competitors product changes constantly.

But I digress... On a limb (and maybe this is what Garrett was referring to as SAP but I don't know what that is)... maybe a fourth option is a small (very small) annual fee that could be paid to DAW to securely warehouse the source and under certain conditions be allowed to "open the vault". This way, we could answer the concern of the prospects by saying

"We thought of that. We have the source code on deposit with the worldwide creator of the language that our product is written in. They have access to competent and willing programmers all over the world, and in the event of this company's demise, they have the authority to distribute both the source code and the names of programmers that you could independently access."

Way more wordy then "Yup there is two (or three) programmers who are owners in the company" but definitely another option.

Mike

Mike Cooper
16-Mar-2010, 08:55 AM
Yes I do too Garrett as long as it wouldn't recreate what was written as a custom app for the original customer...

I actually have a clause in my custom program agreements that they own the source code except for source code that divulges global code that I use in other projects. The most common element that I never give the client is the code for the Login and Password encryption... for obvious reasons.

If they really want that then I would write them a custom screen for that part and charge them extra... but otherwise why reinvent the wheel.

Mike

Garret Mott
16-Mar-2010, 09:25 AM
Thanks for jumping in Chip...

I agree with your assessment of what "shares" actually mean... but my guess is that people (for some strange reason) think that the bigger the company, the safer their investment is. Actually I disagree with that point because the bigger the outfit, the less likely they are to be concerned with your individual wants. We see this all the time, where a large company will simply abandon a project or product because it is simply not profitable enough. One of the products that I compete with has changed ownership at least 4 times in the 20 years that I created the original substance of what is now Visual Grasp Accounting Software out. It means that my customers have simply called on the same support point whenever they need help, whereas the competitors product changes constantly.

But I digress... On a limb (and maybe this is what Garrett was referring to as SAP but I don't know what that is)... maybe a fourth option is a small (very small) annual fee that could be paid to DAW to securely warehouse the source and under certain conditions be allowed to "open the vault". This way, we could answer the concern of the prospects by saying

"We thought of that. We have the source code on deposit with the worldwide creator of the language that our product is written in. They have access to competent and willing programmers all over the world, and in the event of this company's demise, they have the authority to distribute both the source code and the names of programmers that you could independently access."

Way more wordy then "Yup there is two (or three) programmers who are owners in the company" but definitely another option.

Mike

SAP is a software provider (German I believe). They have a huge ERP+ system that they customize to "fit" a customer's needs. Get big bucks for it.

I'd like the DAW storage idea if DAW wasn't a competitor. Since they are, nope. This is why I developed the safe depost box idea. Once they get the source from the box, the customer can then contact DAW for a developer in the customer's region.

Mike Cooper
16-Mar-2010, 09:35 AM
Good point...

I used to keep a copy of source on file at my lawyers... Now there is someone that you REALLY can't trust!

I also got tired of getting the bill from them for that.

Safety deposit is good, except then I would have to drive into town and leave my beautiful island!

It still goes back to the basic legal fact that if I croaked, the company still owns the product and its shareholders get to decide what happens... not an end-user... not a lawyer... not anybody but the owners of the company. That is why the share issue seems the tightest to answer the concern of a prospect and really what would it hurt to create a tighter link to another VDF programmer? In the event of a bankruptcy, then the bankruptcy trustees get to decide what happens to the code.

We are all getting older and survivorship is something that we really should be taking more seriously, and if we can answer the "hit by bus" question at the same time, I think its good. I would absolutely consider this sort of arrangement with a like minded VDFer. It would certainly be affordable.

Mike

merchantr
16-Mar-2010, 10:00 AM
Good point...

I used to keep a copy of source on file at my lawyers... Now there is someone that you REALLY can't trust!

Mike

Have you looked into Iron Mountain and their technology escrow service? ( http://www.ironmountain.com/tech-escrow/technology-escrow-services.html) .

Garret Mott
16-Mar-2010, 10:31 AM
Have you looked into Iron Mountain and their technology escrow service? ( http://www.ironmountain.com/tech-escrow/technology-escrow-services.html) .

Wow - sounds perfect! Thanks Riaz

Mike Cooper
16-Mar-2010, 10:49 AM
Yes... Thanks Riaz. I called them and have info coming... They seem organized... Just the $$$$ question now.

M

merchantr
16-Mar-2010, 11:38 AM
Yes... Thanks Riaz. I called them and have info coming... They seem organized... Just the $$$$ question now.

M

Mike,

In the US, they have multiple offerings. One is a single-deposit account-single beneficiary set up which I think costs around US $1000 to set up and $900 annually. Good for when you have a single product and a single beneficiary.

Another is basically a master account where you have an umbrella account for multiple product sources and multiple beneficiaries. This I believe has a one time set up fee of $2500 and $1000/year per account (each account is for one product source) and $750 / year per beneficiary.

And Iron Mountain handles billing the beneficiary every year which takes the headache out of managing it. The source code is deposited in vault via ftp and this is the only thing you have to take care of, from time to time.

They have a "Release Form" where you specify a trigger condition. For example, you can agree to release the source "if company cannot function as a business" or "files for bankruptcy" or "developer ceases to exist" :eek: You can specify your own trigger conditions that can satisfy your clients/customers needs.

Garret Mott
16-Mar-2010, 11:43 AM
Mike,

In the US, they have multiple offerings. One is a single-deposit account-single beneficiary set up which I think costs around US $1000 to set up and $900 annually. Good for when you have a single product and a single beneficiary.

Another is basically a master account where you have an umbrella account for multiple product sources and multiple beneficiaries. This I believe has a one time set up fee of $2500 and $1000/year per account (each account is for one product source) and $750 / year per beneficiary.

And Iron Mountain handles billing the beneficiary every year which takes the headache out of managing it. The source code is deposited in vault via ftp and this is the only thing you have to take care of, from time to time.

The has a "Release Form" where you specify a trigger condition. For example, you can agree to release the source "if company cannot function as a business" or "files for bankruptcy" or "developer ceases to exist" :eek: You can specify your own trigger conditions that can satisfy your clients/customers needs.

Sure puts it out of my league. Oh well..... Starting the "developer's bank account ceases to exist" process now...;)

Mike Cooper
16-Mar-2010, 12:57 PM
Seems a bit costly... but everyone has to make a living.... I like the idea about them billing the beneficiary!

That really puts the ball in the court of the prospect who is complaining... I believe the old fashion term was "put your money where your mouth is"

Nice... I am looking into it and see a potential there for sure.

M

wila
17-Mar-2010, 04:26 AM
Hi,

You are aware I'm offering virtual remote subversion servers? So you are not limited to checking in one project, but can check in as many as you want as the virtual server becomes your ownership.
You can get a download of the server as well if you like to move and put it somewhere else in the cloud as it is a plain VMware image.

I have no problems signing contracts where I would not look at any source code you check in.
Actually I would not look into any source you check in unless you ask me anyways as I have better things to do. If there's no trust in that.. well what can I say except go to one of those escrow agencies...

It would also mean having someone who knows the VDF world and has contacts with developers all over the world.
I have no interest in taking over anyone's clients, but would be able to help if needed.

--
Wil van Antwerpen
Antwise Solutions

More info on request

Mike Cooper
17-Mar-2010, 07:35 AM
Hi Wil

What you are doing sounds interesting, but I must not quite understand the concept... how it works... what it does... and how it relates to what I am talking about. Obviously, the problem is with my understanding of what you are offering and not the other way around.

I would be happy to learn more.

Mike

wila
17-Mar-2010, 03:56 PM
Hi Mike,

OK I talked with a legal advisor about the implications.

While I can indeed offer you source control, so that the source is "in the cloud" and accessible via the internet. I can offer that on a virtual server, protected by SSH encryption. Protected physically as well as at is in a highly secured data center. Even I need to show proper identification in order to get access to my own servers. There's also the usual diesel aggregates, UPS, multiple backbones, direct internet exchange interconnects, etcetera...

However it seems I cannot offer escrow services.
Why is that you might wonder? Well my friend the advisor used words like a "legal minefield" and at first I didn't understand it, but I do so a bit better now ;)

Let me give a few examples.

Escrow services have a very specific legal meaning and it would require me to draw up a water tight contract.
That already gives me shivers, but it doesn't stop there.
There's a bucket load of problems with escrow services, to name but a few:

1. It means that your customer can hold me liable if the data (your sources) are not in the state they expect they are. Yes that can mean just about anything, even you not updating the source.
2. If there was some data corruption, they can hold me liable for that. Why is the data corrupted? Is it corrupted because you put corrupted data in there or was it corrupted because of "bit rot", was it intentional?
3. If you die, let's hope not, how long should the data be available for your customers?
4. If you decide to not pay your bills for escrow services, then I would still be liable for the storage of the source as I am a named entity in the contract between you and your customer.

and there are many more where those come from...
Basically I would need my own set of lawyers if I would start to offer escrow and I have no ambitions to have my own law firm.

Does it mean the escrow company named earlier on offers a better service?
I'm not sure, I guess it is the "it depends" answer, I don't know the company well enough to give a good answer. It also depends on what you need. Your customer might like the "protected by escrow" legal implications. I guess you are basically buying an insurance. Would it work out? Again that's the question, but you can be certain the escrow company will not be liable if something is not as expected.
It does mean they have a better legal team, that's what I am VERY sure about :D

Hope this helps,
--
Wil

Dennis Piccioni
17-Mar-2010, 05:20 PM
The other issue with all of the above, including the OP Mike, who is in Canada, and Wil, who is in Europe, is legal differences between countries.

JimNC9
17-Mar-2010, 06:58 PM
FWIW, I did an escrow account with one customer several years ago. Here's the arrangement we settled on.

The customer's lawyer drew up the contract and my lawyer perused it. Their lawyer held the source until a specific date at which time the source reverted to me unless certain conditions were met, payment for source or I was not available to continue support. I know this is simplistic as every situation is different, but the devil is in the details.

I think the key was to allow their lawyer to hold the source. The fact that lawyers are officers of the court (USA) gave me some sense of confidence.

Mike Cooper
18-Mar-2010, 09:32 AM
Thank you to everybody who responded... Certainly lots of ideas for the same basic issue...

I think that I am going to continue status quo... that is as a corporation with 6 shareholders, if I kick off then I am sure that one of them will pop up on this news group looking for a programmer.

If that is insufficient to the prospect, then I will offer that they can enter into a 3rd party escrow arrangement through the Iron Bridge outfit that Riaz brought up.... The catch is that the prospect will be passed all of the costs (approximately 3500 to set up and then about 1500 per year forever after)... Then we will see just how realistic the concern it is for them... My hunch is that suddenly it won't be such a big deal.

Back to work everybody!

M

Chip Casanave
18-Mar-2010, 03:19 PM
Mike -

I disappointed to see you abandon your "quest" but I applaud you for starting it. This is a real issue that, with a solution or suite of solutions, would enhance the selling process for lots of developers. Some thoughts...

I've used Iron Mountain and their standard structure for escrows doesn't fit what a loosely coupled group of developers (e.g. NEDC) would need. Iron Mountain is just one company in that business though. Fundamentally, anyone that agrees to do it can be an escrow agent according to what ever agreement is created to serve the parties. You may find a smaller company or a particular law firm or even Iron Mountain that would offer "group rates" that were more affordable. You and Garrett (for example) could even "cross-escrow" each other's materials (no shares required) where there could be defined conditions under which the customer would get the source (still subject to agreed useage and license restrictions). The benefit of escrow, whoever provides it, is that the release conditions are 1) pre-defined (everyone knows and agrees) and 2) established outside of a crisis situation (e.g. death of a developer; non-response to support issues; whatever is negotiated) - these are the things that really bring value and confidence to the end-customer.

Escrows don't have to be on-line although there is great convenience when they are. CDs/DVDs containing source materials are also valid to escrow and would be more typical of what was placed in the custody of an attorney - it would go into his secure physical storage (a big iron safe) instead of onto his data server. Escrowing physical materials might fit better with smaller escrow agents.

While the risks that Wil identifies are entirely valid, they can also be excluded (made "non-risks") in a well-drawn escrow agreement. For example, Iron Mountain, the "big dog" in this business, takes no responsibility whatsoever for the functionality of materials escrowed with them. They offer extra-cost validation services that the escrow's "beneficiary" (the end customer) can buy to ensure that the deposited materials will, in fact, create the intended results. Without that though, the escrowed materials are just bits a DVD, tape, server directory, etc.

Speaking specifically to your suggestion in another post in this thread, I don't think I see see DAW in the role of escrow agent. However, if there is something we can do to help grow the confidence of end user businesses to utilize VDF developers' services, we'd be eager to explore it with and for the community.

Mike Cooper
18-Mar-2010, 03:29 PM
Thanks Chip for your thoughts and insight.

I like the idea of a "cross-escrow" which is what I was getting at originally but without the shares which is an interesting twist on my original idea. (I think I like it.)

Since the customers that I do custom work for already get the source.... it is only the non-custom products that could be an issue. Normally my answer is sufficient but I think that when asked to put some money behind their fears, most would decline so Iron Mountain may never be used other than to say to a prospect... Yes we've thought of that ... here is the solution. Then the customer backs down on making it an issue and the sale can proceed.

I recently lost a sale that could ended up being anywhere from 300K to 900K (because it was to an entire province) and although they never said so, I wondered if my company only having a single developer was the issue.

Cheers,
Mike

Garret Mott
18-Mar-2010, 03:37 PM
I recently lost a sale that could ended up being anywhere from 300K to 900K (because it was to an entire province) and although they never said so, I wondered if my company only having a single developer was the issue.

Cheers,
Mike

Might well have been. I know some of us got a contract because we could offer more than one developer's services (& liability, backup, etc.). The customer was quite clear that a single developer would not have been hired.

Mike Cooper
18-Mar-2010, 03:45 PM
I know that in Canada, the number of VDFers is quite low... A few years back I tried to make contact with a couple of them and found the reception was "chilly" .... (I think it is a Canadian thing).

I also was planning to join your group, but never seemed to be able to swing the 10 hour drive for lunch (My boss only gives me half an hour <grin>)

Cheers,
Mike