User:Sortie/Naively Closed Source

Hobbyist operating system developers often wish to share their work. They do this for a lot of reasons. They do it to get recognition for their work. They do it to help others. They do it to taunt others with how far they've come. There's a lot of reasons and it depends on the developer.

Unfortunately some hobbyist developers are irrationally worried their work will be exploited unfairly by other people. They make the source code proprietary (closed-source) just to be safe. There are good reasons to make hobby operating systems proprietary, but there are a lot of wrong reasons, and beginners tend to do it for the wrong reasons.

Unless you have good reasons to make your hobbyist operating system proprietary, you really should license your OSDev project freely and put it in a public source code repository for everyone to see.

Fears

Hobbyist developers that release their code as proprietary tend to do it because of these irrational fears:

• Someone might exploit the work commercially without compensating the original author.
• Someone might take credit for the work.
• Someone might fork the code and release it gratis, preventing the original author from commercializing the software.
• Someone might look at the code and not like it (it's not ready for the public).

These fears are often misguided and ignore the advantages of having the source code freely available:

• People can learn from the source code.
• People can use the source code to improve other software.
• People can appreciate the source code.
• People can review your source code for you.
• People can assess your skills and perhaps offer you a job if your code is good.
• People can access the source code without asking you, making it more likely people look at it.

Assuming no one really cares about your OS, you have more to gain from releasing it freely than keeping it to yourself.

Nobody really cares about your Hobby OS

The main reason the fears are misguided is that nobody actually cares about your hobby operating system. Many experienced developers have very advanced hobbyist operating systems and make occasional releases, and they have a very hard time getting anyone to care. If it hasn't happened to them, and their source code tend to be freely available, nobody will do it your project.

Nobody is going to pay for your general purpose hobbyist operating system. Some commercial hobbyist operating systems do exist, and nobody cares. If you can't make money off it yourself, nobody else is going to commercialize your code. Besides, if anyone actually wants to commercialize your code, what is the first obvious thing they do? They hire the original developer, the one that wrote it all and knows it best.

It's significantly easier to take credit for an existing project, granted, and it happens now and then with real software problems. Those that do this, however, tend to be wannabe idiots. Anyone moderately intelligent can see through this immediately. They definitely can't maintain the project, and those that pay attention to such feats are probably suckers. Some serious cases happen where intelligent people reuse source code in their projects and remove all attribution from the source code. Except small fragments, this is entirely unacceptable. Free software licenses commonly require copyright notices to stay intact. If a serious contender takes credit for your work in this manner, you may be able to take legal action, even if you give the source code freely away.

The fear that someone will continue developing the software freely, preventing you from commercializing it yourself, is more serious. This is a good reason to be proprietary. This, however, assumes that you can actually commercialize it, which you really probably can't.

Perhaps people actually care about your hobbyist operating system? Congratulations, that's awesome. Your reasons for being proprietary might be good rather than naive, then.

All Rights Reserved is Cool

Some people pretend to be operating system developers rather than actually being real operating system developers. They see real systems have restrictive copyright notices, horrible end user license agreements, and whatever else - and then emulate it themselves, attempting to be a mini-Microsoft. This is usually immature disillusion thoughts of grandeur. Don't be proprietary because it's cool.

What if my code is bad?

Perhaps you have stage fright? The source code isn't ready, the OSDev gurus won't like it, it'll be humiliating, it'll damage my online reputation. You're probably over-thinking this.

Hobbyist operating system development have a very high mortality rate, by even making this far, you're already in the high percentile of success. Congratulations. That doesn't mean your code is good. It's probably worthless, awful code. That's not so bad, actually. Most established operating system developers don't have that good code either. Those that have good code started out having bad code. Everyone gets better, and automatically hate their older code.

If your code is bad, releasing it makes it possible for people to review and comment on it. Experienced developers can often instantly zoom in on especially troublesome parts and remark on it. Think of this as an advantage rather than something undesirable. Use their experience to improve your work.

In fact, it's good that you are worried people won't like aspects of your code. It means you can emulate an experienced developer, or some rough approximation thereof, in your head. Listen to that developer and fix your code yourself.

Show, don't teach

This article aims to get over the stage fright and release your work freely and unashamedly. Do not assume being a moderately successful operating system development implies your code is that good. Don't fall victim to the Dunning–Kruger effect (look it up now) and think your code is a good example for other to follow. It's likely not, ask established ones before making others use your code as a tutorial. Hobbyist operating system's development has a serious problem with people presenting bad code and methodology as good ways to OSDev.

Insulting

Some people care more about your source code, if anything, than feature lists, downloadable images, or even screenshots. To them, an announcement about your OS that doesn't have any source code is just teasing and unsatisfying. It was the minimum interest they had in the project, willing to take a cursory glance at your code, and see if they can spot anything of interest.

Non-commercial only

A compromise could be to release the source code but restrict it heavily. This is somewhat silly. Nobody really cares about your code, and those that care about a small part, can't make that part of a larger free software project, where the ability to resell it is a key licensing requirement.

Ask Only Source

Some wish to help other people but don't want to publish their code publicly. Instead they post an offer to share the code with anyone who asks nicely. This is a bit silly, though. If the author is willing to share the code anyway, might as well get over the stage fright and do it publicly. This also deters people from taking a quick glance at your code, it's much more work to ask, and asking also implies that the asker take a good look, which is more than the potential asker might be willing to do.

This doesn't apply to you

Fortunately, your circumstances happen to be different and this advice doesn't apply to you. Be sure you do what you do for good reasons.