How open is too open?

http://ivory.idyll.org/blog/2018-how-open-is-too-open.html

by fanf2 • 8 years ago

113 41 8 years ago

ivory.idyll.org

jacknews• 8 years ago

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

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• 8 years ago

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. :/

mattip• 8 years ago

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

allenleein• 8 years ago

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

Source: https://youtu.be/UWh_iAG9cGw?t=15m15s

stingraycharles4• 8 years ago

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• 8 years ago

They tried that route and gave up on 2016.

bitshepherd• 8 years ago

Looks like we broke it.

fahrradflucht• 8 years ago

archive.org link since at least for me the page seems overloaded: https://web.archive.org/web/20180702100253/http://ivory.idyl...

_pdp_• 8 years ago

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.

notmyname3• 8 years ago

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.

jandrewrogers2• 8 years ago

This. There is a substantial cost to open sourcing software that too many people pretend doesn't exist. For a small company, the added cost of making software open source can be prohibitive and it isn't obvious where the extra money will come from to make it feasible.

I know of many cases where companies wanted to open source software but the plan was nixed when they realized how much it would cost versus keeping it closed. Or companies that did open source their software but the increase in burn rate was not offset by increased revenue.

jamesblonde• 8 years ago

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!

mindcrime• 8 years ago

I don't necessarily agree with you, and I'm generally not a fan of the AGPL... but have an upvote nonetheless, just for raising an interesting line of discussion.

I am curious to see if the AGPL begins to gain traction as we move into more and more of a cloud-oriented world.

skybrian• 8 years ago

But that's the opposite (or at least orthogonal) to what the article is saying?

Users who don't contribute back also don't waste your time. It's the would-be contributors who clog things up with requests that you have to worry about.

reitanqild• 8 years ago

You are protected from the cloud-providers, who otherwise to monetize open-source projects that enterprise vendors develop.

What if I don't care if other monetize my work?

An example: People monetize BSD all the time, -yet I rarely see them discussing licensing changes out in the open at least.

To take it even further: it seems like even if the source code is completely free companies gives back.

As for now my only reason to go with AGPL would be if I wanted to provide a dual licensed library, with AGPL for open source version and a separate commercial version.

I think for the time being I'd actually feel bad if I made a brilliant libary and only released it under AGPL. Why? Because it could have been even more useful to humanity if everyone (including other developers of commercial software like me) could use it.

kolpa2• 8 years ago

Hortonworks was invented at Yahoo, and open sourcing it got an 8-20% decrease in development costs (in the form of external contributions).

AWS provides high quality hosting.

Hadoop provides a vendor-agnostic environment for writing analytics software.

AGPLv3 doesn't just mean that Amazon can't use your software. It means that no one who uses AWS can use software.

Avshalom• 8 years ago

Amazon absolutely can, it just won't

RcouF1uZ4gsC• 8 years ago

Can’t AGPL be gotten around by putting another layer of service between AGPL and what you are offering?

For example:

Outside-> Proprietary service -> AGPL(Service)

jandrewrogers2• 8 years ago

No, you can't make material modifications to infrastructure software without modifying the software itself, at least not without a substantial loss of efficiency and performance.

It is like trying to make a new type of database engine by writing a wrapper around someone else's database engine. It works -- tons of open source databases essentially do exactly this -- but it has well-understood adverse consequences to scalability and performance such that you'll never be competitive in a benchmarks or efficiency game.

belorn• 8 years ago

Imagine people being in court and trying to argue that to a court or jury. The copyright holder arguing that the Service is made available online, presenting screenshots and video of copyrighted elements being presented through a online service, and the defense arguing that the service is not made available since the Proprietary service sits between the user and service.

Getting around the law through technical means sounds great from a technical standpoint but tend to fall flat once a non-technical person looks at it and don't see the technical layer. The obvious example was BitTorrent which people initial argued did not constitute copyright infringement based on an number of arguments, one being that only minor parts of the whole work is ever sent by any single person. Similar people argued that streaming was legal since no one received a copy of the work. Outside-> streaming service -> copyrighted work did not really separate outside from the copyrighted work in a way that made a legal difference.

ilikebits2• 8 years ago

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/) that tries to address this exact problem, so that developers can create permissive software without being exploited by providers.

ben0x539• 8 years ago

Hm, interesting direction once you've decided to give up on open source, but that seems a bit of a leap.

beojan2• 8 years ago

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?

pacala• 8 years ago

I've recently seen http://scip.zib.de/#license. " You are allowed to retrieve SCIP for research purposes as a member of a non-commercial and academic institution.". Could help keeping alive an academic community around it.

pitaj• 8 years ago

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.

notmyname3• 8 years ago

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.

benmarks• 8 years ago

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.

notmyname3• 8 years ago

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

benologist• 8 years ago

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.

mabynogy• 8 years ago

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

How open is too open?

Related Stories