This pretty much leaves Billy in the same spot he's been for the last 18 months.

I think programmers here are assuming "execution" means coding. It really means sales, pitching, customer development. Also product development - refining the features over time. Billy will screw that up for sure.

Can he? He incorporated 18 months before Startup Weekend, and had literally nothing to show for that time, except a business plan. Evidence strongly indicates he could not (easily) "get somebody else to rebuild it". Which is why he came to Startup Weekend and defrauded 8 developers out of their time and skill. He clearly couldn't (or wouldn't) pay market rates to get it done, or he would have done so in the 18 months preceding this.

If Billy gets their code, then they compete against Billy using his client list, his price lists, etc. because those were exposed during the weekend.*

And, it's not like Billy has super exclusive access to the restaurant business. They could partner with other restaurant owners in the region who are similarly turned off by people like Billy. I'm sure those people exist, given the homophobic and generally condescending comments on display here...

So, Billy has: a code base he cannot easily iterate on because he's fucked over his entire potential employee base.

Developers have:

* A lot of Billy's biz dev work over the past 8 months.

* The freedom to exploit personality conflicts in the local/regional business scene to score additional business partners.

* Far lower costs. There are probably tons of bugs in a weekend code sprint product, and Billy isn't going to find any free labor to clean those up. Remember a big chunk of software dev is extending and debugging existing code... Billy ain't going nowhere with a static code base.

* Worst case, the "fuck you" factor and access to free skilled labor (their own) necessary to make break-even or even loss leader pricing structures. This is a unique advantage in their negotiations with Billy.

The last two together would totally screw over Billy. Imagine these developers going into a meeting and demonstrating security flaws or bad GUI glitches in Billy's product during a live meeting... the client might not go with these guys, but in the VERY BEST case for Billy, he's got to hire a freelance developer to clean up the code base. Not going to be able to exploit a hackathon for that sort of stuff, and 80% of software developer is maintenance...

* Maybe Billy claims they only get access to his work done that weekend. But that's bullshit; they developers didn't teach themselves to create rather specific types of products in a weekend... to the extent that there's any contract there, if it came out during the weekend, then it counts toward the agreement.

Billy could block the other 8 partners from using the code written at that weekend. But they don't need it. They would just need another weekend. Conversely, any one of the other 8 partners could block him from using it. He would still need a cooperative coder.

Billy might be able to make the argument that if he used the code, and no one specifically objected, it was implicit consent from the other partners. Any one of the 8 should be able to send him a cease and desist letter, and he would be stuck.

In situations like this it's very clear that whatever you make, you own.

Absolutely false: http://startupweekend.org/about/firsttimer/ "Startup Weekend doesn’t support or take part in the signing of any legal documents"

Startup Weekend would be a lot better if it required all participants to sign waivers releasing all IP generated over the weekend. That way everyone knows exactly what they are getting into.

If you really think a weekend of coding is worth something then why would you go now? It allows complete strangers to join your team and pollute the IP ownership.

10 percent of the effort is worth 10 percent of the equity, no matter how few days that effort is provided.

>> If you really think a weekend of coding is worth something then why would you go now? It allows complete strangers to join your team and pollute the IP ownership.

Strangers yes. But they self selected into groups.

At the end of the weekend, the code is owned by someone. If there's someone interested in it, the author should be as well.

I would agree that one should not have high expectations going to such and event, but one should expect not to be exploited, and if something does emerge that has legs one should be entitled to his share - and if fact (s)he is entitled to it by law unless someone cons them out of it. Copyright goes to the author.

And just to clarify - if everyone on your team signed away their rights then you would still be free to take your code and do whatever you want with it. You could build the business on your own if you didn't like any of the other teammates.

An actual partnership would probably have contracts and articles that make it easier to do business. Notably, many allow for ratification of business decisions by majority vote of the partners, weighted by their ownership share. There may be a conflict of interest if you try to make your partnership buy something you already own individually, but as long as you disclose your interests up front and recuse yourself appropriately from conflict decisions, that's rarely an issue.

That's shitty for Billy; he just signed away 18 MONTHS of business development for a 0.4% stake. Or else he doesn't get access to the code. The sure thing is that he doesn't get it both ways...

