You need to hire an attorney, one who works in business litigation (if you can find someone specializing in minority shareholder disputes, that much the better). Right now. If you're delaying on this point out of some idea of wanting to "try to fix things first" or "not wanting to be the bad guy," you're just shooting yourself in the foot and downing blood thinners to keep the wound from clotting. Working with an attorney is not the same as filing suit, and you will never be worse off in this sort of situation for having sought outside counsel. You also need to find your own attorney; the company's counsel works for the company itself, not for any of its investors, executives, or employees.

Judging from your story, your situation is pretty clear: you're being squeezed-out. Sadly, it's not uncommon. Though he might not be asking you to leave right now, framing it as in a few months is just an effort to (i) get some additional benefit out of you, and (ii) give them the time they need to break you.

There are two possibilities right off the bat: (i) the CEO is involved, which is likely given the difficulty involved in squeezing-out a shareholder + 50% co-founder; (ii) the CTO is working alone, hoping to push you out the door and benefit in some way from the resulting vacuum. In either case, you can't move forward without speaking to an attorney. And don't you dare think for one second that you can "just talk to the CEO first."

Already, you're talking about things as an employee rather than an owner. That's your first mistake. An employee might be able to be kicked to the curb, but you're not just an employee. You've already made a significant investment into the company, and from their perspective, an ideal/successful squeeze-out is one that deprives you of that ownership interest entirely. Most of these efforts are successful because they manage to position the person being targeted in a position where they just roll over. Ideally, they force the person being squeezed out to choose to quit rather than actually be fired. It seems like that's the CTO's goal in your situation.

That said, there are few programmers, in my opinion, whose work is so bad that there is zero potential for future improvement. Considering the costs of pushing you out, you'd have to be doing a hell of a lot more than just writing shit code to justify termination. Given that they want to wait until after additional fundraising rounds are completed, I doubt that your involvement with the company is nearly so problematic. Besides, you already stated that there's been a clear improvement in your code.

I was in a similar situation, once. I was foolish, stupid, and trusted a friend I've known for years. I did the development work, partner A brought his business skills and industry contacts to the table along with his money (and a third partner, B, as well). Did the work, but during that time, there was no sight of their money. One of the earliest clues I was going to be screwed was, when discussing fundraising, A mentioned his own deferred pay. Something I thought slightly peculiar given that he was supposed to be investing his own, significant funds along with B. Plus, I don't believe that he actually did any measurable work during the time period that would justify it based on what I knew at the time. Investors are rightly finicky about deferred salaries, and the bar is pretty high to justify them.

When we were at the end, I found myself being squeezed-out: in the end, they apparently figured that it'd be cheaper to outsource to some ridiculous "startup in the box" type of company rather than deal with my deferred pay and the long-term consequences of a third founder's ownership interests) even though doing so would delay things by a couple of months. They even managed to time things well: the weekend of my grandmother's funeral, after A had been told about it, they dropped their little bomb on me. The only good thing was that they walked away without getting a single line of code that I'd written.

My parting was anything but on good terms. Eventually, I wound up not pursuing the matter in court--talking it over with my attorney, it became quite clear that the legal fees of fighting them would be ruinous. That partner C was a shyster of an attorney, and all evidence suggested that they'd just try to wait out the expensive clock rather than consider settling. After all, the cost of doing so would be pretty minimal. Litigation is uncertain and expensive. Painful though it may be, you never ever litigate on principle. Not if you have any brains at all.

Even though I would have likely prevailed given the facts, I would have come up horribly in the red when it was done. A pyrrhic victory and no more. Choosing not to go down that route was one of the harder decisions of my life, made all the more difficult by the knowledge that they had, quite literally, taken even my grandmother's funeral away from me.

Oddly enough, I'm probably better off for it now that I have some distance and perspective to look back. When they launched, it was unobserved and uneventful. Even now, they're unknown with almost no traffic and engagement. They've also made a number of bad mistakes that I had identified--often through trial and error--that I had told them about. It was a submarine rigged for silent running, deep and quiet, that's never bothered to surface for air. All of partner A's vaunted experience and extensive media contacts in the industry proved for naught in the end. Eventually, they'll simply wither and die on the vine. Had they not squeezed me out, no doubt I'd still be hanging on trying to turn things around. After all, who abandons a friend? It was quite the learning experience, albeit an incredibly expensive one.

