
While open source is free as in beer, it’s also free as in baby (2014) - dantiberian
https://danielcompton.net/2014/11/19/dependencies
======
seagreen
> software decays over time, a.k.a. entropy

This is similar advice to "always have your castle ready to withstand a
siege". Both are excellent pieces of advice -- for 2010s software/the medieval
ages respectively. But the advice is not timeless, once we get/got our crap
together it stops making sense.

Software decays because we don't track all its inputs. Once we do it will no
longer decay, when run in environment X it will give output Y, every time.
There's already movement on this front with
[http://nixos.org](http://nixos.org) and imitators -- I expect massive
improvements on that front in our lifetimes.

Of course, you still need an x86-64 computer or whatever. I doubt they'll stop
making them any time soon though=)

~~~
skybrian
You can track the environment all you want, but you still have to modify your
software when the environment changes.

If your software has a web page, browsers are not under your control. You
don't know what the next version of Firefox is going to do.

If your software runs on any cloud service, you don't know what they're going
to do.

Also, even if the software stayed the same, business requirements will change.
New security holes will be discovered. Customer expectations will change. Who
knows, maybe IPv6 will finally happen?

Freezing your software is not an option for most people. The Internet is not
done yet and it's not going to be done anytime soon.

~~~
chubot
It's possible that we will reach a point in computing history where we can run
all historical software, and that this state of affairs will continue
indefinitely. It just requires enough manpower put into "bootstrapping" of
hardware in software (emulation). A decentralized Internet file system might
help too.

In other words, the "digital dark age" [1] for code (in addition to documents)
doesn't need to last forever.

You might compare it to things like farming, metallurgy, or plumbing. Many
things in those areas were invented independently in different geographical
areas, and some were altogether forgotten and reinvented later. But now we've
reached a point in civilization where we're not going to forget them, because
we have libraries, the Internet, and so forth.

Likewise, at some point we should stop forgetting how to run old software as
well. Old software can be made runnable now through conscious effort, but the
"default" is still for it to rot and be forgotten.

For web pages, the Internet Archive only does the server side... there does
need to be an archive of web browsers as well, and there probably will be some
day. I have no idea when that will be, but I think it will happen.

