Probably some reality shaking out. Uber's engineering team puts out some impressive stuff, often as OSS. Their engineering blogs are regularly on HN. I've been genuinely surprised that they churn out some of these things and release them for free given their relatively extreme financial situation.
In contrast to companies like Google, Apple, Microsoft, Amazon etc. that have mountains of their own money to burn (rather than investors') on research and OSS side-projects, it always seemed to me that Uber was trying to play the same game, but far too early. Paying lavish SF engineer salaries to generate cool, but not revenue generating, software is probably excellent for morale, culture and recruiting, but a dubious use of resources when you are losing money seemingly faster than it would be logistically possible to literally burn it.
Saying they're ~ "culling the low performers" can be entirely true, but it is also a Silicon Valley, meritocracy-culture-friendly way of saying "we're losing far too much money to pay bloated growth-stage poaching-game salaries to engineers, so if you're not working on something that generates revenue, glhf"
> that have mountains of their own money to burn (rather than investors')
I totally agree with everything you're saying. But I'm going to quibble with your phrasing. Apple's cash reserves belong to the shareholders just as much as Uber's funding rounds.
Too many CEOs operate under the mistaken belief that retained earnings is "play money" in the way that paid-in-capital is not. For investors, retained earnings are subject to the same opportunity cost of capital as funds raised by equity or debt.
Its management's responsibility to deliver returns exceeding the firm's weighted-average cost of capital. If they can't do that, then they should return capital to the shareholders, who can then use it an alternative higher-returning venture.
Good point. I didn't have that perspective in mind so the wording was off.
My sentiment was that if a company is losing money consistently and egregiously, they are on borrowed time and a borrowed dime in very real terms as the trajectory is towards 0 - but the context is largely psychological. To your point, waste is waste. I agree wasting cash generated from profits is equivalent to wasting it from earnings.
I'd insist there is some practically relevant difference in there though.
Wasting money during a trajectory to bankruptcy creates a narrative of negligence that accelerates failure, while wasting it during a consistently profitable trajectory seems like sub-optimal management. The kind of thing that is theoretically identical, but in the real world of behavioral economics, the former seems more certain due to how easily the trajectory to failure can be estimated. The latter creates a weak narrative because of hidden information - nobody will ever know what "could have been" and so can never quantify how sub-optimal the management was.
E.g. nobody is dragging GE executives out of retirement/the grave to answer for long-term effects of sub-optimal management, and further nobody could prove at the time it was sub-optimal, only hypothesize. On the other hand, everything Elon Musk does at Tesla is torn apart and front page news, because they have a trajectory towards failure a high school student could easily calculate.
So "management's responsibility" to optimally allocate capital is sound in theory, but in the real world of imperfect and outright unknowable information, nobody ever really knows what optimal is. Sub-optimal comes to be expected as normal, but accelerating a trend towards failure is a powerful defining narrative. Somehow this matters.
Why would someone whose been tasked with a job that is involved with gathering as much money as possible, be willing and able to just turn that part of their personality off and start giving money to someone else? Why would they do this just because its investor's money rather than customer's money?
I get that this is the normal ideological description of firms post-70s neoliberal whatever, but if that’s true, like why not just say firms suck, we need communism? Like your description makes Pikkety look like an optimist. “The purpose of a firm is to help rich people get money faster than other rich people” logically implies that eventually a small group of rich people will have all the wealth. That’s feudalism. If that’s the goal, let’s start a revolution instead.
I agree, but the theory "firms exist to maximize shareholder value" ensures that they will be.
Put it this way: gravity turns space dust into supernovas. Dust is just ever so slightly attracted to other dust, so it accumulates and accumulates, and eventually it becomes so massive that it forms a star.
The theory that firms should beat the market makes money gravitational. A shareholder who beats the market will get more money than other shareholders. Now they have more money that they can use to invest in other market beating schemes, etc. If whether a firm beats the market is random, then some investors will win and some will lose but it all balances out. But if beating the market is not random (and how could it be totally random?) then those with the most money can invest in the best firms faster and more easily than smaller investors and crowd them out. Remember that companies only have a finite number of shares, so not everyone can invest in a winner. If there's even a slight bias towards having more money making it easier to beat the market, then eventually you will get a supernova.
We all understand this on some level. Why is insider trading illegal? Because it makes it trivial to beat the market!
Put it this way, if the standard theory of why capitalism beat Soviet communism is that competition created better products etc. none of that requires that the goal of firms is to create better than market average returns to shareholders rather than the goal of firms being a) earn sufficient profit to continue to exist b) benefit consumers c) benefit employees d) benefit shareholders. Yes shareholder would prefer to invest in companies that prioritize them over all else, but why should we the public not say “that’s not an acceptable charter. We don’t want feudalism to happen again, so we are not allowing firms to prioritize shareholders over consumers.”
If the only defense of capitalism is competition, why not market socialism? As in, markets, competition, and entrepreneurship still exist, but all firms must be worker-owned.
Because then you would be forcing everyone to be an equity partner, even if they would rather take a higher salary than share in the risk. Doesn't sound like freedom to me.
Quibble: I don't really see worker-owned firms as a form of socialism, which I understand as the government ownership of the means of production. Worker-owned firms I associate more with distributism.
Worker-owned firms are a great idea, but if that's the only ownership model then you lose some ability to diversify your investments. Everyone's 401k goes poof.
Thinking through this, what are the alternatives? Simple cash reserves are out (because most societies can't seem to shake the tendency towards inflation). Bank savings accounts are a good idea, although impractical in our current society because interest rates are so low.
Alternatively, management could be inclined to not give piles of wealth to people who had zero hand in its creation (shareholders, modulo some employees who also own shares [rounding error]) and use it to pay engineers to do interesting things.
You need 4 things to run a company, in small companies some roles may overlap. In no particular order Workers, customers, management and shareholders/capital. When one gets too much power the company goes rotten. Usually but not always, it’s management.
Shareholders pick the board, board picks CEO. If CEO wants to spend money that his choice until the board gets rid of him.
It's not some sacred pile of cash that 'belongs to investors/shareholders'
It's especially a dick move when everybody already knows they're hurting for cash, and the official position could be "we just can't afford all these people" without the company losing any face. They aren't fooling anybody by pretending it's not about the cost.
If you could chose low performers, lay them off, and be more focused and higher productivity with the remaining people...
_Why haven't you already done that?_
Nobody likes low-performers, even when you're flush with cash. Fixing their mistakes is demoralizing for your high-performers. The word gets around that you have low standards, and it's hard to recruit.
The only way to get your money's worth from them is to put them in death marches and grind them down until they burn out and quit.
I am always extremely suspicious of claims that a company is going to lay off its poor performers and magically be better. If they're telling the truth, they are actually saying that their existing managers are incompetent.
There's a reason that all tech companies try to brag that they only hire the top performers.
Fine, but laying off people who don’t work out is an ongoing process in all companies. If people haven’t already been let go as a part of the company’s existing management review process, what changed suddenly that the company can suddenly lay off a bunch of people in one go and “improve?”
Another way to think about it is that everyone has some productivity, some contribution to the company’s net progress. If someone’s contribution is negative, they should already have been let go.
If their contribution is less than others, maybe “bottom 10%,” but it is still positive, you may be letting go a relatively poor performer in a round of layoffs, but you’re still shedding a person with a positive contribution.
You are going to be worse off, no matter how you sugar-coat it.
> Nobody likes low-performers, even when you're flush with cash. Fixing their mistakes is demoralizing for your high-performers.
If you define performance as change over time then this would seem to have nothing to do with mistakes. From what I've read about the space shuttle programmers, they would have been classified as low performance (low change over time) but who also made with very few mistakes (as I understand their process). At the other end you could have high performing programmers (lots of change) with high defects that they're always fixing (which could in turn qualify as still more change).
Well, the colloquial understanding of a “layoff” is that it is not based on underperformers, but based on changing business conditions.
For example, closing a plant, or getting out of a line of business. If Uber decides not to have anything more to do with self-driving vehicles, they might lay off everyone in its division.
That would have nothing to do with poor performance on the part of individuals.
On the other hand, there is “These people are underperformers,” which is part of Uber’s allegation as they throw their former employees under the bus rather than take responsibility for their management choices.
I contend that if people are underperformers, a constant trickle of letting such people go is not bad for morale. It’s perfectly normal.
“Did you hear they let Dave go?” “Yeah. What took them so long?” That’s the usual talk.
Whereas, “Did you hear that they shut down ML?” “Yeah, and it was half the database tuning group last month, who’ll be next?” “I dunno, but I’m not hanging around to find out...” is the thing you are describing.
Long story short, I agree that a trickle of layoffs is not good, but I suggest that this is true when the people being let go are not thought of as holding the company back.
I disagree that it doesn’t matter who it is. If they are underperforming in the sense of being bottom 10% but still carrying their costs, I agree with you about trickle, but then we can’t claim that letting them go makes the company stronger.
But if they are underperforming to the extent that letting them go makes the engineering group more effective, then management should have identified them earlier, done everything in its power to make them perform, and let them go if they didn’t improve.
Ignoring net negative employees, or being blind to whether they are net negative, or keeping them around even though they are known to be net negative is bad for the company’s bottom line and bad for its morale.
Hello Reginald, I am a fan and a fellow Torontonian!
I agree with your points, but optics might depend on a company. In a startup or smaller company being aware that underperforming employees are let go might actually improve morale. For bigger companies it is a typical situation that you notice or get to know that people from other teams are gone, but you may not be aware of their performance.
True, but then again you probably don't notice so much. Every month there is a new face here and a new face there, and one old face has... Quit? Retired? Been fired? Who knows...
I like reading your writing so I would appreciate your input/feedback either here or you can email me at gmail, whichever is more convenient.
> Nobody likes low-performers, even when you're flush with cash. Fixing their mistakes is demoralizing for your high-performers. The word gets around that you have low standards, and it's hard to recruit.
Fixing mistakes is part of development. I am yet to be part of a team that never made a mistake. Mistakes are how we learn and get better.
If the same mistakes repeat, THEN you have a problem but if a single individual is to blame everytime, then it's not the individual's problem - you have a bad team. Your team has failed at teamwork - the primary focus of any team.
If you have a team of dozen engineers making a car, the car does not drive until all the parts are not only in place but they all work well together.
The way to make all parts work well together is to have the designers of the parts communicate and work together, well.
If the engine guy is not talking to the intake and exhaust guys, don't be surprised if there are leaks at best or the engine blows up at worst.
I AM assuming each team member went through an interview process. If the going was tough where you could not interview and had to let just any person in, hopefully this person helped you through the tough times.
What value does the interview process provide if you can't figure out if your candidate is a high-performer or not?
Why did your interview process select a low-performer?
Also, performance is the output of a team - a single person should not be expected to provide high-performance day in and day out.
That's impractical to expect out of a human being. A machine and a person have vastly different characteristics.
If my team is working well, we will have a high performance team. There is no other way to have high performance sustained over a long term.
Each team member needs to actually looking forward to working with each other.
The other extreme is programmers work in these silos and come up with solutions that barely work well with each other and then there's blame game being played.
Why do that nonsense? Save money? No - of course not!
Just work as a team!
> The only way to get your money's worth from them is to put them in death marches and grind them down until they burn out and quit.
I don't follow.
Death marches?
First of all WHY do this at all?
What's wrong with the alternative "Hey, it looks like it's not working out. We will be letting you go and support you in looking for a job elsewhere over the next X days"
At one point in time in the past, you and your team interviewed this person and found them useful - what changed that they are no longer useful?
Was an error in hiring made?
Own up, take responsibility and move on. Make the interview process better.
Did the person expect to get a larger bump come bonus/review time that did not happen and now they are demoralized and upset?
Own up, take responsibility and move on. Clarify better what bumps and bonus would be like and how much effort that would entail next time.
> I am always extremely suspicious of claims that a company is going to lay off its poor performers and magically be better. If they're telling the truth, they are actually saying that their existing managers are incompetent.
I also don't follow this and want to hear more about this perspective.
What happens to the people working in mining, transporting and delivering ice from Iceland to California when refrigerators get invented?
Are those people inherently low performers or has the industry they work for shifted beneath them?
We (developers) work in an area of high specialization and the market values us for it (to the tune of six figures).
I have worked at both product and service companies before where entire departments were laid off because a contract did not get renewed or the market changed.
Most employees AND manager involved there were and continue to be competent. We even hire and refer each other wherever we might happen to be to this date even though we met decades ago.
People who aren't critical to the core product, or whose projects aren't big revenue generators. They might be high performers while being technically unprofitable.
Not necessarily a bad idea, but disrupting those business critical teams by just swapping out people could actually slow down execution and hurt revenue.
I'm implying that rather than laying off top performers you find them a different role in your organization.
Granted if the skill set is incredibly niche--such as hand optimizing HC12 assembly and you've moved to ARM then perhaps not.
It's hard to imagine a scenario where an entire project teams skillset is so niche that they couldn't find a home for top developers in other parts of the org.
You can't just swap out members of a team, or add more members to a team, and expect the result to be faster execution (in short run) even if the new team members are high performers.
In the first case, you're losing team members with tribal knowledge of the system and its requirements. In the second case, you're exponentially increasing the pathways of communication. In either case, you still have the ramp-up time for new team members.
Any number of reasons. They might be high performers in skill sets not needed in those business critical projects. You might be leery of the time needed to get up to speed on something completely different.
You can just say something like "we're restructuring to focus on our core competencies". If you fire a bunch of non-critical staff, you just told investors "our revenue to cost ratio is about to get a lot better" and so if anything investors who have been watching the decline are going to recognize you are doing something about the problem.
Indeed, HP (or HPE and HP Inc.) has done many layoffs in the past few decades. I just narrowly dodged one a number of years ago. Pretty much always the goal is to simply reduce costs without reducing revenue (as much). Investors don't care how much staff you have, they just care if you are making money.
I completely disagree. Which would you rather have:
(a) Business is booming, but leadership holds off on hiring because they believe the boom won't last forever.
(b) Business is booming, so leadership hires to support the boom. The boom eventually subsides, so leadership decides to lay off as the business is no longer there.
Fortunately, even as an employee, I'd much rather have (b) (assuming the timeframe was relatively decent, i.e. I didn't get hired and laid off in 3 months).
I've said this before, but in growing industries, I do not believe lay offs are something to fear. I mean, given the desire for experienced engineers and product people, I have no doubt these Uber folks will get snatched up extremely quickly. (and to emphasize, I certainly do NOT believe this is the case with shrinking industries)
You can't be a unicorn and not be able to afford the people. This is not a story for people in the tech who know about the industry and the six figure salaries engineers at unicorns make.
This is a story for retail that will be buying stock. "We cannot afford X" can be an stock buster.
So?
They could lie (which is far worse) or say nothing and let people speculate.
A job candidate with solid skills will be able to show their value to employers, and if an employer puts more weight on this quote over a candidate's qualifications then it was a bullet dodged.
Good point - didn't think about that at all. Did you mean think before I speak, or Uber?
In any case, yeah, in that respect it is a massively shitty and unnecessary thing to do to employees. They could have easily left it as "re-structuring" without a risk of tainting the reputation of former employees.
Certainly that should be part of it, but the goal is to reduce costs without reducing revenue. Low performers are certainly a cost, but there's only an indirect relationship between job performance rating and revenue.
They did some impressive stuff, but internally the eng org was bloated as hell, thanks to Thuan's leadership. Ironicaly, Thuan recently asked his directors to tell him which departments are bloated so he could decide who to cut. So much for the "amazing leadership".
>> In contrast to companies like Google, Apple, Microsoft, Amazon etc. that have mountains of their own money to burn (rather than investors') on research and OSS side-projects
You are assuming that these companies are letting engineers to do side-projects that are unrelated to their day to day work?
As far as I know the OSS projects these companies put out are in line what they use internally for day to day work and it is absolutely core to their business.
A side-project isn't by definition irrelevant, and of course by sheer probability the engineers at those companies are, on average, going to create things that are within their area of expertise which is usually related to what the company they work at does :).
The motivations for making software OSS are varied and often strategic. For example software is often open sourced to:
* deliberately commoditize it - to eliminate competition and differentiation in that area / stack layer
* leverage additional (free) testing and development.
* Drive ecosystem / platform adoption
* Literally free up customer budgets to be spent with them, rather than on licensing 3rd party software
* Intangible benefits like community image, employee satisfaction, etc.
* Some combination of above when the software is useful internally, but simply not in a market that the company wants to compete in, or a market worth their time
In any case, the point was that they are "side-projects" from a business perspective in that they cost money but don't generate revenue - the benefits are hard to quantify. Successful, stable companies have much more breathing room for strategic and the "hard to quantify" ROIs than does a company on a trajectory towards bankruptcy. It is kind of like an individual out-of-work engineer with a month's expenses left in the bank choosing to contribute to OSS instead of seeking out paid work. It is not that contributing to OSS is wrong, it is that the priorities in that situation are backwards.
RE: "Nobody is forcing Uber to employ people in California." That is entirely true, but I'm not sure what your point is. My comment is a post-mortem on what led to the layoffs. It is a priori that nobody has forced Uber to do anything that it did...
I have also been impressed by everything they are producing and I'm actually really wondering why do they need all of those new OSS projects. They need to scale but to an order of magnitude lower than most other webscales. None of their application is data heavy
I have said this before but they seem to have a strong "must be built here" culture. You typically see this in highly political environments where engineers are trying to create projects as a career highlight and as a justification for promotion.
While not a "tiny amount of data" Uber's problem seems like one of those embarrassingly parallel ones where partitioning by location is trivial, and accuracy of all the data isn't as important as knowing everyone's location right now. I'd guess any relatively popular MMO deals with similar things under much tighter latency constraints.
Data heavy to me means terabytes of data with potentially multiple dimensions, like Google or Facebook.
Not to say that Uber's problem isn't challenging, but I don't expect that the amount of data is necessarily the problem.
Can't speak for OP, but I'd imagine most of the data in the system is metadata - i.e. very tiny. Sure they're moving a lot of packets, but an entire ride's data could probably fit in 100KB. If they have a million drivers active, what data do they actually need on them? Profile, GPS location, type? Few KB. Keeping the log of all rides probably takes up the most, but still, relatively small. In any case they essentially deal with small, highly compressible metadata.
Think of that vs. a company like Instragram where people are uploading probably terabytes of media content every day, and they have to maintain/host all that content to be served on-demand basically forever. This is probably a low-key reason for pushing "stories" - they get a reprieve by only having to store that for 24 hours. In any case, you're looking at orders of magnitude larger data usage in all aspects.
Or YouTube, with 1000s of hours of video uploaded per minute.
FWIW an Instagram pic, 1080x1080 is around 100kb.
Uber has to do a lot more processing on it's data. I'm sure there are real challenges and the OSS projects from Uber I've seen/remembered on HN seem to be the type one builds because existing tools don't solve the problem well enough for their cases.
In the grand scheme of things it just isn't. 14 million rides a day, giving them a generous 1MB of data per ride, is "only" 14TB, 420TB/month. The data relevant to a ride for the clients like GPS location and ETA can fit into a few bytes...
A single video doorbell can use 200GB / month. With only 10,000 users that is 2 Petabytes of data traffic per month. Not to mention recordings that have to be stored and hosted for streaming later on.
Maybe, but the problem is that in a restructure like this the high performers often leave in protest to the culture problems that a restructure creates and austerity measures.
Often though they don't cull low performers, they give each department a budget or a head count they have to hit. A department made up of high performers will have to cull a high performer to hit budget, a department which is overloaded will become more overloaded and people will quit in response.
In a company the size of Uber a restructure is often a pretty blunt instrument.
Airbnb seems to do similar things, but has a better business model to support it. I kind of get it from a recruiting standpoint and they probably did need to build some customized software given the scale they have. My guess is they spent far more money trying to conquer rideshare in multiple countries, self driving, and side businesses. At the same time, they did look like they were also developing some pretty low level software that was probably not necessary.
Can someone explain to me what are the technical challenges at Airbnb? They need to handle less requests than the top airlines or hotel booking websites.
Airbnb is a business innovation with a shiny website frontend. But I really don't get all the hype around Airbnb engineering.
It doesn't really cost anything to open source something though. These are all projects which are developed for a reason: the commercial version might be prohibitively expensive at Uber scale, or not technically capable of operating at Uber scale, or just plain doesn't exist yet. At that point you can engage with the tech community and offer it as OSS (not to mention make your engineers happy), or you can keep it to yourself and eventually lose that opportunity to somebody else.
Depending on context, sure this could be true. Like if you're comparing the cost of releasing some small OSS module of Uber's to Uber's annual revenue, sure, it's going to be a negligible cost. But if you compare against the cost of developing the module in the first place, it can easily be an equal expense. For example I spent several months on a BLE library for Android (https://github.com/iDevicesInc/SweetBlue) and asked my company to open source it. It took several more months to get the library to a point that was suitable for a proper OSS release. So cleaning up code, making sure no sensitive info, swear words and such, documentation, lawyery stuff, icons, PR copy, blog post, basic website, wiki, and much more nitty gritty I'm glossing over.
I mean a company can just throw code over the wall into GitHub and call it OSS, but I associate a basic level of polish with a proper OSS release that does indeed take a good amount of effort. And that's just initial effort! If it becomes at all popular then you have further ongoing overhead.
I'd say a general rule is that open-sourcing something is at least 50% of overall cost of the project.
> So cleaning up code, making sure no sensitive info, swear words and such, documentation, lawyery stuff, icons, PR copy, blog post, basic website, wiki, and much more nitty gritty I'm glossing over.
I'm the manager of one of Uber's OSS projects, and all that the things you listed here ring true. I just know that in our case at least, OSS prep absolutely pales in comparison to the feature/operational work put in by the team.
To be clear, when I added "really" to that first sentence it was meant to communicate that there is some cost, but in the sense that it's negligible to Uber's losses, as you point out. I was responding to OP's "dubious use of resources" comment. But I can see that wasn't clear.
Yeah absolutely! It's a successful project and pretty integral to Uber, I love what I do and have a lot of faith in my manager/director. I don't anticipate any reason for our situation to change.
> If it becomes at all popular then you have further ongoing overhead.
THIS is the one that comes into play. All that stuff you listed before is a slog to go through when you go to open-source, but unless you're parking the thing as a proof-of-concept/end-of-life, you're now signed up for maintaining the repo. That means triaging issues, pull requests, helping out when contributors don't understand why their build is breaking, etc.
And there's the PM aspect of it: you don't just want to develop a bunch of features without talking to your community, so communicating (in a public friendly way) what you're planning to work on, when folks might reasonably expect that, how they might be able to help out, which of their contributed features you might be able to take depending on where you're at in your lifecycle, and RESPONDING TO COMMENTS all takes way more time than just "building [closed-source] product" in a team of 5-20.
And of course, one of the hardest of all: telling people "no, we can't take that change" when they've spent hours and hours doing work for your project for free. In that regard, we're still very much iterating on a transparent design process that allows for consensus BEFORE too much work has been done (though as we all know, building prototypes is often one of the best ways to find out if a design works right or not).
If you're doing it all right, everyone involved in the project should be doing some amount of all of this every single day. There's no compartmentalizing an engineer on an OSS project as "someone who just writes feature code" vs. "someone who does the repo stuff".
So going back to OP's point: no, it doesn't literally "cost anything" (or very much) to do the basic act of open-sourcing, doing it the "right way" at scale where you're truly engaging and working with the bazaar is very expensive.
Full disclosure: I'm a PM at Microsoft working on PowerShell and was heavily involved in it being open-sourced and ported to macOS/Linux.
Tangent: Could you explain why I might want PowerShell on MacOS or Linux, if I use those as my primary OS? (I usually only open my windows VM for checking that my websites work in IE 11).
Linux is actually half of our usage on PS Core[1], so it's a great question. A lot of folks use PowerShell inside of CI/CD pipelines, especially for cross-platform app development of .NET Core applications (having a single build/test/deploy script is often cited as vastly preferable to trying to maintain a split of .ps1/.cmd/.bat and .sh/.py/.rb).
But also, lots of folks prefer an object-oriented pipeline. Many of those folks (our primary use case for 10+ years has been IT management) are used to PowerShell on Windows and starting to learn or be exposed to other environments.
We've also got lots zsh-style optimizations in PSReadline. In some cases, we've got some catching up to do, but there's also lots of unique interactive optimizations hiding around[2].
It's also great for interactively exploring REST APIs and building scripts via that experimentation. Try running
And then look at all the properties you can explore:
$a | Get-Member [or gm]
$a.<tab><tab><tab>
Oh, and of course, one of the big reasons is "so you don't have to open a Windows VM to remote into your Windows Server boxes and manage them from a Macbook".
This is obviously not an exhaustive list, but it'd take a lot more time to write about every benefit and scenario here. In any case, it turns out that our user base is pretty spread out among different scenarios, but between our repo and usage numbers, we've been really happy with how excited that such a diverse group of folks really love PowerShell.
And feel free to reach out to me on Twitter @joeyaiello if you ever want to talk more about your experience (or just hop into our GitHub repo). :)
This was far more detailed than I expected. You seem very passionate for PowerShell. The rest method exploration looks very cool, I knew I might learn something cool by asking. Thanks!
100% agreed, I started doing this for a small project my company has. We don't really use it anymore, but it would be helpful to many hobby projects however we are now sitting here saying 3 weeks work to just give this code away? ick.
That's not true. It costs quite a bit to open source a product if you're a commercial entity.. It needs to be reviewed (by legal, security, engineering, etc) and approved..
You're not just flipping the public/private flag on the repo.
Also, the doc, blog posts, feedback from the community, evangelization at conferences, thinking out the API design so it answers enough cases, not just yours, all take engineering time, that's not free.
We open sourced my team's project a few years ago ( https://nomulus.foo ) and it was a substantial amount of work. There's everything you're saying plus a fair amount of engineering to get the darn thing working externally; we were built/hosted within the Google monorepo which is obviously not externalizable. And you end up spending lots of time writing documentation that you hadn't ever gotten around to when it was just a project being worked on by a handful of engineers all sharing adjacent desks.
Not disagreeing but elaborating: The costs are higher when it's an already existing product of which parts the company doesn't fully own enough rights of for publishing. Even higher when it's not known which parts are fully owned by the company and which parts are of foreign origin. The costs are lower when it's meant to be open sourced from the start and it's been a project constraint since before the first line was written.
Of course. But compare that cost to (say) six full time engineers pumping out code for a couple of years. It's not the dominant cost by any means. Not to mention you're paying those other folks a salary regardless.
If it helps you attract better talent, well - there's a financial incentive there through increased efficiency which I'm sure on its own is more than equal to the review cost.
Why would you give your open source code a tighter security and engineering review than your in-house code? Are you hoping for security through obscurity? And quality through obscurity?
> It doesn't really cost anything to open source something though.
Yes, it costs next to nothing to just open source a project if you mean literally just putting the source on some hosting site.
However, open sourcing something properly, where you respond to issues, document things properly, and provide build/test infrastructure to external developers is much more work. Not only that but you have to be much more careful when creating APIs and be much more vigilant about keeping backwards compatibility.
There was the fixed cost of developing it, and then the potential lost revenue of not selling it, similar to an opportunity cost.
If the presumption is that the software would be useful ("developed for a reason") economics suggests there is some price people would be willing to pay for it, and you forfeit that when you make it OSS. That absolutely costs something.
Sure you may not want to be in the business of commercial software (support, maintenance, ultimately just responsibility) which is a completely sane thing to avoid. However when you are bleeding money at the rate of a small country's GDP per year, avoiding opportunities to generate profit based on intangibles like community engagement can come off as ill-advised. In fact, if your company is declared bloated, it stands to reason that you should have the capacity to take on the additional overhead of selling the software. It is not that contributing to OSS is wrong, or that your points are wrong, just that there is a time and situation for this kind of strategy.
Contrast with Amazon, whose entire development of AWS was for the reasons you point out. Instead of open-sourcing it, to the extent that would be possible, they made it into a product and almost in a single move turned consistent overall loss into a massively profitable company.
So this is not at all to argue against the merits of having healthy OSS contribution at a company, but more to say that a company can't contribute to OSS if they are bankrupt - so avoiding the latter should be prioritized over the former.
In contrast to companies like Google, Apple, Microsoft, Amazon etc. that have mountains of their own money to burn (rather than investors') on research and OSS side-projects, it always seemed to me that Uber was trying to play the same game, but far too early. Paying lavish SF engineer salaries to generate cool, but not revenue generating, software is probably excellent for morale, culture and recruiting, but a dubious use of resources when you are losing money seemingly faster than it would be logistically possible to literally burn it.
Saying they're ~ "culling the low performers" can be entirely true, but it is also a Silicon Valley, meritocracy-culture-friendly way of saying "we're losing far too much money to pay bloated growth-stage poaching-game salaries to engineers, so if you're not working on something that generates revenue, glhf"