Luckily, you can avoid that sort of experience by acting now to protect yourself. Document everything, save all of your emails, chat logs, download and archive all Github comments on everything that you've worked on, as well as everything else you can. Make sure that you're also grabbing copies of emails off any servers/accounts they might have access to. Even though it will create problems if there's any litigation, there's a high likelihood that they'll do something foolish such as delete them.

You have a lot going for you right now that'll help you. First, you're obviously still needed to help their raise funds. Second, investors are scared to death of founder disputes. If any potential investors even sniff the possibility, they'll run and never look back while your current investors will raise holy hell, even if the CEO+CTO were able to find some fig leaf of justification. It also implies a deviousness that will scare investors; if they're willing to screw a friend and risk such a serious dispute, then it's also possible that they'll wander into similar situations in the future. Particularly in the early stages, investors and VC firms don't have to put up with that sort of bullshit.

This gives you an absurd amount of leverage: you have the ability to single-handedly kill their fundraising efforts now and in the future. You need to call your attorney and start using it. At the very minimum, it'll put the breaks on any plans they're currently working on. At best, it'll help you move forward as a company without having these sorts of problems lurking about in the shadows.

The question I would try and answer if I were in your shoes is the following:

Does he want me to leave the company or does he want me to stop writing production code for the product?

If its the first one, there is likely a personal issue between the two of you that needs to be resolved one way or another.

If you think the second option is what he is really trying to communicate, then I would look for other opportunities to contribute to the company. It sucks to grasp your own limitations and admit that you might not be a good enough coder to contribute to the product at this point, but this is a critical time for the future of the product. Any technical debt acquired at this phase of development is going to be very costly to pay off later since you are developing the core of the system.

However, you are a founder of the company, and I am assuming very passionate about the company's mission as well as financially motivated to see this thing through. There are tons of jobs that will need to be done as you guys grow, and each one of those is an opportunity for you to contribute above and beyond what a new hire off the street could accomplish. A lot of those jobs can also take advantage of your coding skills to either automate processes or utilize your deeper understanding of how the product works to better support it.

This is of course assuming that you guys have the cash in the bank to pay you for this work, if that is not the case then the situation is a little trickier and you will have to explore other options.

I am not a fan of this book. I wrote a review of the book as an HN comment. I dislike this book so much that for the first time in the history of my use of HN, my comment overflowed the bounds for HN comments. So, here it is:

http://pastebin.com/raw.php?i=NXgU30xK

(as a Github gist:

https://gist.githubusercontent.com/anonymous/3cc34251e501c2c...)

There are a lot of comments here from people who aren't on the python-dev list and don't really understand what this diff actually means.

The core developers are not required to maintain 2.7 post-2015, and most of them won't be involved in it. That part hasn't changed.

What is happening is that Red Hat is preparing to cut a RHEL 7 release, which AFAIK depending on how much you pay them they support for 13 years. So they will need to figure out how to support 2.7 themselves at least through 2027.

Here is where I am reading between the lines. RH are well within their right to fork Python and keep their maintenance patches to themselves and their customers (Python's not copyleft). But, they are nice guys and so maybe they are willing to upstream their changes at least for awhile if there is still a Python project willing to accept them. Again, this is my speculation based on the ML discussion, not what RH has actually said they will do.

An analogy can be made to Rails LTS, a commercial fork of Rails 2.x that patio11 was involved in [0]. Inevitably somebody is going to step in to support 2.7, and so let's see what we can do to avoid a situation where the only way to keep running 2.7 is to subscribe to RHEL.

Meanwhile, there are some large companies that use 2.7 extensively on Windows (e.g. Enthought, Anaconda) and the thinking goes that somebody can probably be found to produce a Windows installer once in awhile, assuming that Python.org will still host a download.

So really what is happening here is not very exciting. The core committers aren't doing anything different than leaving the project as originally planned. What is happening is that they will leave the lights on in the source control repository and on the FTP server, so as to capture the free labor from people at large companies who have an interest in continuing to support 2.7.

The alternative is that RH and other vendors create proprietary and expensive forks of Python 2.7. That may end up happening anyway, but it will take longer for your employer to notice you should stop contributing your patches back if binaries still appear on python.org and you don't have to ask IT to set up SCM and a bug tracker, etc.

[0] http://www.kalzumeus.com/2013/06/17/if-your-business-uses-ra...