[1]
[https://en.wikipedia.org/wiki/Digital_dark_age](https://en.wikipedia.org/wiki/Digital_dark_age)

~~~
ashitlerferad
[https://www.softwareheritage.org/](https://www.softwareheritage.org/)

~~~
chubot
That's a great effort. Though their mission isn't exactly what I am
describing, it's definitely on the way.

It seems like it is mostly about collecting source code at this point. But the
harder problem is the build and runtime environments (and how to "bottom them
out"). Without the ability to execute it, source code has limited utility.

"Given that any software component may turn out to be essential in the future,
we do not make distinctions and collect all software that is publicly
available in source code form."

~~~
ashitlerferad
The Debian snapshot service keeps binary packages too:

[http://snapshot.debian.org/](http://snapshot.debian.org/)

The Ubuntu Launchpad system has something similar.

Fedora's build servers keep all packages for eternity IIRC.

------
Klathmon
>If you only need a small amount of relatively simple code and the license
allows it, then just copy that code into your project.

I disagree with this. With a good dependency management system, this should
almost never be done, even for the most trivial code. If you find it somewhere
else, and it's published as a "dependency" (module, package, etc...), you
should install it as such.

Lock the version, vendor your dependencies, keep a copy of the full source,
but don't just copy it into your project.

Even trivial code snippets "decay", and being able to look at a piece of code
that "decayed" and see that there was an update 6 months ago that fixed the
problem will save time over trying to follow code copied into your code base,
a possibly out-of-date comment saying where it came from, and the chance that
anyone could have modified it from it's original without updating the comment
in the meantime.

I think of a dependency is "copy-paste with metadata", and throwing out that
metadata seems like a bad idea.

Is there something I'm missing or have completely wrong, as I seem to see this
being advocated for more and more, especially in the javascript ecosystem?

------
mattip
The OP refers to open source, but his comments apply just as much to any
third-party component in your product. Many proprietary products also suffer
from slow or non-existant upgrade paths, and then what do you do to upgrade
the component?

------
watermoose
While Daniel is correct that open source projects require upkeep and typically
require a community of users and developers giving back to the project in
order to succeed or at least continue, I think this could be misused as a
reason to back those that erroneously conclude that closed source software
that is backed by paid work on software is the best method, and this in my
many years of experience is incorrect.

Another correction is that "open source" does not mean free as in beer. Source
can be open and not free. To ensure that you are using or offering source with
a free license, please read: [https://www.gnu.org/licenses/license-
list.en.html](https://www.gnu.org/licenses/license-list.en.html)

~~~
AJ007
By analogy open source is free as in baby while closed source is like a baby
in a maximum security prison. At least one you have the option of fixing when
it breaks. The other, you hand someone cash and maybe they fix it.

The other problem, especially as software migrates in to pay-to-use cloud
services, is that you have no clue what the future $ cost will be.

Software startups that began with free tiers or really competitively priced
tiers have morphed in to things that cost six or seven figures a year. String
a few of these together and suddenly you have to figure out how to roll those
costs back on to your own customers -- and it may turn out you don't have a
viable business model. Further down the road, some of those companies won't
exist. Some may be purchased by Oracle/IBM/MS and then reallocate funds from
upkeep & dev to nightmare salespeople.

------
exolymph
tl;dr from the conclusion:

> Open source software is a massive boon to programmer productivity, saving
> man centuries of effort. But remember, just as you own your availability,
> you also own your software and everything that goes into it.

------
ashitlerferad
[2014]

------
hiddentag
Before you file a github issue, see if you can fix the problem yourself and
submit a pull request. You're in the best position to fix the bug - you've
reproduced the problem, you have the correct environment, and you have full
source code.

If you're unable to fix the problem, it's your duty to provide as much useful
information as possible in order for someone else to solve it. Saying
something like "it doesn't work with X" is not helpful. Put yourself in the
position of the maintainer and provide the information you'd like to see - OS,
versions, exact commands to reproduce the issue, sample data - whatever is
necessary. And if you've reported an issue, it's your responsibility to follow
up and test and prospective solutions and provide feedback. Their time is not
less valuable than yours.

Remember that open source project owners have done you a favor by giving you
access to the code and owe you EXACTLY NOTHING. Complaining free riders are
the worst. Give back to the community.

~~~
no_protocol
> fix the problem yourself and submit a pull request

For smaller projects out on GitHub I often see attempts at this that fail.
Stuck in "Open" status for years or outright rejected.

Maybe the account in control of the canonical repository is no longer active
or interested in the project.

Maybe that person doesn't understand or agree with the submitted code or asks
for more accompanying work.

Maybe the submission is under-documented or not even fully understood by the
submitter.

Each of these types of sticking points can be overcome, but the bottom line is
they all take a lot of work from one side or the other.

Does anyone have examples to share of open source projects that have very low
friction for drive-by contributions while still maintaining quality? Projects
with very clear documentation and instructions for contributing? It would be
nice to have some models to aspire to.

~~~
PieterH
> Does anyone have examples to share of open source projects that have very
> low friction for drive-by contributions while still maintaining quality?
> Projects with very clear documentation and instructions for contributing?

Yes, absolutely. Read
[https://rfc.zeromq.org/spec:42/C4/](https://rfc.zeromq.org/spec:42/C4/).

We developed the C4 contract (in the form of an RFC) precisely to teach
maintainers how to welcome new contributors while keeping quality high. It
took many years to refine this approach. By formalizing it, it becomes really
simple for projects to adopt: all you need in your README 'Contributing'
section is a license (we recommend MPLv2), a link to this RFC, and later a
style guide to ensure consistent code style.

The thing about C4 is that it teaches people to make small testable patches,
and to trust new contributors. We know from experience that it's users of a
project who keep it alive. Original authors and core maintainers burn out, get
full time jobs, start new projects. As long as you have users, though, you
have potential contributors.

Small patches, merged immediately, with reviews and improvements made
asynchronously over time. This style is lovely to work with, kills bike
shedding (we argue with new patches rather than comments), and reduces the
friction in the project to as low as possible.

More on optimistic merging:
[http://hintjens.com/blog:106](http://hintjens.com/blog:106)

In terms of friction: we aim to get a patch live on master within a few
minutes. If that breaks master, we fix it either with a new patch, or a
revert. Anyone can submit a patch, anyone can revert or improve previous
patches. You can't merge your own pull requests. We work straight on master so
new code is pushed aggressively towards users capable and willing to use it
(those who build off master). We use CI heavily to test backwards
compatibility, i.e. that existing APIs and protocols haven't broken.

There is also a whole theory of how incremental testable patches remove the
need for "intelligent design" and thus the dependency on brilliant key
individuals. That's another story which I cover in my book "Social
Architecture". Free to read online if you want it.

Best of all, this process works. We know because we've been using it quietly
and successfully in the ZeroMQ community for years.

Of all the things I've done in open source, I consider this my most important
work, as it solves the really essential problem raised in TFA, which is how to
keep open source projects alive over the long term.

~~~
tbirdz
Thanks Pieter!

I've been interested in that optimistic merging idea of yours for a while now,
but I've never had the courage to pull the trigger on it anywhere myself.

I had a few questions about it though. The process seems to work by moving the
code review portion after the merge instead of doing it before the merge. So
instead of sitting in a review queue, the code goes live, and if there's any
problems the code is removed. I was wondering if this is really that much
better from the contributer's POV. Sure it's discouraging if they submit a
patch and have it ignored, but it must be even more discouraging to submit a
patch, have it accepted, and later have it removed because it wasn't good
enough.

Also, I know the incremental patch style is the style for OM, but is there any
way to do large sweeping changes, other than forking the project or trying to
break it into a series of incremental changes?

How well does OM scale with number of contributors? Have you any experience
with very low numbers of contributors (where I think you could potentially
have bad patches sit in the repo for an excessive period until they are
removed), or with very, very large numbers of contributors?

Really though, all the ZeroMQ RFCs are great. If any of you are doing some C
programming, I'd highly recommend checking out ZeroMQ's CLASS C style guide:
[https://rfc.zeromq.org/spec:21/CLASS](https://rfc.zeromq.org/spec:21/CLASS)

~~~
PieterH
Like any radical shift in technique, it's best to try on a small project. It
takes a while to get the hang of it. I'll answer your questions...

\- It is really seldom that a patch is reverted (that a patch is removed). As
in, it only happens in exceptional cases, when someone has made an obviously
toxic patch by accident on on purpose. It's far easier to move forwards with
improvements to the patch. We encourage people to do this rather than provide
opinions on the code in writing. What this does is interesting: it brings
others in the project into the work, and creates instant mentor-mentee
hookups. We see this really often and it is a wonderful thing. You make a
patch, it's merged, someone sends a patch on your patch and explains why, and
suddenly you have someone in the project who knows that area and can teach
you.

\- Large sweeping changes are sometimes the simplest way to e.g. refactor some
code. It's usually a Really Bad Idea to make functional changes at the same
time. It also depends a lot on the language. I'd disrecommend large sweeping
changes to a C project, absolutely. The risk of introducing multiple bugs is
just too high. In a scripted language, far less risk, and so it's safer. In
general, functional changes appear to work better as many small testable
steps, and refactoring can work as a single mass change.

\- OM scales really well. It needs 2+ people in the project. After that, the
limits are elsewhere. Projects with hundreds of contributors are probably too
large in terms of internal structure. It means you get ad-hoc pseudo-projects
inside a single repository which means poor internal contracts, etc. I'd say a
project with more than 7-10 _active_ contributors at any time is getting too
large. IME a network of small projects works far better than larger monolithic
projects.

\- I use OM (the C4 protocol) on all projects, whether they are just starting
(my first act is then to call for co-maintainers), or have been around for
ages (like the libzmq C++ core library, with hundreds of contributors). We've
never seen an issue of scale.

Cheers!

~~~
hiddentag
Similar to
[https://github.com/illacceptanything/illacceptanything](https://github.com/illacceptanything/illacceptanything)
?

;-)

~~~
PieterH
No, quite different. There are strong rules about what constitutes a valid
patch. Probably stronger than in most projects.

------
JoeAltmaier
"Free as in Baby" \- how apt! I have my own children; I have no desire to
adopt someone elses' brats. This explains perfectly why I'll search for a
supported commercial product before any open-source deal.