If I was being uncharitable, I could say that the reason the 0.4% offer came up in the first place was specifically to deal with this problem - by offering a trivial amount of equity, Billy has an argument that the other programmers were compensated for their time in a form that they mutually agreed to. Why else would Billy bother making this arrangement?

(edit ignore the exact percentages, they ended up with a team of 8 devs than 4)

> A work created by an independent contractor can be a work made for hire only if (a) it falls within one of the nine categories of works listed in part 2 above and (b) there is a written agreement between parties specifying that the work is a work made for hire.

If there's no law covering it, there's no IP.

If you're working on a hack project like this then insist on all copyright notices in the code and site being assigned to a made up organisation with all the names in it. So put

@copyright SmithJonesZuckerbergOrg

in all the source files and html.

Those files would be a record of the interaction and activity on the hack weekend and would allow for a neat place for lawyers to start in negotiating a smooth buyout in this situation. Because I would rather accept $1K than work with that type of individual.

Anyway, you make a great point about the commits being clear assignment of copyright, and thanks for that!

You don't have to actually subpoena GitHub and get their lawyers involved. The fact that you can means that opposing council will know that you're not bluffing or lying when you say "I authored this commit, and I have the commit logs to prove it". Or if they think you are bluffing or lying, they can certainly subpoena GitHub themselves...but if you aren't, that works in your favor.

Unless Github has some backup logs somewhere, that entire log can be wiped out and replaced with whatever someone wants with a simple `git push -f`.

Which is why it's so important to sign commits. You sign your commits, and keep your private key private, and as long as any copy of the repo exists anywhere you can access, you can prove authorship/ownership.

Commit signing is also very useful for vouching for code integrity.

[0] http://blog.printf.net/articles/2015/05/29/announcing-gittor...

No, for this to work, you'd really need to timestamp either the git tree hash or (preferably) the hash of the GPG signature (or the signature itself).

Most timestamp service hashes are necessarily public (for trust reasons), so an attacker could grab one and go back and include it in his signed commit message.

But if you timestamp your commit hash (which is a cryptographic hash after all -- albeit an increasingly weak one) or timestamp the signed commit, then it can't be forged (since the attacker can't go back in time and use a cryptographically-verifiable timestamp, like the ones indelibly embedded in the blockchain).

/s

This method of founding a tech startup doesn't really work. Either learn to code yourself, or build a trusted long-term relationship with someone who can.

His goal is not to get customers with this code. His goal is to get investors. And, I wouldn't be surprised if he succeeds. He helped the team win Startup Weekend with a seemingly effective presentation, after all. Further, I wouldn't be surprised if his plan now (that it's become clear his developer team wants nothing to do with him) is to raise money with the prototype built at Startup Weekend, and then trash it and start over, so he believes he is free of the obligations he agreed to in order to get the code (that 0.4% stake everyone agreed to). Investors always ask who else you have equity and economic obligations to...and I'll wager he neglects to mention the situation with 8 devs owning a total of 3.2% of his company.

Regardless, dude's a douche hat, and I would hope nobody would fund him. Nobody smart would, since he's not gonna be able to deliver a product worth selling.

I think it comes from the fact non-technical people don't necessarely understand what building software is. All they see is some nerds doing arcane magic with keyboards.

The question is, can we do anything to make things better?

Such a startup weekend would be a wonderful occasion. Why organizers do not draw up a simple legal checklist is beyond me.

Just drafting a paper signed by the whole team at the beginning of the event stating "I am going to put ~30 to 40 hours at my hourly rate of $X and thus my contributions can be bought for $Y", or whatever stock terms float your boat, would set clear expectations. They actually were less naive than most since they had that "handshake deal", but they should have gotten it in writing.

That, and realizing "Applicant tracking system in an original niche" is not a revolutionary idea. They owed that Billy guy absolutely nothing and should probably have kicked him out.

They see SW's (in general) as a way to get free labour, they've just learnt enough nerd-speak to bamboozle them into providing that labour.

I've been in the receiving end of "You know this'll be a commodity soon enough" from a guy who's product still relies on a database from 1992, renormalized of course, and who stores dates in packed 16bit numbers.

My advice is to reply with "Great. Best of luck, but you can't use my IP." Better yet retain operational control at all times - don't give out Heroku credentials, etc.

They usually go quiet when you finally show your cards and it's a straight flush.

What would suck is doing everything to protect yourself, and then need to waste money (if you can even afford it) on a lawyer if the idiot tries to sue you.

1. Nerds should run companies. The core problem is this assumption the CEO needs to be a "biz guy" like this seeming frat boy. I don't know why nerds think this, I think it may be some high school trauma.

But being the CEO is a lot easier for a nerd than it is for a biz guy-- biz guys at best are going to not touch the product development side, and more likely are going to undermine it... while nerds can easily manage a VP of sales, a VP of marketing, etc.

So first solution- don't work for biz guys. Only work for nerds. (and for purposes of this discussion, I consider Tim Cook to be a nerd- his nerd area is global manufacturing, but he's not a "guy who owns a restaurant" and thus has no relevant skills for a tech startup.)

