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.
Back in 1999 or 2000, shortly after Steve had rejiggered the cafeteria staff, I was walking back to my office in another building with an "afternoon doughnut" - that is, one that hadn't sold in the morning at the coffee place in the main lobby, and probably sold at a discount.
I passed Steve in the hall and he glared at me as I walked with my doughnut. Steve was in great health in those days while I was pasty and obese. (Still am, sad to say.).
But I was happy with my doughnut. Steve glared at me but didn't say anything. I slunk away.
The next day, there were no more doughnuts at any of the cafés on the main campus. I don't think it's a coincidence.
I basically did whistle my way out the door because of this.
I worked as a contractor for a very large defense company. After a year, they offered me full time employment. I specifically asked if there was a "we own everything you make" clause in the employment agreement, but I was assured there was not. I went through about five digital form contracts, and when I got to the last one, it had the clause in there. I told the woman that I wanted to amend the contract and she huffed and told me they don't do that. I replied that I was promised that I would not have to agree to such a clause, and she told me that it was mandatory, so I could take it or leave it. I asked if there was anyone in HR I could talk to about this, and was told no. So I stood up and said "please escort me out the door, starting immediately I am resigning. At the gate, I would like the security guard to search my things." (it was a secured facility, and I didn't want anyone to claim I was stealing anything later.) She asked me if I was serious, and I said yes. I was berated for how much time and money was wasted on getting me ready for employment, and I replied I was promised repeatedly that I would not have to sign away my rights, and this was absolutely a deal breaker and I didn't appreciate being told repeatedly this would be honored until the very last minute. So really, my time was being wasted too. This really, really didn't go over well. My heart was beating like crazy the entire time. My former boss was furious, the HR person was furious. The security guard was cool about it though.
In large production environments it's almost impossible to avoid bugs - and some of them are going to be nasty. What sets great and security conscious companies apart from the rest is how they deal with them.
This is an examplary response from google. They respond promptly (with humor no less) and thank the guys that found the bug. Then they proceeded to pay out a bounty of $10.000.
"In appendTo, we’ve constructed our business model to encourage our staff to keep an effective and balanced schedule. The definition of work-life balance is unique for each person, but we’ve built our organization with the features and tools that empowers our employees to customize their interaction with appendTo to their needs. This manifests itself many ways, from flex time to giving our engineers time to work on personal growth or open source projects."
When you talk about IV, use the name Nathan Myhrvold. Hell, they have a picture of him right there.
One of the best measures we have against Mr. Myhrvold -- given that he seems interested in portraying himself as a public genius of some sort -- is to drag his name through the mud over this. He's not the guy who studied with Stephen Hawking. He's not the guy who wrote the molecular gastronomy tome. He's the very, very rich guy who wants to drag down the entire tech industry to get even richer.
Note the almost painfully predictable response to the thread. Instead of focusing how OpenSSL can pull in, let me pick a number, $800k in revenue in the next year, they immediately zero in on $70 of Paypal fees as the organization's leading financial problem.
The first (and stated) effect of this policy is to weed out the unmotivated employees.
However, Dan Ariely has explained that the secondary effect is potentially more powerful. For those that choose to stay, they will forever live with their past action of having turned down lots of money to work there. So, when they're having a crappy day and hating their job, they're probably thinking "why didn't I take the money and quit?!". The only way to reconcile their thoughts and actions is to explain that, in fact, they must really love this job and therefore should work hard at it. This effect is known as ‘Cognitive Dissonance’ and is fascinating.
Here's a link to a video of Dan explaining this and a really excellent Coursera course he does on Irrational behaviour.
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:
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 . 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.
As is often the case, the problem here could have been avoided if there had been clearer and more open communication.
All this guy had to do was go to his employer and say, "Listen, you should know that I'm working on an open-source project that is in the same ballpark as what I'm doing at work. However, there is no shared code, a different architecture, and the two don't even compete against one another. Plus, what I'm doing is open source."
If his employer had said, "Yeah, go ahead -- no problem," then there wouldn't have been a problem.
If his employer had said, "We're all in favor of open-source contributions and projects, but not when they compete against our core products, from which we make money," then they could have worked out a deal. Or not. But at least it wouldn't have been left up in the air like this.
I definitely see a problem with an employee creating an open-source project in the same space as his commercial, day job. While a cease-and-desist order is pretty unpleasant, all they're saying is that he has to stop work on the project. It could have been much worse, and much more expensive.
It also seems weird to me that while the former employee is saying he needs to stop, he's letting others fork the code and keep going with it. If I were interested in picking up an open-source project, I'd be hesitant to join one in which there had been explicit legal threats against the original author.
It's very hard to take this initiative seriously. Software vulnerabilities are what software vulnerabilities are: the fundamental enabler of modern network signal intelligence. When you see Obama sign an executive order ending foreign signals intelligence, you can at that point start to believe that the USG is primarily in the business of fixing rather than stockpiling vulnerabilities.
NSA's first and overriding mission is in conducting signals intelligence against our adversaries. As people have pointed out here and elsewhere: regardless of what other missions NSA may have crept into in the last 40 years, when SIGINT comes into conflict with some other NSA mission, SIGINT wins.
The Appeals Court acknowledged that there were lots of issues at play in the appeal, but that they only had to judge one of them to vacate the conviction.
The prosecutors selected New Jersey as the venue for the case, despite the fact that Aurnheimer and his co-conspirators hadn't been located in NJ, and AT&T's servers weren't in NJ. The rationale was that some of the addresses disclosed belonged to NJ residents.
Not only did they select a tenuous venue, but they allowed the court to sidestep the issue during jury instructions. The jury decides whether venue is correct. Because venue was important to the case, the jury was supposed to receive instructions on how to evaluate the validity of the venue. But the trial court decided that venue had been adequately established.
"The venue error in this case is not harmless
because there was no evidence that any of the essential
conduct elements occurred in New Jersey. If Auernheimer’s
jury had been properly instructed on venue, it could not have
returned a guilty verdict"
One reason this matters is that the CFAA charges that were applied to Auernheimer depended in part on NJ state law. In fact, the specifics of NJ state computer crime law might have been the reasons prosecutors stretched venue so much to get the case located there. But with the Appeals Court determining that the NJ venue was invalid, the whole framework of the case falls apart.
The short answer is that miners are hoarders, and this is based on a few things:
1. In theory difficulty and hash rate should follow the bitcoin price, but they don't. You'd think that as price decreases difficulty re-adjusts as miners pull out but difficulty and hash rate continue to increase and are completely disconnected from the price. Charts:
Because of the disconnect, you can conclude that most mining business models are based on the future price of bitcoin. The miners are either true believers in the future potential, or they are effectively stuck because they have sunk upfront real USD but are currently mining at a loss and have no choice.
2. Most mining at the moment is being done at a loss. This continues from point 1, but if you look at a mining calculator your can work backwards and calculate at which electricity price point mining is currently profitable at.
As an input for our calculation, lets assume all miners are running the equivalent of a KnC Neptune, a new 20nm-based board that hasn't been released yet but it due out in a month or two (hah!):
Your gear is generating $32 per TH per day, so $96. To pay off only your hardware would take 104 days, this is with 0 electricity cost. You'd need to find electricity
at a few cents per kw to break even. The sums aren't good.
 This is possible in only a couple of places, mostly scandinavian nations with geothermal electricity supply or nations where electricity is subsidized like China and India. Even at a low 8c/kw your hardware (which is being delivered) is paying itself off in 118 days at todays difficulty rates (which won't hold).
3. A big problem with mining is that your investment decision is inelastic (not sure if that is the right term). You decide to invest at todays difficulty and bitcoin rate but outside of cloud-based mining you don't actually get started mining after placing your order for at least a month, often 5-6 months. So that means when there are little openings in the window for mining profitability everybody piles on, and you find when you get up and running that your mining estimates are an order of magnitude off because a lot of other people had the same bright idea.
The hashrate and difficulty charts show that with their increases. If you plotted the announcements of new generation mining gear against those charts in the same way Google News does you'd likely find that each big spike is equal to in time as new_mining_gear_announcement_date + new_mining_grear_delivery_date
4. Newly mined coins can't be transferred for at least 100 confirmations. This was an impromptu patch applied by the bitcoin project and a number of markets to defeat some sort of bug, but I can't recall or can't seem to find the details at the moment and can't recall what it was fixing or if the 100 number is correct. If anybody knows the details of this, i'd be interested in finding it again.
So when looking at the blockchain for newly minted coins, you'll never see them move immediately, there would be an at least 100 transaction delay (which isn't long in real time terms).
5. On non-volatile days the markets combined trade around 15M coins. On highly volatile days like today the combined volume exceeds 120M coins. 3,600 new coins are mined per day, so their input ranges from 0.01% of coins traded to 0.002%.
Note that this is traded volume, rather than percentage of coins, and the low trading days are often only a few million transactions per day.
6. You can follow the newly mined coins on the Blockchain. Ghash.io is anywhere from 35-50% of the total hash rate (which in itself is controversial) and their newly generated coins go to this address:
You can see that most of the coins remain unspent, and GHash.io is a unique case where you'd expect more of the coins would be spent, which i'll explain in my next point.
7. The hash rate and return itself has now become commoditized and can be traded like a derivative. cex.io was a pioneer here and they have an active market for buying and selling GH/s mining. Their pool is the GHash.io pool mentioned above.
Their current price for a GH/s of mining hashrate is 0.01058690 BTC, or around $4.03 USD. If you compare to the yet unreleased Neptune above, it is $4030 per TH/s vs the Neptunes $3,333 per TH with no electricity costs - and you can move in/out as you wish.
I have previously profitably traded on cex.io using an automated trading bot. It hasn't been active in a long time because I haven't updated it to suit the new conditions.
Here is my referral link to signup to cex.io, I get 10% of whatever you purchase:
I'll likely bump the version currently there with my new strategy interface in the next few weeks since I believe there are new opportunities in GH trading again on CEX. If you're interested in trading strategies, get in touch. The most basic mechanism in that bot will take your mining return and pour it back into purchasing GH/s so that your returns are compounded.
A lot of the return you get in CEX is from the other coins that are mined alongside Bitcoin when you purchase GH/s.
Note that nothing in the bitcoin world really makes sense, so the rules from normal public stock markets or strategies that might work there don't apply in the bitcoin world. You can see from the disconnect between hashrate, difficulty and price that a large part of Bitcoin price and market movement is speculation and emotion driven. You can still take advantage of this, though - as a lot of the price is driven by news events and emotional reactions to them.
Since it is so easy to move in/out of mining on CEX, you'd assume their mined coins are more liquid than the miners who setup long-term projects and are looking for a return based on future bitcoin price, but even at the CEX.io address you see only a small number of coins being moved.
8. In theory it would be possible to go back through the blockchain and measure/quantify what percentage of newly mined coins in a certain time period are being spent. Anecdotally i'd estimate the percentage is very low, and that most coins in circulation are greater than a year old (eg. i'd estimate 99.5% of traded coins were mined +1 year ago).
tl;dr: the current mining business model is based on future bitcoin price, most newly mined coins are held.
This piece is very perceptive in portraying Prop 13 property-tax caps and rent-control as sibling policies, each feeding destructive "I've got mine" politics. They both bribe incumbent owners/renters/voters with an economically valuable seniority privilege, at the expense of the future and flexibility. Children and young adults suffer the most: they move the most, and none have the benefit of paying frozen base rates established 20-30 years ago.
I wonder if both rent-control and prop-tax-caps could be knocked down in an equal-protection lawsuit. Why does the person who moved in yesterday, perhaps far needier than the longer-term resident/owner (and just as deserving of basic civic services) have to pay so much more? Is duration-of-residence a legitimate basis for such strong civic discrimination rooted in law?
What other people have said in comments is completely right: OpenSSL, or maybe just this Steve Marquess guy, is missing the forest for the trees. Or in this case, the six figure donations for the pennies. OpenSSL could raise more money in a few months of pan handling in a major city than they raise in a year.
A student group that I will soon be President of at the University of Northern Iowa received more in donations and financial support. Our student group is not the best managed, but we care a lot about large sponsors, keeping good relations with them, and making asks that matter.
If someone told me that panhandlers and Midwest student organizations are out-fundraising OpenSSL, I would scoff and laugh. OpenSSL? That's mission-critical software running on nearly every PC and post-PC device in the world. You know what OpenSSL reminds me of in this respect? SQLite.
SQLite charges $75,000 for consortium members to have 24/7 access to phone support direct to developers, guaranteed time spent on issues that matter to them, and so on.
The fact that this doesn't exist for OpenSSL is an embarrassment to project management. I made an offer in that email thread to try to raise $200,000 for OpenSSL by the end of 2014, and I'm repeating it here for visibility:
If you are an employee of a corporation that wants to donate to directly support OpenSSL development by funding staff time, send me an email right now: email@example.com
If you are in the OpenSSL foundation, send me an email right now and I will try to solve your problem by finding a phone number at every major OpenSSL using corporation and making an ask. Want me to do that? Send me an email right now: firstname.lastname@example.org
You are probably pitching your product to the wrong audience.
Your customer is not the one actually making the cards, rather their boss. Making the cards only costs the employees time, something they don't mind wasting for the most part. For the manager or owner it directly costs money, time wasted on making cards costs the employer money in the form of wages. They are also the one with the purchasing power in an organization like a school.
Creating a more efficient organization is generally speaking not part of the scope of someone making ID cards, but it certainly is for their employers or managers.
Them and everybody else. "Remember that time akamai ran vulnerable code in production for 13 years and the bug got patched two days after they open-sourced it" should be able to drive open source contributions at all kinds of companies.
As a handicapped individual, I hate all this stupid word play. I'm a cripple. Unless calling me something different is going to somehow make me run, climb, or dance again, then it really doesn't matter how you refer to me. Call me whatever you want, but don't refer to me by any of this flowery language, I find that far more offensive.
He's trying to fuck you over. Remind him that he works for you, not the other way around. Start looking for his replacement. Check with a lawyer about the security of your own stake and make sure you are good with the business guy, because the CTO has probably been whispering poison in his ear about you.