[013a]

There is a line you can draw in the sand here. I usually define it in terms of the Product; I don't believe companies should feel compelled, or even desire to, open source code which directly relates to the product they're trying to sell. The number of companies which actually do this are few and far between (Red Hat, Gitlab, others of course).

However, companies should desire to open source code which supports their product. Libraries they've written internally to do important things. Services. Infrastructure tooling. These are all great things to open source. There are many reasons why this is a great idea, beyond just recruiting and marketing.

1. Every company has shit code. Most of this is centered around your business domain (aka product) because that's what changes so often. Its alright to find a balance between "we're hiding skeletons in the closet" and "don't make a snap judgement based on a few Github repos, we have mentorship and you'll learn a lot about the context and intentions a lot of this stuff arose from."

2. It forces your developers to think beyond just their team. Now, suddenly, anyone can see this. Woah. I mean, its pretty likely only a couple dozen people will, but I guarantee you'll get really high quality READMEs, you'll get documentation, clean APIs... all of this benefits your internal team tremendously. Why doesn't this happen as often "by default" with strictly internal projects? Developers know the internal requirements, and they're usually not a strict as their perceived public requirements many open source projects live by. Crazy. True.

3. It forces your developers to think beyond just your product. This is HUGE. I cannot stress how important this is. "Evolved" companies develop everything with the little voice in the back of their head that it could just be thrown away tomorrow. Because, whether you like it or not, pivots happen. Maybe small, maybe big. If all of your code is intricately intertwined with your latest Uber for Canaries idea, you'll find reusing it during one of these pivots to be very difficult. But if its open source, there's this invisible force telling you that it can't be like that. It forces you to find the right APIs to work with both your product and Generic Use Cases. This takes longer. You should find a balance. But its worth it.

[acjohnson55]

I challenge the notion that product is so precious that there's a benefit to it remaining closed source. If there is a line, I'd draw it at business process, not product.

I'm a former Artsyer. There, a good bit of core product code t is actually open source, including the entire website and iOS app. As it turns out, the real value in most businesses is the data, business relationships, the domain knowledge, and the processes. People can't use your code to steal your business, even if they want to.

It does, indeed, have some impact on code quality, although I wouldn't say there was major difference. Much of the closed source code was pretty critical in its need for correctness.

Another benefit is that as you blog or do conference talks, you can point to real life code, rather than contriving examples. So there's somewhat of a virtuous cycle of positive exposure.

I can also say that the CTO is genuinely enthusiastic about his engineers building their personal brands. Sure, they might eventually leave (like me), but on the whole, it gives people growth opportunities outside the company while working there, and definitely helps with recruiting.

[pjmlp]

> I challenge the notion that product is so precious that there's a benefit to it remaining closed source. If there is a line, I'd draw it at business process, not product.

The overwhelming commercial success of FOSS desktop software.

[AsyncAwait]

Huh? Most FOSS desktop software is not commercial to begin with, however there are companies like JetBrains that do sell quite successfully to Linux users, even as their core product is FLOSS.

[pjmlp]

Exactly, because everyone failed to monetize it.

JetBrains sells developer tools, a very niche market, specially when a large majority of FOSS is allergic to paying for tooling.

In fact I would bet a large percentage of those Linux users are using Android Studio or Community variants.

It would be very interesting to know how many of those users has JetBrains actually managed to monetize on.

[AsyncAwait]

> It would be very interesting to know how many of those users has JetBrains actually managed to monetize on.

> developer tools, a very niche market

Overall yes, but on GNU/Linux, most users are still some kind of a developer.

I don't have numbers, but JetBrains did say that most users of their products use the paid version and that their Linux business is a healthy one. I am on Linux and subscribe to all their products and have colleagues and friends that do too, so we do exist.

I also paid for Githost.io when I was using GitLab.

[ghaff]

In all fairness, developers have always mostly been allergic to paying for things. Even way back, when a lot of developer tools were proprietary and often had pretty significant price tags associated with them, the developer tools business was always a pretty tough one. Like open source software, the model generally worked best when the developer tools were effectively in support of some other part of the business. (Microsoft is a great example.)

[fipple]

Not every company is Artsy. Artsy is an Internet company, not a place where new frontiers are being conquered. It makes sense to build Artsy in the public square, not so much Waymo.

[dblock]

Artsy CTO here. Interestingly for the first 2 years we were conquering the frontier of nearest neighbor search applied to art, using some pretty new algos. Then ElasticSearch just built something 10x better and we tossed our entire codebase. I wish we just did it in the open, the advantage was quickly lost to a stronger open-source effort.

[fipple]

I mean, exactly? When you had some novel tech, you kept it to yourself. Now that you have market power, you develop out in the open. Perfect game plan.

[acjohnson55]

Or don't do it. Whatever works for you. I don't know if it would be as appropriate at my current company, but I certainly see it as an option, having experienced the benefits.

[freddie_mercury]

> I guarantee you'll get really high quality READMEs, you'll get documentation, clean APIs...

I think this is hyperbole. Go look at, say, Atlassian's open source code: https://bitbucket.org/atlassian/atlassian-maven-enforcer-rul...

Or https://bitbucket.org/atlassian/confluence-react-components

Or https://bitbucket.org/atlassian/confluence-threaddump-plugin

The thing about "guarantees" is they only take a single counter example to disprove.

[013a]

Oh absolutely it was hyperbole. I should have said "higher quality"; I'm scared to think about how well-documented and written Atlassians non-open-source stuff is if that's the quality of their open source stuff. I'd bet money that a good bit of it is worse, much worse.

[watwut]

2. 3. Makes me think that you never spent time browsing around smaller random open source projects documentation or code. There are companies and individuals who are good at it and situation is improving, but standard is often pretty low. Being open source does not force you to generate general solution either.