2. Biz guy ideas are not better than nerd ideas. I don't know if SW doesn't allow it, but they should have come up with an idea that they, as engineers, were passionate about and worked on that. I think the results would have been better.

3. Focus on bootstrapping. The way biz guys get in is that they have connection to money or money and they use that money to take over and exploit the nerds (VCs and the bad angels are nothing other than these exact same biz guys--only VCs are incentivized to get you to bet it all on a longshot to be a unicorn because it's better for their portfolio, even though it diminishes the likelihood your company will be a success. )

It's a sometimes useful generalization, but it can also be a shortcut people use to trick themselves into thinking that they are part of some wise and good group of people (who coincidentally are just like them!) and gives them carte blanche for othering anyone they decide they don't like or don't want to work with.

It's almost impossible not to do this, it's kind of a necessary evil when you're constantly dealing with lots of different types of people and don't have much information about them to make more nuanced judgements. Not a problem as long as people don't start mistaking the mental shortcuts and generalizations we all employ for reality. Most of the time I behave as if pi is 3.14 because that usually works fine, but I never allow myself to start thinking that it actually is 3.14, which is the vibe I get whenever anyone starts talking about how everybody is either an "x person" or a "y person".

Diving in a bit better: a tech person may well obsess over implementation details (because they understand, or think they understand) them better than whoever is on the dev team. They may rabbithole working on a rewarding intellectual work that has nothing to do with the success of the business.

They may not even know how to deal with a veep of sales or marketing, because they may not have any idea how that world works. I have a friend who is a CEO that, for the longest time, thought marketing was basically lies, and so saw no reason to invest time in it. They've since reconsidered their position as their business intelligence has caught up with their technical intelligence.

As developers, especially ones who haven't really built and scaled a business, we always love to think "Hey, I build the product--how hard could the rest be?"

We're usually wrong.

Sales, marketing, legal, taxes, accounting, organization, etc., are hardly things people automatically know how to do.

Now, that doesn't mean they'd make a good CEO, just a better sales person, which is also a critical skill for most startups (although I do like the "growth engineer" movement, which puts some of this power back into the hands of engineers, in marketing if not in sales).

And for those that read everything in the literal sense: this is a joke because of the /s.

I've seen some really scary situations that started with throwing things over the wall- like having investors and board ready for the finished product in a few months, while it's just some wannabe CTO and maybe a family member helping holding the pile of shit code with some seriously rich and powerful people expecting that they will be in production soon, for large companies they've already talked with and planned to sell it to.

Steaming piles of shit become rolling tumbleweeds of shit doom become ticking plutonium-enriched time-bombs of every-kind-of-animal feces...

shudders

More like:

GOOD execution is one of the major problems.

This is why engineers should not be afraid to sell, or at least, not be afraid to be out in front. The power in any organization comes from who sells the product.

Good businesses understand that all their functional areas are important, and don't try to preference one over another. You may need to focus on one at first to make progress with it, though I'd argue that when you first get started, that one area should be none of the above (it should be customer development in the Lean Startup sense: talking to people to get a sense of what they need and how they do things).

The big challenge in enterprise software engineering is that your "customer" is the person who forks over money, not the person who uses the software. Pretty much all engineering effort is devoted to pleasing them. Engineering requirements for enterprise software are often insanely complex and sometimes even conflicting, and most of the engineering effort is devoted to satisfying them.

If you look at product/UX debacles like Taleo or Lotus Notes from the perspective of a department head buying them (rather than from the recruiter, job applicant, or ordinary worker who will be using them), a lot of enterprise software makes sense. There's a lot of effort devoted to reporting requirements, to making sure the buyer has visibility on what all of his department is doing and conversely can make that "productivity" visible to his boss, to covering one's ass with regulatory requirements, and not much effort devoted to making things pretty or productive for the end-users. That's because the end-users are not the buyer of the software.

Indeed, a lot of the investment thesis in consumer/smallbiz Internet is this idea that software should replace middle managers entirely, and so the end-users should be the actual buyer of the software who need it to make money, basically replacing management with markets.

Billy doesn't exclusively own the codebase or product. Any of the devs could reasonably start a company, use the product, as long as they award 0.4% to each of the members in his venture. That's what the handshake deal seems to have been all about.

It makes sense for the devs to either say 'buy out exclusive rights to the work and we forfeit the 0.4% share and be on your way, or keep the work, we'll compete with you (and grant you 0.4% in our venture, too, according to the handshake deal) and we'll see who can iterate on the codebase faster and run a successful business.'

The devs still have the power despite Billy's asshole move.

If your goal at a startup event is to have fun, jam on something, see what comes of it, then it's easy to succeed.

If your goal at a startup event is to make something valuable, you've already lost. There is no winning. This is the worst possible environment to create a new business in, and there are way too many variables. Everyone will feel cheated no matter what the arrangement is.

I think you've flipped the situation around a little bit here.

The point is, it is startup weekend, it's time to have fun, to learn, collaborate and do something interesting and a lot of the guys going aren't necessarily interested in ditching their jobs and going full-time startup. In fact most people came to the weekend without any ideas they actually wanted to launch, simply interested to join an existing team and have fun.

So one of the developers who is like this basically proposed the 0.4%. You make it sound as if Billy said 'hey guys work for me for 2 days for 0.4%'. When in reality it was a developer who said 'Hey look, this is going to be fun but let's agree on something simple, if any startup actually does come out of this, let's all have a 0.4% share even if you're not interested to invest anything in the startup apart from this weekend's work. This way everyone is rewarded without having to exchange any money, and only if whatever we built this weekend actually ends up having value'. And the others agreed with that.

This may not make sense in every situation, but I think it was pretty sensible here and I don't think it was insulting either, particularly when the dev proposed this reward himself, for himself, not as some kind of payment to others for getting his company off the ground.

I'd argue that they'd need to make a case, and the additional share would be conditional. Like "If you can close $100K in financing then you will get another 40% stake."

Likewise if team members really do want to quit their jobs and chase after this, they'd be accommodated in a similar capacity. Adjust the share balance when events happen, not by padding it heavily up front with the expectation that they will happen.

Otherwise you're valuing your contribution vs. some future unknown, yet saying with certainty your contributions are worth 0.4% of that. The chance of that being fair is basically zero.

Exactly, that makes total sense. Why then did one of the developers, OP's friend, another developer that agreed, propose 0.4%? This is where I get the feeling OP isn't telling the whole story.

Knowing nothing else and asked to speculate, I'd say that they proposed 0.4% knowing that Billy wanted to work on his own idea and wanted to turn this into a company, while they just wanted to have a fun startup weekend working on someone else's idea and then go home and go back to their normal lives. As a reward, they propose 0.4% of whatever company arises out of the startup weekend, without wanting to be part of anything else later. Billy said he's happy with that arrangement and they go forth.

Why 0.4% and not 100% / n team members? Because it makes no sense for the team of 9 people ultimately for each to have 11% equity in a company that perhaps only Billy will be running. That would mean if a company is formed and everyone gets an 11% share, but nobody actually works there except Billy who works 80 hours a week the next 10 years and turns it into a success, he has the same 11% share as any of the other guys who merely spent 20 hours over a weekend on this. That's why, if you're not interested in running this company beyond StartupWeekend, you'd propose 0.4%, a small percentage for a weekend contribution that is still significant if the company ends up worth a lot (e.g. $10m, means $40k for a weekend of work). A more granular valuation of the work is to simply value it as a fixed amount of money, say $1k per dev, but then you're getting in the realm of 2-day work-for-hire which doesn't make much sense in the context of StartupWeekend, it requires money transfers, investments and risks, and it just doesn't make much sense in a 2 day context to hire random stranger devs. Saying let's see what is possible, if it has any value well let's each have 0.4% even if we don't continue past this weekend, is more practical.

This is why I suspect that the article is only part of the story and that perhaps everyone was aware that Billy wanted to turn this into his own company and that the rest just wanted to work at it over the weekend for fun and get 0.4% in case their weekend work turned into a valuable enterprise. Why else would you agree to 0.4% and not just say 'let's see what we can come up with this weekend, and after incorporate it on an equal basis if we want to, or buy out the work by those who aren't interested in pursuing it further'?

I thought they never actually signed anything with regard to that.

He still owns all the code he wrote. If Billy uses that code in his own business that would be unauthorized and legal action can be taken.

The start-up is called StaffedUp and it's site is up and running (with that unlicensed code, I presume): http://www.staffedup.com

This is also why it's such a pain in the ass for open source projects to changes licenses -- they have to get permission from everyone and anyone who contributed code, or rewrite that person's contributions.

You write it, you own the copyright for whatever part you wrote unless you formally transfer your copyright via contract. You don't even have to file any papers to get copyright, it's automatic.

So in this example of startup weekend, whoever writes a piece of code owns it, whoever writes website copy owns it and so on and so forth to the extent that the startup weekend ip policy doesn't setup something different for participants.

(edit: fixed the last paragraph)

I suspect anyone on the SW "team" could claim ownership of the code and any aspect of the business.

SW trys to avoid these issues during the weekend ..from their FAQ: (http://startupweekend.org/about/firsttimer/)

How do teams address the issue of IP/ownership? As with any startup, the team decides. Startup Weekend doesn’t support or take part in the signing of any legal documents at the events themselves, and while Mentors with legal backgrounds are often present and able to give general advice, they are not permitted to give specific legal counsel.While it doesn’t hurt to be clear about your individual expectations from the start, we’ve found that teams who don’t spend time addressing this issue until it actually matters (i.e., there is a tangible product to have ownership of) are much more productive and successful than those who do.

You can always license any code you wrote.

> How do teams address the issue of IP/ownership? As with any startup, the team decides.

That's not how copyright law works.

No you can't ...not if someone else has a claim on the work you do. I can't put "copyright <my name>" on the code I write at work ... its "copyright <my company>"

EDIT: re license vs copyright : I also can't just unilaterally decide what license I use for code I write at my company. I think its reasonable to think the same would hold true given that FAQ item.

> That's not how copyright law works.

That was from the SW weekend FAQ. But I think that FAQ holds weight -- just like my statement above. If the rules for the weekend are the "team decides" you can't just go claiming ownership of stuff you did for the team.

Without surrendering copyright, you absolutely do have the right to unilaterally license your code in whatever way you want. The entire reason that companies require you to sign IP agreements before starting work is to ensure that you don't run off with the code.

The developers wrote the code and never signed a license to Billy's company. They own it. End of story.

thanks for the clarifications.

so the "you can always license any code you wrote" isn't always at all

EDIT:

so, my "exactly" above is a wrong. I see your point about signing a contract vs not. got it. I'm sticking with my arguments about "always" ..its all I have left :)

BUT! Terms like this need (both legally and ethically) to be explicit, and should have provisions for both "person X stays on-board" and "person X leaves after the weekend."

That's a nice opinion. But as you say, it's a "rule". It's not the law.

And the law disagrees with you. If 5 people write code with no legal framework in place (such as a written contract), they each own their individual contributions.

it would interesting to see something like this tested in court.

Do you know what qualifies as a legal framework when entering a weekend hackathon? Is there a different bar for something like this vs a standard employment situation?