There's a very real business reason to make certain goods cheaper, even at your own expense. "Commoditize your complements" is the short catchphrase for some of this.
The short explanation is that when something is cheap, demand for complimentary goods goes up. For example, when the software for managing cloud deployments gets lower (in a total cost of ownership sense, not just sticker price), then demand for cloud computing goes up. Google has both Kubernetes as an open-source project and Google Cloud Compute as a revenue-producing product.
There's another reason to do open-source, and that's to get your future hires pre-trained on some of your internal tools and frameworks. If Go or Angular were internal-only things, Google wouldn't be as able to hire engineers with experience in Go or Angular.
Is it possible that the folks who contribute are just inherently more passionate / have more experience (already participating outside of work) than those who don't contribute?
Not to say I think the article's premise is necessarily "wrong" just wondering if folks who contribute just are more likely to have some aspects that benefit their employer.
Significant contributors know the software they work on more intimately. Most obviously having an expert on staff like that makes for faster debugging when something goes wrong. Less obviously (but more importantly), having someone who truly understands the software well helps ensure optimal architectural decisions about how the software gets integrated.
It's a good indicator for an agency to contribute to their chosen platforms. It means they have been able to identify and fix an issue in a way that was sympathetic to the architecture. If you can see a plugin or module made for the target platform even better.
You don't want an agency that writes a bunch of code in their own way and bolts it into your framework, because when you change agency later the new agency will have to learn how to read their code plus the platform code.
Yeah the long term benefits especially when it comes to using features / software as intended / in a way that will be supported in the future have to be huge. If they can teach others.... benefits have to be big there too.
I think this has been true in my case, for years I wanted to make a significant contribution to an open source project but I did not have the skills to do so in a timely manor, I had to focus on billable work. Now ~ 8 years after I started programming I feel more confident that I can jump into a new library and fix or add what I need without the risk of spending more time modifying library feature than was required to add the business logic to my app. This seems like it would be a critical realization in the path of a dev from junior to senior.
Enlightened businesses know to hire key contributors to the open source libraries they depend on. :) I was glad to work for such a business for several years, and proud to offer them great value.
I would love to hear more about your experience, and I’m sure I’m not the only one. Were you employed to maintain your project full-time? Did you consider working for more than one of those conpanies, as an independent contractor? What about starting a services or product company around your project?
I was an employee, not a contractor. Over the 8 years I worked there, probably about half my time was spent on open source contributions: not just coding but also community management and such.
Before I got hired by this company, I did consulting for a handful of clients, but I personally prefer the stability of reporting to one boss. It was my personal "business plan" you could say to get hired. And it worked! :)
The project was moderately successful over its twelve-year lifespan but has now completed its arc. While a certain amount of marketing is necessary to get people's attention, for a long-term relationship like this, value is ultimately imperative.
I love open source and work with it every day. I used to contribute but I grew tired of interacting with difficult people. Some project owners are grumpy, or perhaps someone wants to bike shed every detail. I shouldn't let it get to me, but I did.
This is hard to get right. Personally I try not to be a grumpy maintainer but I'm frequently a picky one. Lately I've been an absent one.
I think maintainers can frequently come across as grumpy simply because their goals are different from contributors. They have to live in and fix the codebase for the long term, so have a proportionally higher stake in consistency while also having a much broader knowledge of the rest of the code. It's hard not to nitpick in this situation.
For the contributor, they're frequently trying to get some other work done and would rather not have endless back and forth over the precise detail. Furthermore their feature or bugfix is clearly a good idea because it solves their own problem. A problem that, unfortunately, the maintainer doesn't have.
Perhaps a partial solution is in treating project maintainership itself as an engineering problem. That is, having automated testing infrastructure, developer tooling for code consistency, etc. This kind of stuff has become dramatically easier to set up for small open source projects, but depending on the language it can still be a lot of effort.
I don't think we've reached an equilibrium yet about what we can expect from open source maintainers.
It's difficult because there's no contract spelling out what the responsibilities are, and the maintainers can have anywhere from "throw it over the wall" to comprehensive support.
This is a challenge for Open Source governance going forwards. We have certain expectations for a project which is governed by a commercial entity; we have certain expectations for a project at the Apache Software Foundation which is governed by its community; and so on. Perhaps other systems of governance will gel over time and both users and developers will develop more predictable and codified ideas about what kind of support to expect.
I suspect that there are types of projects / product areas that especially benefit from being OpenSource. What are these areas?
Yet my mental model considers the following development business models:
* OpenSource/Bazaar - everyone can do whatever they want, without much of supervision. Like famous NPM registry.
* OpenSource/Glassdoor - only selected "maintainers" can actually do the development, the rest, on the other side of the glass, can only look and suggest something (if they have loud enough voice). Like Linux development.
* ClosedSource - internally that is also using either Bazaar or Glassdoor model - it is just auditorium is smaller and more focused - limited by the organization itself and its clients. Like Windows and its all major customers, states and agencies.
It is compatible with various business models. One of the most popular is "open core", where a product is available under an open source license but a company makes add-ons available under proprietary licenses for a fee.
There are also various governance models for open source projects. A company can maintain ultimate control over the direction over a product (e.g. Docker, the Go programming language, ...). Or the project may be governed by its contributors and may have various rules for contributors being offered a governance stake. ("BDFL" or Benevolent Dictator For Life where 1 person has final say, a "PMC" or Project Management Committee where members join by invitation, etc.)
In my experience, when most people talk about "software development methodologies" they mean something like "the kinds of things captured by labels like Scrum, XP, Crystal, RUP, AUP, waterfall, etc." In that sense, I wouldn't say that "open source" has traditionally been thought of as a "development methodology", but by the same token, I can see how it would be fair to refer to it that way.
Maybe it would be better to say "open source is a development philosophy" or "open source is a development approach" or something, but I actually think it fits as a "development methodology" with the caveat that it's not just a development methodology. For a lot of people, (myself included) it's more of an ideology or even a way of life.
Anyway, there are companies that actively talk about running projects as "internal open source" and in that sense, I would argue that referring to "open source" as a "development methodology" is reasonable.
I agree. Digging deep into an open source library is a major pain in the ass, but helps to get better and being it to clean up the code and add a couple comments.
Open Source is beneficial for so many reasons. Just a few:
- Use of the software, of course
- Your programmers become better at their craft
- Access to cutting edge innovations
- You have the power to fix something, you aren't reliant on someone else
- You get some pride in your contributions. You helped build that.
The short explanation is that when something is cheap, demand for complimentary goods goes up. For example, when the software for managing cloud deployments gets lower (in a total cost of ownership sense, not just sticker price), then demand for cloud computing goes up. Google has both Kubernetes as an open-source project and Google Cloud Compute as a revenue-producing product.
Really good blog post that explains this in further detail: https://www.joelonsoftware.com/2002/06/12/strategy-letter-v/
There's another reason to do open-source, and that's to get your future hires pre-trained on some of your internal tools and frameworks. If Go or Angular were internal-only things, Google wouldn't be as able to hire engineers with experience in Go or Angular.