Hacker News Reader

Comment by sudhirj | Hacker News Reader

It’s really difficult to have your engineering quality or culture NOT reflected in your open source projects. What are you going to do, keep the regular coders locked in the basement working on CRUD apps and a penthouse full of cool evangelist programmers writing OSS for no good reason?

A company’s OSS is an excellent reflection of the people, decision making processes and culture that permeates it. Look at React, Go etc. They all heavily embed the founding company’s DNA, from the design of the tool, branding, blog posts, contributor engagement, build system, everything.

View on HN

I can think of many open source projects that are very tightly controlled by a small number of people. You're describing a situation that is now the default: You put good programmers in a room with a good engineering manager and good engineering practices and whatever else you think makes the magic happen (time, money, tools, etc), and out the other side comes a well-engineered open source project. Nothing I said disputes that chain of events. But if you step back from the individual trees to take in the whole forest, this article is written in a way that suggests the reverse: How to make an open source project look like you have all this engineering sugar hidden on the inside of your company.

I know a company where they have this exact same setup. Ivory tower "elite" team + countless wtf teams writing crappy code.

I'd love to know who they are!

Why wouldn't they do this? It's good marketing, you can tally it up as a recruiting expense, same way/reason companies sponsor conferences and send people to speak. These days I see the term "developer evangelist" bandied around a lot -- it seems like they basically get paid to hang out in the dev community, make cool things with the product (tm), and then talk about it at conferences. These days I also see more and more ~1 hour informercials for product X at conference Y.

One, two or ten projects cannot possibly reflect people and decision making processes of an entire culture -- The best it can tell you is about that team inside the organization. You could only tell the culture of the company in aggregate, and companies where the F/OSS output is anywhere near the total of what they produce is pretty low.

The marketing is working on you. Go is a small part of Google, but you highlighted that and not their Java or C++ or ads. 90% of people are not working on Go and flying cars; they are maintaining legacy search/ads systems with duct tape or launching a dozen DOA messaging apps a year.

> It’s really difficult to have your engineering quality or culture NOT reflected in your open source projects.

Would it be completely unthinkable that a company runs an open source showcase team like Oracle runs their America's Cup boat, as an independent entity paid to project the brands name into the world? That would be far from the idea of business open source, but it might not be the worst way of funding the kind of free software that is not directly connected to a specific business case. Many of us don't exactly remember the name Transmeta for their CPUs, for example.

> What are you going to do, keep the regular coders locked in the basement working on CRUD apps and a penthouse full of cool evangelist programmers writing OSS for no good reason?

You kinda sorta described SensioLabs: the good team is working on Symfony proper. While the other people are on the web agency side of things and quality is usually not the same.

Square is also like this on the Android side of things. The Square Cash team is the penthouse of cool evangelist programmers and the rest of the company is locked in the basement.

It’s really difficult to have your engineering quality or culture NOT reflected in your open source projects.

I can't entirely agree with that. Aside from the possibility of deliberate deception, as discussed by others here, there is always a danger with operating in the open that potentially interested people are only going to look at the latest code, without knowing the history and thought behind it. Many times in my career, I've seen "bad" things done for very carefully considered reasons by diligent and smart people, perhaps to work around identified compiler/OS/browser bugs, or to allow for sensible assumptions that unfortunately turn out not to be correct on some particular platform. The last thing an organisation like that needs is oh-so-smart developers missing the significance of a small comment at the head of the relevant code and judging based on the mustn't-ever-do-this bad practice that was, in fact, based on an entirely rational engineering decision.

Reply on news.ycombinator.com