
How open is too open? - fanf2
http://ivory.idyll.org/blog/2018-how-open-is-too-open.html
======
jamesblonde
AGPLv3 is the cloud-condom open-source licensing model for the future. You are
protected from the cloud-providers, who otherwise to monetize open-source
projects that enterprise vendors develop. For example, MongoDB got offered
money by AWS to include it in Redshift, but they said no - MongoDB is AGPLv3.
AWS just took postgres and MySQL for free, because they could. Who earns the
most from, yet contributes the least to, Hadoop? AWS! If you're Hortonworks,
Cloudera, or Data Artisans (Flink) are you celebrating AWS' monetization of
the software you develop?

Honestly, i think Apache licensed open-source software is dead for startups.
Cloud providers do not compete on an even field anymore, and the basic premise
of an open ecosystem for Apache software is now a pipe-dream - cloud providers
(mostly, AWS) will dominate providing managed versions of Apache licensed
software. Long live AGPL-v3!

~~~
ilikebits
Yes, this is a big issue for many infrastructure startups. The AGPL scares
potential users and customers away, but permissive license often get taken
advantage of.

At FOSSA, we've commissioned a new license called the Commons Clause
([http://commonsclause.com/](http://commonsclause.com/)) that tries to address
this exact problem, so that developers can create permissive software without
being exploited by providers.

~~~
beojan
What's the point of using a permissive license then? Why not just use a
(situation appropriate -- i.e. LGPL, GPL, or AGPL depending on what precisely
the software is) copyleft license?

~~~
ilikebits
The point is to prevent service providers like Amazon from making money by the
software you built, but still allow end users to operate and self-host and
modify it.

~~~
beojan
AGPL is just fine for that.

------
pitaj
One thing mentioned is that some people make extensive use of private modes of
communication with project leaders. I've fallen prey to this as a contributor
myself, so much that I've now made it my policy to never converse privately
unless it's related to a security issue.

I think another important point is multiple channels of discussion. The
project I work on has a forum where people can ask for help installing or with
other issues they have. If they find a bug or have a feature request, it goes
on our issue tracker on GitHub.

~~~
notmyname
That's great to hear that you're forcing yourself to keep communication in the
open, when at all possible. That's one of the best ways to keep a community
healthy.

In my experience with a particular open source project, more than half of new
contributors started by communicating privately with myself or some other
leader in the project. This is only bad if the communication never moves out
of private conversation. I've found it normally takes a few nudges to get
people to build their confidence and participate publicly.

Interestingly, it's not only new contributors who suffer from this. I've been
told by some of the most prolific contributors to our project that they are
still intimidated to speak out publicly. Many times these feelings come from
deep-seated cultural norms that don't really fit with traditional
Western/American ways of communicating. And that's ok! We all learn together
how to best communicate with each other. And we get a healthier community and
better code out of it.

------
allenleein
“Nobody has open source too much.” -Fireside Chat with Paul Graham.

Source:
[https://youtu.be/UWh_iAG9cGw?t=15m15s](https://youtu.be/UWh_iAG9cGw?t=15m15s)

~~~
stingraycharles
That statement is very difficult to prove. Where’s the control group? To take
an example from YC themselves, what would rethinkdb have looked like if they
kept a close core and monetized upon that?

It’s a very bold claim, and I’m not sure I agree.

~~~
wolco
They tried that route and gave up on 2016.

~~~
stingraycharles
That isn’t the same. Asking money early on is often a clear validation of
monetizable ideas, which isn’t the case with open source projects; even if you
gain traction, you never know whether the users will pay for it.

~~~
zzzcpan
But you can ask money either way, whether you open source things or not.

~~~
stingraycharles
That is true, but the statement by pg was that there hasn’t been a single case
where a startup open sourced too much. I’m saying that at best it’s uncertain,
and more realistically not true.

You _can_ open source too much, especially when you don’t know yet which
aspects of your business add the most value (and thus you should charge for).
You can ask money when you open source stuff (e.g. support, cloud service,
etc), but how do you know when you shouldn’t have just licensed your actual
product?

~~~
zzzcpan
I understand what you are saying, but open source code cannot be a product, so
it doesn't matter whether you open source everything or not. You will also
feel over protective about it, not actually open sourcing everything under the
most permissive license. No matter how I think about it, I can't imagine how a
startup can over open source things.

~~~
TimJYoung
That's not true. You can sell a software product and provide the source code
as part of the product and/or sell the source code at a premium price to those
that need/want it in order to make modifications/customizations or just to
have for security/auditing purposes. However, the general stipulation is that
you cannot just share that source code with everyone else, only to other
customers that have also purchased, or have access to, the source code.

------
_pdp_
A bit of a side-topic but I am sure many people will resonate with this. My
company has been considering making many internal projects open source - these
are the foundations of our products. Why have we not done it yet? Well, it
takes a lot of effort to go open source - more than people realise. We can't
just dump bunch of sources out there - there is no point in doing that. We
need to open them so that they are well documented, understood, have good
support around the build system any many other things you don't need to
consider when developing in-house products. So while open source is great and
I love it as much as the next person it is not easy.

~~~
notmyname
I'd encourage you to do it anyway. We're on the same journey at my company.
Some of our product is based on a fairly large and active open source project.
Others are much more limited and simply at the "here's the code, have fun"
stage.

There's different levels of "open source" (everything from one-way code dumps
to full-on maintained-as-a-whole-distributed-global-team). In my experience,
it's easier to start with a simple "here's the code, bug reports welcome".
This starting point is generally an easier sell to management who's worried
about project management taking too much time away from other work.

Like all things, practice, start small, and grow from there. Get's easier as
you go. But yeah--licenses/legal, written policies, governance, marketing,
time prioritization, and more all take a lot of time to figure out.

NB: My own background in open source biases me to thinking open source is
"easy". It's not; it takes a lot of work. The good news is that there's a lot
of tools and help available for anyone wanting to start.

------
benologist
I think we have some examples now where being proprietary ultimately created
competition from open source instead of being a moat that protected anything.

Like GitHub vs Gitlab, the people most-affected by GitHub's restrictive code
licensing is Github themselves wasting time and effort giving any fucks about
it and losing customers anyway. Their proprietary license protecting their
code set competitors and intentional clones back days, weeks or months ...
years ago.

Restrictive open source licenses seem equally pointless, it's just more clear
how you specifically do what you do in what may ultimately be one of many
suitable approaches people use to compete with your version.

I feel like we should be using public domain much more and have let ourselves
become very distracted by imposing restrictions on our code.

------
benmarks
This post speaks to much of what we've implemented and discovered in the last
couple of years at Magento. Our 1.5-year-old Community Engineering team was
created from top core architects and given a mandate to facilitate
contribution by our rather large open source developer community. We've
managed to get core code contribution to >50% of all new code in that time -
mostly by implementing controls and processes which reduce the burden by
encouraging alignment, quality, and organization. Think automated CI, issue
and feature backlog grooming, test coverage, and hands-on workshops around the
world.

------
fahrradflucht
archive.org link since at least for me the page seems overloaded:
[https://web.archive.org/web/20180702100253/http://ivory.idyl...](https://web.archive.org/web/20180702100253/http://ivory.idyll.org/blog/2018-how-
open-is-too-open.html)

------
jacknews
Woah, "extractive" contributors, but the "investors" are AOK?

~~~
UncleEntity
I've actually seen this in practice, someone wanted their code merged _before_
they would even consider working on the issues pointed out in the code review
because they didn't want to waste their time on fixing up the code without an
ironclad guarantee that it would be merged. The devs didn't want to merge a
"code bomb" and then either have to scramble fix it themselves or yank it out
when release time came around so the whole thing just turned into a time sink
for everyone involved.

~~~
justinclift
Sounds like an edge case scenario (eg not normal).

If the project had a demonstrable history of merging things though, then it
sounds like the person wanting the gatekeepers to accept the not-up-to-
standard code _first_ was just being egotistical. :/

~~~
gwbas1c
I've hit similar issues with new engineers in my closed-source product.

It's more than an egotistical thing; some engineers just don't understand how
to write good code. The engineers who treat code review feedback as optional
don't last very long.

A code review for a newcomer is not a formality; it is often rather burdensome
for all parties until the newcomer is familiar with less obvious parts of the
code.

------
mattip
Kudos to the foundation sponsoring this work, and to the companies that
quietly let their employees contribute on company time.

------
notmyname
I would be extremely interested in any tools that have been developed to
maintain a Common Pool Resource community, open source software or otherwise.

------
bitshepherd
Looks like we broke it.

------
mabynogy
The problem is the money. Not source code nor contributors.

