It depends.
Does the developer has any missed deadlines? If yes, you should talk to that guy, and probably fire them if he doesn’t change. Otherwise, go to the next step.
Can it be proven they are actually working? If their deadlines are met, but it can’t be proven otherwise they are working, they may forge some records. It’s time for a serious talk. Otherwise, go to the next step.
Do these side project add value to the company? E.g. if they write libraries that are published under their name which are used in the company to make a workflow faster/easier/etc. If not, they are not really useful to the company, and their work can probably offloaded to the other developers. Otherwise, go to the next step.
Does having side project under their name allowed by their contract? If they write software in office hours and publish it under their own name, it may violate their contract; some companies like to have their developers’ work registered as their own IP, and it’s usually in the devs’ contract. If this is the case, they can even be sued, although I wouldn’t dare go down that path as a startup; unless you have good lawyers, you may get out of this worse. Otherwise, go to the next step.
Just kidding. There is no next step. If you reached this point, the guy may actually be valuable to your company. You may give them some more tasks, though, if there are any.
Sounds unprofessional to me and depends in a lot of factors!
Always on side projects? Can you specify that, if it's literal then obviously yes
If the employee is not stealing your intellectual property and is performing well and on time, I see no reason.
When I was en employee, I'd have probably quit on the spot had I been micromanaged like that.
That depends on the company and how that company feels about it, but it seems like a very ill-advised activity to me.
If it's causing a problem at work, such as lost productivity or lowering team morale, management should talk to this employee and let them know that this behavior is not acceptable during work hours and constitutes either neglect of duties and/or a conflict of commitment.
I've heard that some companies have a policy that any software developed at that company belongs to that company. These types of policies are generally intended to keep developers from running off with code on their way out the door, but might also extend to the projects this person is working on. Something the employee should think about.
Since I don't know if you are asking as the person working on the side projects, as an irritated/concerned co-worker, or as a supervisor, I would say that in all cases, this is not what this person is paid to come into the office to do (as hugoenn pointed out) and should stop unless they have supervisor approval. Even then, it seems unprofessional.
If the employee is worth keeping and is getting their work done, maybe a flex time agreement with this employee (meaning then employee can work off hours on work stuff and work on side projects during the day) is something that can be explored as well.
But, to answer your question directly: they should only be fired if they have been warned by management not to work on side projects and then continued to do so.
Chadwick Horn
Is the person writing quality code and not missing deadlines? If so, no. If not, speak with them regarding what's being missed. If it doesn't resolve itself, fire them.
Being employed in our type of work doesn't actually require someone to be at the office most of the time. If they're showing up for normal hours, producing quality code and meeting all deadlines, why should this be an issue?
The worse you would have done is that their company is successful and they leave. So it's either you fire them or they leave? Either way, they're going to leave. If the engineer is otherwise a great employee, it's best not to expedite their departure.