How open is too open?
ivory.idyll.org
ivory.idyll.org
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 am curious to see if the AGPL begins to gain traction as we move into more and more of a cloud-oriented world.
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.
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.
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.
For example:
Outside-> Proprietary service -> AGPL(Service)
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.
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.
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.
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.
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.
It’s a very bold claim, and I’m not sure I agree.
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?
The point I'm making is: why open source it at all? Couldn't you earn money by keeping the source closed and selling the actual product?
Who writes a small piece of software that changes the world yet do anything else to build commercial value on top of it?
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.
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.
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.
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. :/
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.