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!
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.
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.
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?
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.
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.
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.
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.
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.
> 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.
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.
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.
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?
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.
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?
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.
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.
If you can write a prototype software in just a few person years that is enough to launch a major business, yet you can't generate more value by being the expert hosts/consultants on it, you are a rare breed.
Who writes a small piece of software that changes the world yet do anything else to build commercial value on top of it?
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.
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.
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.
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.
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.
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.
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. :/
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.
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!