
Companies that contribute to open source can gain a competitive advantage - ingve
https://hbswk.hbs.edu/item/the-hidden-benefit-of-giving-back-to-open-source-software
======
ThrustVectoring
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.

Really good blog post that explains this in further detail:
[https://www.joelonsoftware.com/2002/06/12/strategy-
letter-v/](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.

------
duxup
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.

~~~
rectang
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.

~~~
ehnto
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.

------
rectang
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.

~~~
zapita
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?

Thank you!

~~~
rectang
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.

------
xfitm3
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.

~~~
ChrisFoster
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.

------
c-smile
The question that intrigues me quite a while.

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.

How do these models correlate with product areas?

~~~
rectang
"Open Source" is a _development methodology_.

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.)

~~~
c-smile
Thanks for the clarification but that's pretty much what I just said.

Not sure about this though:

> "Open Source" is a _development methodology_.

Development methodology is one of these as far I understand:
[https://www.synopsys.com/blogs/software-
security/top-4-softw...](https://www.synopsys.com/blogs/software-
security/top-4-software-development-methodologies/)

In any case my question/suspicion still stands: far not all types of software
projects are fit or benefit from being OpenSource.

~~~
mindcrime
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.

------
myspy
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.

Increases the quality of your own products too.

------
RickJWagner
Can't agree more.

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.

Get on board! Open Source is truly a great thing.

