On the contrary, I’ve found that companies who are actually doing hardcore software engineering, where the code is the main value driver for the business, rarely open source their best stuff, but they’re great places for engineers. Google doesn’t open source its self driving car code. Facebook’s value driver is the network, not the code, so it can open source anything. Dropbox’s client is amazing and is not only closed source but heavily obfuscated.
When a small company open sources everything, their main value driver is in sales or marketing or partnerships or something. Not a bad thing, but not a really engineering centric place.
Think the MBA speak for this is “commoditising you competition”. It’s when you use open source or zero pricing to either offensively or defensively to nullify an advantage your competitor has. Google attacks Apple by offering an open source OS (Android). Now everyone can make a phone.
They defend against Facebook controlling the internet by offering an open source browser (Chrome/ium).
Microsoft defends against irrelevance in the Linux age by open sourcing .Net Core. So now you’re just writing code for .Net, not Linux.
FB open sources dev tools to both attack and defend the talent pool.
Google open sources Flutter to counter React, decides it can show FB how it’s done.
Google also puts out K8S because AWS ate their cloud lunch and they need to show they also get it. Now you’re just running on K8S, not AWS.
AWS just open sourced a JDK. Now we can all give Oracle the finger.
Apple sits in their spaceship, not giving a fuck. Chris Lattner tried to open source for the sake of OSS, with LLVM and Swift, but he left.
> Chris Lattner tried to open source for the sake of OSS, with LLVM and Swift, but he left.
Maybe there's some history here that I'm missing: but it looks like LLVM and Swift are open source. Did Chris have any trouble open-sourcing them? Was the reason for his departure related to that?
He succeeded at open sourcing those two projects. Not sure why he left, but other than WebKit, which was probably a defense against Microsoft and IE, don’t think anything else can come out of Apple.
WebKit started as a fork from khtml (from kde). Apple didn't have a choice about open sourcing Webkit because they started with GPL2 code. They would have kept it closed source if they could, but that would have taken a few years of development, while they could start with khtml and get a great browser in just a few months.
I expect in a few years (5-10) Apple will do an audit, discover that only a small amount of code isn't written by Apple, and replace that with inhouse code and then relicense to something propitiatory. Time will tell.
I think it make sense from a cost/benefit analysis. Swift was created to make it easier for developers to write iPhone apps. Open sourcing the code provides developers with example code (given it was a brand new language), and more eyeballs to potentially look through the code to improve it whereas google open sourcing search should just allow bing to catch-up.
Amazon "open sourced" OpenJDK, which has been open source since the day 0 of Oracle purchasing Sun? Oracle just committed to maintaining backports for OpenJDK 8, and that part of Oracle's business it might be commoditizing: paid support for legacy versions, not the code.
Facebook: yes, the network is important, but still: Ads service? Closed source. Data science stuff they use for harvesting relevant data from users? Closed source. Dropbox: agreed.
I agree, companies like Facebook open source things that are being helpful for them, and in most cases, due to their huge scale, they didn't find anything similar and had to do themselves. For a company to open source its core product it only make sense when you expect to have revenue from enterprise SLAs and custom services, as it is the case of companies like MongoDB and Redhat.
Seriously, the Dropbox client? I mean, I never used it but I can hardly imagine anything that makes it so special. I use Nextcloud and from what I can tell, there is nothing that sets the Dropbox client apart from the Nextcloud sync client (which is 100% open source).
Sure if your business model depends on selling the software then open sourcing it might be a bad idea. But if you are selling software to other companies they most likely are not interested in the software but in the service you provide, so they will require Service Level Agreements which should be the base of your business model.
However, with consumer software that doesn't work very well, since nobody gives a about service levels (even if it would solve many of their problems) ;-)
For one, delta-sync was built into the Dropbox client from the very beginning, and I'm getting the impression from this thread that Nextcloud still doesn't have it till this day: https://github.com/nextcloud/server/issues/417
This is a major contributor to sync UX, and by no means trivial to implement.
Another example is their file stubs implementation (Project Infinite) that works across platforms, which is also no small engineering feat, that afaik no other sync software has been able to replicate yet (OneDrive has this on Windows, but no other platforms).
The Dropbox client makes just about every other sync client look like toy projects in terms of technical sophistication, reliability, and general UX. There's a reason why they're so successful. And I say this as someone who doesn't even use Dropbox on a day to day basis (I use Syncthing as my daily driver).
This really seems like a matter of the OP not knowing what they're missing and then flaunting that ignorance.
> This really seems like a matter of the OP not knowing what they're missing and then flaunting that ignorance.
In fact, I added that I never used Dropbox to give context on my perspective. I am not sure that qualifies as 'flaunting that ignorance'.
Regarding the delta-sync feature: That is, in fact, a feature neither Nextcloud nor Owncloud posses at the moment. On the other hand, it would not be that beneficial to my use-cases since I rarely have large files within my synced folders and most of the time I have a GBit connection to my Nextcloud. So I guess I am missing not that much (at least with my current usage pattern).
Granted, for some use-cases, it is essential and bringing such a feature to all major platforms is not a trivial task. Yet I still wonder if protecting the implementation is necessary since the comments in the Nextcloud issue suggest that the primary problem the availability of the developer is (who might have an easier job if he could take a look at the Dropbox code, but ultimately he would have to write an implementation that integrates with his project).
And ultimately I wonder what makes people decide which service they want to use. For many people, it sure is the little friction you encounter during the setup of Dropbox. For me, it is not that much about the features of the client software but about the features of the larger system. Being able to host my own server is essential to me. Having an open source implementation is a nice add-on, which I value and made use of already. AFAIK those features are not available with Dropbox I seriously doubt my previous comment qualifies as flaunting ignorance.
The only thing keeping me in Dropbox is the fact that I use several very important apps (one of which is an encrypted password vault) across very different OS-es -- think iOS, Android, Windows and macOS.
They offer transparent syncing so all your app instances work with the same data and sadly trying to get the developers of the apps to include self-hosted solutions (with added configuration step: the IP/port) is not happening and isn't likely to happen.
And both Apple and Google aren't open to the idea of allowing cross-ecosystem app synchronization (think game you play for an hour on your iPad but then want to play it on your specialized gaming Android device when you are out and about later; in the case of games this problem is solved by using Google or Facebook as login providers on all your devices). And until that's true then Dropbox and other popular cloud storage providers (mainly Google Drive and OneDrive) will always have a place.
Dropbox Nautilus Extension is open source because it has to be - GNOME Files is licensed under GNU LGPL. The amount of code in that extension is minimal, the proprietary Dropbox client pretty much does all processing, the extension is only responsible for displaying icons in a file manager.
> Seriously, the Dropbox client? I mean, I never used it but I can hardly imagine anything that makes it so special. I use Nextcloud and from what I can tell, there is nothing that sets the Dropbox client apart from the Nextcloud sync client (which is 100% open source).
Writing a simple file sync utility isn't difficult, hell you could just wrap rsync and you'd be half way there. Making that open source is easy and low risk, because you haven't really invented anything.
On the other hand, if you can throw 100 developers at the problem, you'll come up with something _far_ beyond the simple case. Sure it might only be 50% faster? But that 50% makes your product "magic" when compared with other tools. This is where you get things like Project Infinite (https://blogs.dropbox.com/tech/2016/05/going-deeper-with-pro...). I can imagine there are some very complex optimisations for the multitude of configurations that Dropbox runs on, that I can understand a company wanting to keep "secret" if it's so core to their business.
I think you'd be surprised at the depth to which these companies are solving problems.
> In order to innovate on the user’s experience of the file system, as we are with Project Infinite, we need to catch file operation events on Dropbox files before other applications try to act on those files. [therefore we need a kernel driver]
You can block the operation within fuse's userspace part while calling out to some helper gui program to ask for confirmation. Seems like an excuse rather than a reason to implement stuff in the kernel.
I think Google actually does open source a significant part of their reusable libraries. I'm thinking about stuff like Leveldb, Tensorflow and Angular off the top of my head, but I'm sure there is a lot more.
Some companies do seem to be ideologically opposed to open source (I'm looking at you Balmer-era Microsoft) but Google has always seemed to have had a certain commitment to it.
Once the output is built and uglified, you will not reverse engineer it back to the source that google started with. JS projects are not not much different from any other built project. Probably closest to .Net or Java IL once uglified. Still higher than WebASM, but still not he same as source.
It has to be open source in the sense of sharing the source code, but companies take the extra step of making it open source in the sense you have a license to use it for your own website.
Anecdotally, I look at the public repos of any company advertising a job I'm interested in before I apply, so open source certainly attracts some class of developers.
The problem is the assumption that people who do that are "better" in some way. I've known some brilliant engineers who don't care at all for open source code; they wrote great code that no one besides the customer would ever see or use. That doesn't make them bad engineers.
> The problem is the assumption that people who do that are "better" in some way.
Well, your argument doesn't prove that the assumption is wrong.
In my experience, everybody starts with closed source code and before open sourcing anything the developers asks himself what kind of code he wants to show as his work which in itself triggers a desire for quality and makes them better(tm) developers. Therefore, I would assume too, that the mean open source developer is statistically a better developer than the mean closed source developer (everybody). But that doesn't mean that every open source developer is better than every closed source developer. It just means that when you are targeting open source developers you have a higher chance of finding a good developer.
So? Just because your code is not open source does not mean you're not allowed to use it.
They might not care about the company they are applying to opensourcing their code. Plus you have to try really hard nowadays to not use any open source code at all
If you go through your dev career thinking only people who write and use open source code are brilliant you'll miss out on the opportunity to learn from some of the industry's best developers. There are loads of people working on entirely closed source projects who are very, very good engineers.
>If you go through your dev career thinking only people who write and use open source code are brilliant
I didn't said that. I have just pointed that even close source developers are using open source when working daily on their closed source projects. So saying they don't care about something they use daily is ....wrong. Also I didn't said anything about their level of brilliance :)
Using open source in many enterprises is just a way to save costs, many times at expense of productivity as there are closed source options that are actually better, but not all companies are willing to shell out the cash.
Contributing back, or even announcing to the world that such packages are used is not even a thing.
I didn't said that. I have just pointed that even close source developers are using open source when working daily on their closed source projects.
When I said "entirely closed source projects" I meant that literally - some projects have no open source elements. They're written in closed source languages that you have to pay for, with closed source libraries and frameworks that you also have to pay for. They tend to be things like control systems in small industries, unusual embedded systems, and so on.
The software industry is big and hard to make general statements about. "All developers will use open source code" is not true.
Ah, but then you must raise managers’ wages too, because they obviously have to make more than your engineers. Okay, then I guess open sourcing your code is indeed the best option!
I was listening to a friend's music podcast tonight and they were talking about how industry will seize on any shred of creativity so that they can use it to sell cars, and this contributes to people getting defensive about the things they like becoming popular. There is a latent fear that just over the horizon, some marketing asshole is waiting to get their hands on something that is meaningful to you, in order to abuse that connection so they can buy themselves a boat.
This post feels like it's edging way too close to that. If you want to attract "talent" by putting repos on Github or Gitlab, that's great. But if you are hiding bad engineering practices and/or a shitty work environment and putting up a facade which is carefully crafted as a recruiting tool (and not truly a reflection of what it's like to work on a project inside your company), you are making a huge mistake that will backfire and it will come back to haunt you.
That's not to say that we don't know that open source is a tool companies use to get more for less (everybody knows that). But if you keep a carefully-controlled open source repository around to show potential hires when there is a bonfire in the engineering team's side of the open-office floorplan because your actual engineering practices are abysmal, you should know the "talent" you want to hire is no spring chicken, and they will know almost immediately that you have been duplicitous in your hiring, and word will spread. And then you'll have existential hiring problems.
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.
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.
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.
> I was listening to a friend's music podcast tonight and they were talking about how industry will seize on any shred of creativity so that they can use it to sell cars, and this contributes to people getting defensive about the things they like becoming popular. There is a latent fear that just over the horizon, some marketing asshole is waiting to get their hands on something that is meaningful to you, in order to abuse that connection so they can buy themselves a boat.
It's called I Hate Music. [0] I really enjoy it, and I think some folks around here would, too, but I'm really a poor barometer of what others might enjoy. My assessment is also maybe a bit clouded by my affection for the guy.
I don't know about you people, but I don't give a rats ass if the company I work for open source their code or not. I care what benefits i receive and mostly the salary and the possibility to work remotely.
Also it is a positive thing if what I do is fun and/or meaningful.
Open sourcing the code is important to me because its frustrating being a senior hired onto a team of all newbs. By senior I mean a person who can write code quickly. By newbs I mean people with high insecurity that just want to dick around with code style and framework tooling.
I would not define "senior" as "one who codes quickly." I also would not define a software developer's level as "newb." So there is that.
Junior, mid-level, senior, and then maybe principal. I would gauge them by a combination of time in the market, ability to write production grade code, the ability to make informed tradeoffs, ability to work independently and as a team player, and ability to work across teams and disciplines effectively. A very, very small part of that is "quick coding."
> I would gauge them by a combination of time in the market,
Absolutely not. Time on the market isn't an immediate indication of competence. It certainly isn't an indicator of potential. In my experience you are so much better making an objective hiring choice by throwing EVERYTHING related to programming and interviews away and simply providing a battery of personality tests. I went through this when I was interviewing with Bridgewater.
Performance is better determined by the briefness of product, the speed of execution, and minimal time of delivery. An educated person can make gross determinations of this by examination and testing of the code. Likewise, lesser souls can evaluate the product for code style, a super high dependency count, and favorite framework.
Ultimately it comes down looking for an ambitious endeavor versus looking for emotional comfort.
Time in the market is not good by itself, but can be a proxy for leveling. Someone could have 15 years of repeating 1-year experience and be a junior dev. Another could be out of school by 1 year and show tremendous potential and have shipped some great stuff and quickly fill a mid-level position. But time in the market is definitely a consideration. Not the most important, but, for sure, on the radar.
For a normal person, it will take time to develop expertise. Time for exposure to novel problems and time leveraged for (the opportunity of) growth.
After you get into an organization, you can level up quickly depending, to a degree, on the speed of execution. I also agree with you that it is uninteresting to gauge leveling based on code style, dependency count, and/or a favorite framework. However, discussions around those can lead to a better understanding of someones professional maturity.
It makes an engineer look good to have solid commits to an open source project on their github profile. The people who actually make the bulk of these commits put in tons of (at times thankless) free labor.
Create a grey market for open source software contributors to sell their diffs (that they've already written and actually entail useful contributions to their project) to some rich lazy wannabe engineers to submit to the repo, and get credit for. Bulk discounts for corporations!
It would get OSS devs more money, which is good, but is lying which is bad.
I thought this didn't apply to computer programs, but I looked it up and you're right... In France, authors' moral rights are quite strong.
In the UK, the moral right of attribution exist, but there's a specific exception for computer programs, so that programmers don't have a right to be identified as the author, or as far as I can tell any other moral rights.
You can already get credit in open source projects without doing anything. Be on the mailing lists, present at conferences, claim ideas that weren't yours, treat actual code as a "solved problem".
You do not want to hire engineers with "personal brands", in the same way that hiring celebrities for anything other than showbiz, normally causes problems.
At a previous large company with massive opensource scheme, "personal brand" engineers blocked many attempts to increase security, specifically filtering git commits for keys, PII and other expensive mistakes.
the "personal brand engineer's" solution? everyone singing a pledge to stop committing PII & keys to git.
The argument was: "well, committing 60,000 PII records to github was done by an idiot[1], not one of us, there is no way it could happen to _us_. We can't work on private repos, because that means we can't collaborate"
[1]They are not an idiot, they weren't in the trendy department.
If you want good engineers, don't let your tech department be run by penises. Let me put that into a list:
o hard limit on work hours(rota for Out of Hours support, if needed) no more than a 40 hours week, ever (averaged over a month)
o Solicit feedback from everyone, more importantly, action it.
o Pay well
o only use data for decisions (HR or otherwise)
o keep no secrets
o Balance empowerment with maintainability
o aggressively kill legacy
o correct or eject bullies
o allow differences (live and let live)
o don't all look and think the same
o Train the next generation
o don't allow silos (rotate at least twice a year, bonus points for feature teams)
For me the problem is that to create a brand around yourself you need a pretty damn big ego, and ego is just bad in a team setting.
The best engineers I know have zero ego.
This is a really important point. I work with someone who has quite a bit of an ego. Definitely cares far too much about his personal brand, which has been built up over the years through open source projects. Any time you work on a project with this person you basically need to use all of his open source libraries if any of them are at all relevant for the project, regardless of if they are the best option for the task or not ... sometimes they are, sometimes they aren't.
By far, the best developers I've ever worked with are quite humble.
This is a great point. The best engineers are the ones working with their teams to get shit done. If someone on the team is more worried about their OSS contribution than getting work done, it can be a red flag that they are more concerned about themselves than the team.
> engineers blocked many attempts to increase security, specifically filtering git commits for keys, PII and other expensive mistakes.
I am struggling really hard to find a good reason why anyone would be against this change. Committing keys is a very easy mistake to make, especially for a junior dev. Github is littered with secret keys committed by college students trying to figure out web development for the first time.
I did the same thing when I was fresh out of college and new to both git and using web apis. Luckily it was just a Spotify key and not one for my Dropbox or email.
So here's some of the reason's they give for why Engineers want to work on Open Source:
> They want to work in the open because it creates some visibility to them
> The best companies align business needs with the desires of individual contributors (Engineers) to create their personal brand
> Smart developers like to hang out with smart code. When you open source useful code, you attract talent.
Some of these may play some factor when choosing a company but honestly I think its very small and/or confounding with the underlying factors. More likely IMHO is that companies with an open and communicative culture, where people and processes are transparent, and where work is iterative and agile, tend to open source more code b/c it fits perfectly in that culture. I think Engineers in turn are probably more attracted to that culture as opposed to classically hierarchical, bureaucratic, structured monolithic organizations (which also tend to open source less code b/c it doesn't fit their culture).
I don't really care about any of those things. The reason I want to create open source as part of my job is it means I can take it with me when I leave. What's the point in building up deep expertise in something that you just throw away and never see again if you shift jobs? When I'm working on open source I see myself accumulating a lifetime resource / skill compared to something that is relatively ephemeral.
This is the classic paradox of employing developers, though. Of course those developers want to establish a good professional reputation, because it makes it easier for them to find new gigs later on. However, encouraging "resume driven development" practices and high staff turnover is hardly in the interests of the employers. Obviously it's good to have an engaging work environment that is interesting for your team where you can, but ultimately it's a business and you're all there to get a job done, not to pad your resume so you can hop to the next one in a few months for a 10% pay bump. In a few strange bubbles like SV, where the crazy money available is barely correlated with the value or efficiency of the businesses spending it, maybe you can overlook this for a while, but I'm not sure it's a healthy, sustainable culture in the industry.
Is there really a reason/data to think that open source companies are better places
(better culture) to work at compared to another company of the same size? Or
is it just assumption?
As a note, "open source companies" != "tend to open source more code".
There are relatively few open source companies. Most companies which distribute open source do so for part of the company which is not directly connected to revenue generation.
I've seen a lot of teams write code internally with the intent of open-sourcing everything once they're done. If you're doing this, you're missing out on a huge opportunity. Just as important as open-sourcing the code, is open-sourcing the collaboration process. Why not make your code 100% open-source from the beginning and let contributors participate in the design process? Let your contributors join in your heated debates & hear the rationale behind your design decisions.
At Origin, 100% of our code is open-source and everything we do is "public by default". We have a culture of radical inclusion and transparency. Everyone is welcome to participate in our open-source engineering process and our product discussions. Our engineers collaborate every day in our Discord (1), we track our progress on a public project board (2), discuss what we're working on each week in a public Google video Hangout (3), and publish our engineering meeting notes for the world to see. (4). As a result, it's really easy for outsiders to get up to speed on what we're building, what our current needs are, and get a feel for our company culture. While our core engineer team is only 9 people, we've had over 60 contributors to our codebase and we have new people showing up every week wanting to get involved. We've also been able to attract and hire amazingly talented people we would never have discovered if we were running a traditional hiring process.
Don't just open-source your code. Open-source your collaboration process too.
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.
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.
> 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.
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.
> 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.
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.)
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.
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.
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.
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.
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.
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.
Artsy CTO here. I am excited to see this article and, putting aside that it quotes me :)
A couple of things I wanted to highlight that are not in the article and should have been.
- Pay attention to how Microsoft has used open-source to turn things around in terms of developer credibility.
- Becoming open-source by default can still be an advantage as 99% of companies don't do it. It can still fix your hiring pipeline, but that advantage won't last as it's becoming more mainstream.
One obvious benefit of open sourcing the code, or at least important parts of your code, is to identify developers who are really interested in that part of your product. This goes both ways. As a developer, I have a list of open source software I use and have used. Some of the software I selected because I had a specific problem to solve at a time, but a a large part of that list is software I keep reusing across projects and which I am actually fond of. So, if I were to look for a new job, of course, those software packages would make their main maintainer very attractive to me as a potential employer. And for the employer, who is better to hire than an engineer who already took interest in the software before even being paid for it?
I have a question for some other HNers that is kinda related to this topic.
I've got a library built solely by myself that I'm interested in open sourcing.
I'm tossing up between putting it on my own Github account, where it probably blends in with the rest, or putting it on the OSS page for the company I work for which, honestly, is a bit of a wasteland (numerous unused forks mainly)
I guess I just wonder what looks nicer on a resume. I would assume having something on an OSS Github org looks better but is it really? I don't recall ever looking at eg; a Google or Netflix project and looking into the authors vs looking into an individuals Github project.
I dunno, just wondering if anyone has any thoughts. I understand legalities come into play too but for this is more of a hypothetical.
I would definitely put it under my own name, if I were you. Like another commentor mentioned: if you leave the company, you still control your own repo.
Also, whenever I interview programmers, I always browse their Github (or BitBucket or whatever). Not having a Github isn't such a bad thing, but if you have a cool (or popular) project of your own there, it can help you get noticed.
(Of course, you need to be careful that your employer isn't going to freak out about you posting code openly. I have a habit of starting side-projects in-between jobs, then only do updates on the weekends after I've started a new job.)
Another option, perhaps: put it on your own repo, but track it from the company's repo on the company's webpage. (If they'll let you do it, that is.) That gives you some free visibility.
I'm going to question my sibling commenters' assumptions here - reading between the lines of your comment it seems this may have been developed as part of a work project using your employer's time / equipment? In which case I'd look into the terms of your contract before releasing anything.
Of course if this is a side project on your own time then personal GitHub all the way - your employer doesn't deserve any of the credit at all. I always have a good look at job applicants' GitHub accounts and while contributing to open source isn't a requirement, it certainly helps.
Put it under your account, in case you stop working for the company. If that library gains traction, you can move it to its own ORG, which makes it easier to manage other contributors.
Finally look out if that project could be moved to other big OSS orgs at some point. I created some packages for the Atom editor, and when it became clear I couldn't maintain them, I found another ORGs that were able to pick it up.
Maybe do the other thing - if it's a really useful project with the potential of a community around it, name it well and make an organisation just for your work.
A side effect of open sourcing is that programmers might be a bit reserved to do stupid things in the code. This might be both advantage or impediment I guess.
Off the top of my head, a good software engineer is not just a coder. They develop solutions to problems that provide value. They do so under constraints of time and resources. Beyond that, you then can get a feeling of the level of the engineer depending on the following:
- code: maintainability, instrumentation, extensibility, readability, testability, performance, handles tradeoffs in complexity, and the time to create the code.
- projects: can work independently or in a team, can work with individuals across teams and disciplines, can influence project direction, can architect solutions and choose designs and supporting tooling based on tradeoffs, can deliver on a reasonable time scale.
- people: can mentor and be menteed, can collaborate well, can lead or follow, and can inspire best practices.
I'm sure there is much more, but that is off the top of my head shortly after waking up.
And here I sit, thinking that competent middle management that can actually evaluate people based on results delivered instead of attendance and therefore allows more flexible remote work instead of commuting 3 hours would help.
Increased pay also helps. Flexible remote work is just not enough - you are still tied to incredibly expensive housing. You need full remote - so you could live uncommutable distance away.
I don't think open sourcing code will necessarily attract better developers. Better is highly subjective. If anything it will attract more compatible developers.
This seems mostly like a Silicon Valley filter bubble talk.
All the great places I worked with valued:
- People's time. Any extra red tape was aggressively and actively hunted and killed on the spot.
- Self-sustainable business model. No venture capitalists, no investors of any kind. They walked before they ran.
- Not hiring more that they can pay for in a year.
- Less people doing more in exchange for hefty salaries and job security. As business needs grow, the company's leadership turns inwards and people seriously discuss how can they optimize people's time and efforts better without burning them out. I've seen 5 juniors replaced with 1 senior a number of times.
- Respect and appreciation. Be it a few days off after a lot of work, or 20-50% extra salary that month, or just a collective thank you from several people -- all of these go a VERY long way towards loyalty and sense of camaraderie that make people stick around for 10 years.
---
Open-sourcing your code serves a number of goals:
- Shows that you are open to be vulnerable and that you are ready to do better. However, sometimes it's just a PR stunt and no pull requests or comments are ever addressed.
- Serves to attract young and enthusiastic programmers which is often times not such a good thing -- the company might need people who they can guilt-trip into 17-hour coding sessions to get N projects off the ground in a short time frame. Sometimes they actually need the fresh perspective though. So 50/50 here.
- Shows that you care about your ecosystem even if you don't actually open-source your own product but a number of libraries that you managed to extract from your monolith over time.
...and a few others. But open-sourcing stuff in a corporate setting is mostly a PR move.
So really, this article is not at all valuable nor does it even give an interesting side perspective.
> Refactoring your code to be as simple as possible
> Following style conventions for names, whitespace, etc.
> Replacing private information with environment variables
> Commenting your code to contextualize snippets within your broader codebase.
While I do wish more software was released under a FOSS license, I also wish that these points were a given for any codebase regardless of license or source disclosure policy. I really don't think you can be agile no matter how many agile-trademarked tools and processes you pile on top of your project if you don't do this first.
When a small company open sources everything, their main value driver is in sales or marketing or partnerships or something. Not a bad thing, but not a really engineering centric place.