4 ms·
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,
by 013a 8y ago
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.
- deleted 8y ago[deleted]
- acjohnson55 8y agoI 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.
- fipple 8y agoNot 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 8y agoArtsy 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 8y agoI 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.
- watwut 8y ago2. 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.
- freddie_mercury 8y ago> 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-rules https://bitbucket.org/atlassian/atlassian-maven-enforcer-rul... Or https://bitbucket.org/atlassian/confluence-react-components https://bitbucket.org/atlassian/confluence-react-components Or https://bitbucket.org/atlassian/confluence-threaddump-plugin https://bitbucket.org/atlassian/confluence-threaddump-plugin The thing about "guarantees" is they only take a single counter example to disprove.
- 013a 8y agoOh 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.