Hacker News new | ask | show | jobs
by iamacynic 3366 days ago
> Give us creative freedom and ownership of our IP.

you can't be serious. why would a company even exist if all the work it paid for would be owned by someone else?

i mean sure, you can live in that world, it's just nobody would pay for anything to happen.

5 comments

Obviously an employer should own the work that their employees do for them as part of their job description. But we really need to stop accepting employment contracts that claim ownership of any unrelated works that you produce.

If I'm a web programmer, don't give me a contract that claims my paintings, music, consumer electronics designs, video games, etc, and then claim that it is unalterable "boilerplate." I don't care that you're a big company which has its fingers in many areas of business. That shit won't fly.

The company exists to sell a product or provide a service, not to own intellectual property. Sometimes the most effective means is to own the IP, but it's a means, not an end. Very few companies tend to market IP directly.

For instance, in a sufficiently broad view, 99% of AWS is other people's IP - the PC platform, hardware virtualization, Xen, Linux and userspace tools, Perl, etc. etc. And they seem to be doing a fine job commercializing it. They could build their own computing architecture, write their own hypervisor, design their own OS, etc., but that would probably be a less profitable approach. There's an existence proof in Microsoft's Azure and IBM's z/whatever-they're-calling-it-these-days, which are significantly less popular.

You pay for your business to continue operating, not for a lucrative exit strategy.
yeah sure. the open source services business model has some legs but they aren't that long.

in other words, yes it works, but not that great.

>you can't be serious. why would a company even exist if all the work it paid for would be owned by someone else?

Because software is, by default, a non-rivalrous good, and so a cooperative, share-and-share-alike mode of production makes more sense for it. Companies already deliberately support open-source contributions for exactly this reason.

A business's returns are based on products, customers, relationships. Specific proprietary knowledge may be a part of that, but it's quite often a very small piece. The more so for companies which open source core (or all) infrastructure.

Not releasing core tools can itself be a major impediment. Several years ago, a Google architect, Yonatan Zunger, noted half-in-irony that he'd settled on a hiring decision heuristic: "No".

That is: the answer to whether or not to hire anyone, was to not hire them. Again, somewhat in jest.

But also partially serious: Google has highly complex systems, operates very much on an NIH mindset, and has significant risks for any level of failure (though they've also engineered some impressive systems against many of those causes of failure).

I thought, and wrote, at the time that this was actually a major concern for me over the future viability of the company. If Google literally cannot find qualified talent, or figure out how to make the talent it does find qualified, then it cannot continue. Even accepting the hah-hah-only-serious nature of the comment, it's troubling.

Much of this problem can be avoided by opening up more of your core infrastructure, as it allows potential talent to both gain experience with your tools, and to demonstrate that experience, most particularly to you, which would then be of interest in an employment context.

Some additional context comes by way of a YouTube engineer I'd spoken with some years before that, who was commenting (this in the mid-2000s) how Google's technology was really old. That is, Google had settled on a software stack in the mid-to-late 1990s, and has (or had) to a large extent sealed itself off from the world since. As a consequence, Google's tools were diverging (in Google's interests) from those of the rest of the world.

(I don't know how that situation's played out since, though the comment sticks with me.)

Back to the question of IP: claiming rights to both what it is you teach your workforce, and what they come up with on their own (as I've seen written into employment contracts) ... betrays a staggering level of short-termism to my mind. It works out for the current King of the Hill, for so long as they're KotH, but tends to end rather poorly. Not only for those companies, but their customers, who are ultimately saddled with old, stale, one-off software for which the potential employment pools are small and generally less than stellar.

(Look up the recent HN discussion of the MUMPS programming language and the firm which continues to utilise it, largely in medical software, based out of Minneapolis. Cautionary tale. And yes, I'd heard of MUMPS decades before, and run then.)

https://news.ycombinator.com/item?id=13859961