jon_dahl

Hmm, I don't think that's true at all. Since when has the tech press taken an interest in open source legalities?

Not that I've had the nerve to try it.

With respect, I think it's great advice. He's far enough along that he's interested in the price and already talking logistics. "Should they be able to see the full source code in advance?" "Which steps would be involved..."

And even before that point, experienced advice is important. A good lawyer can provide that, just as YC and good angels provided it in your case.

that will cost you a lot of money and a lot of time on something that 1) you many not be interested in 2) may not actually happen. ... It would have been a huge waste of time and money if we got a lawyer like some people on HN suggested, before actually figuring out steps 1-3.

But if you find an attorney who will defer legal fees until an acquisition is finalized, you wouldn't have that problem.

* Get a good lawyer if you don't have one already. If they're a Silicon Valley company, consider getting a lawyer at a top SV firm (Orrick, Gunderson, Wilson-Sonsini, etc.) and asking them to defer fees until the acquisition goes through. That way, you're not out anything if things fall through. (Ask for a referral to an attorney on HN and I'm sure you'll get some good connections. I could refer you to a few.)

* If it's primarily a "hiring bonus" acquisition, it might be cheap and easy to do. In other words, if they mostly want you and your expertise, not (just) your product, they're less likely to screw you.

* Even if you really want the deal to go through, don't stop everything and wait for that to happen. Keep moving the business forward as if nothing will happen.

If you're running a transcoder (Zencoder, Quicktime Pro, ffmpeg) or a player (Flash, native HTML5 video in Firefox), you still may need to pay royalties.

That said, Demo Day is this week at YC, so this is probably one of his busiest times (along with interview season).

But a small startup is probably motivated by different things than a large, vaguely monopolistic company (like an ISP).

You'd be amazed how many websites out there need something like this - tens and tens of thousands. Every website with an "upload" button that accepts video or audio files needs transcoding, plus many others. And since a site like Zencoder makes it possible to do complex things with video in 2-3 hours instead of 2-3 months, we open the door to a whole new class of video functionality.

Beyond that, I'd take the annual local Bar Camp over most national/international conferences. A strong local tech community is really important.

Beyond that, I've pretty well stuck with one language in production work for about five years. But that's only because I've mostly done modest-scale web app development, which really only requires one backend language. If you stick to web apps, you can go a long way with a single backend language.

But my current startup is about 50% web app and 50% Linux app. So we're finding more and more need for C.

What do you use for video encoding?

Just to give a little detail on the video front: if you only run ffmpeg, you're guaranteed not to support a few dozen edge cases. You'll run into a non-trivial number of codec incompatibilities (>1% at a typical UGC site), audio/video sync issues, aspect ratio distortion, edge case bugs, etc. You also won't get the best output quality or compression, and you won't be able to do certain "advanced" features (like auto-rotate rotated videos).

That's not to say that ffmpeg is a bad tool. It's a great tool, and an incredible open-source project. But using it (well) isn't easy. At Zencoder, we use ffmpeg alongside a dozen other tools, both open-source and commercial. More importantly, we "drive" those tools with a lot of custom logic - to date, we have about 50 fixes and improvements over vanilla transcoding tools.

There is a strong connection between music and programming, that shouldn't be ignored. Doesn't mean that programmers are necessarily musical, or vice versa, but programming well requires similar thought patterns to music (and writing, and philosophy).

1. Inexperienced entrepreneurs

2. Big companies

If you have to sign one, make sure it's (1) mutual, (2) doesn't include non-compete language, and (3) expires. If you want to cheat, add (4) confidential information must be noted as confidential in writing or by email within 24 hours of being communicated. No one is going to do that. :)

And run NDAs by a lawyer, especially your first few. They'll talk you through the process of evaluating them.

I wouldn't sign the linked document, personally. This is pretty severe: "no person listed as a Participants may knowingly or unknowingly profit or benefit from the concepts, ideas, thoughts or information communicated or shared by any other Participants, unless hardcopy proof exists in a common medium used for communication that this information was either possessed prior to the date of this meeting by a person not listed as a Participants, or was created, refined, possessed or owned by the Participants prior to the date of this meeting, or is common knowledge."

3 years ago, Ruby implementation problems became the hot topic at Ruby conferences. Ruby was a beautiful language with an ugly implementation. It's great to see that the community has executed on this concern.

But until then, you have no idea what is going to happen.

(Plagiarized from Steve Blank...)

Since maintenance contracts are a mixed bag at best, write them in your favor - full price, fixed number of hours, use it or lose it. Then hire or subcontract the work out for some passive income.

5 years ago, my consulting partner and I ran into this situation. We managed it by hiring our first employee. We nailed down $5,000/month of guaranteed maintenance from three customers, and hired a designer/HTML guy. (Much of the maintenance work was simple HTML.) This worked out well for us - two years later, we had five employees and large projects, plus a small steady maintenance stream that was mostly handled by one person.

It makes really good espresso (freshly ground, brewed at the right temperature, etc.), and you can dial in your desired strength by tweaking the amount of water. An espresso with a few ounces of hot water makes for great coffee. Not cheap up front, but with 5-10 people using it for a few years, it isn't that expensive either.

This sounds a little messy. Draws/dividends aren't mandatory or an entitlement. As the majority holder and presumably the CEO, draws, reinvestment, and fat bonuses (to him) would be at his discretion.

If you really want to do this as an ownership thing, I'd ask for preferred shares and explicitly enumerate some rights/protections. (You have the right to inspect the books; a mandatory dividend payout; spell out his compensation in advance; etc.)

What about doing this as a partnership/royalty deal? You take 10% of all proceeds, net of hosting expenses? That sounds like it would be much cleaner. He could still buy out your share of the partnership at a later date.