Rules for Open Source Success
hintjens.com
hintjens.com
Agreed, but if you are the only user, serve yourself first on the project. If you determine that you can't serve yourself and others at the same time, it might be a bad road you are going down.
"2. Use a Share-Alike License"
First, RMS hates the term "open-source", so it's funny that the idea is to promote GPL here. On top of that, you call for a share-alike license, which is a term used mostly for creative commons licenses, which are usually for creative works.
The license matters, but most people suggest Apache. (L)GPL v3 (not v2) is also great if you don't want it to be integrated into business products. I'm not sure why you'd want to use MPL v2 unless you are writing something for a Mozilla product? If you don't give a crap about your rights, choose MIT. Then, use a Creative Commons license for creative works that aren't free.
"3. Use an Zero-Consensus Process"
"Merge first, fix later"
No, don't do that. I understand you are trying to keep other forks from taking over, but you shouldn't allow everything. I've rejected some bad PRs before because the developer didn't understand what they were doing. There's no reason to merge that and then undo it. Explain to them what they are doing wrong and refuse the merge- then they will either fix it or you save yourself the trouble of having to undo it.
"4. Problem, then Solution"
"Every patch must be a minimal solution to a solid problem" is wrong. New features may not relate to a problem you or others are trying to solve.
"5. Contracts Before Internals"
Not every project needs its API documented to be successful.
"7. Write Down the Rules"
Those rules for ZeroMQ are really aggressive sounding. You don't have to use those. I think it's fine to just point people to docs about the PR process and information on how to build, test, release, etc.
That's a counter-intuitive claim. Can you give an example?
If it has a DSL, or any sort of scripting, as a user you damn well want it to have API docs. It's super frustrating to have a use case the author didn't think about, and you have to figure it out via trial and error because the author didn't think it'd be worth spending a few hours documenting what each thing is supposed to do.
Don't think that just because some projects were successful without API documentation, maybe because they served a particular niche, that means you can just ignore documentation because you feel it's not necessary.
I think that good documentation for usage is a great idea, but not all projects need formal API docs, because not all of them intend for the classes in their project to be used as a library.
I agree with you that if your code intends to be used as a library, you should provide API docs.
And, if you expose a service then you should probably provide API service documentation with examples.
I'd add also that usage examples can sometimes go much further than API docs to clarifying things.
RMS isn't the only proponent of copyleft. The Mozilla license also has some weak copyleft clauses.
Do you have metrics for that? I doubt your claim, given that the GPL is the most widely used license? GPL 2 and 3 and LGPL 2 and 3 alone are 40% of the licenses in the black duck stats: https://www.blackducksoftware.com/resources/data/top-20-open...
Share-Alike is the name which is easiest to understand. Copyleft is the historical name of the approach. Reciprocity is the concept.
Apache is suggested as a free-software-compatible alternative to GPL v3 by RMS himself. In the past 15 years of contributing to open-source/free code projects, Apache is the longest standing license that over and over people have recommended. It is an intense license, but it covers the bases legally, whereas others do not. Still- I've used GPL, MIT, and BSD in the past- just learn about the pros and cons and choose what you think you should use, though.
That RMS says that you can use Apache if you don’t want copyleft does not support that it’s the most widely suggested. You can be sure that RMS will not suggest using Apache over GPL where GPL can be used.
There are less people who are opposed to Apache than there are people who are opposed to the GPL (or strong copyleft in general), but that does not mean that there are more people who would suggest using Apache than people who would suggest using the GPL.
Free Software proponents will say “I would suggest GPL, but Apache is still Free Software, so it’s OK”. This is not the same as suggesting to use Apache.
I suggested not using Blackduck's stats because they are incomplete. I know this because I used Ohloh for a few years and found that there were many projects that weren't listed there, and I did not have time to list all of mine there, and I have quite a few.
I do not have enough information to say for certain that GPL or any other license is the most well used license. If I had to guess, I'd say that there would be quite a large amount of code that is available online that has no stated license, so I'd think that would be the most common. After that, it could be "any version of GPL"- I don't know. Maybe Google with all of their resources and analytics would be best suited for determining a good estimate.
Starcraft 2 has LGPLv3 libraries in it. Its hard to not see Blizzard as a business nor SC2 as a product.
This makes it viable to integrate LGPL libraries into commercial products.
I agree with merge first fix later, if you have sufficient work hours to actually do the fix: in the Freenet project we lost many contributors, because their code wasn’t merged in time, so they just lost interest: “my effort is wasted here”.
Truth is: Those who get their code merged quickly are more likely to review other code, so they grow the community.
You can only do that if you actually have the time to keep quality up.
The rules I explained work together. If you allow large confusing patches, or features that don't solve clear problems, then it won't work as well.
Can you elaborate on this, because as written here, this seems like a negative statement? As someone who doesn't know/care much for licensing, I just choose MIT when releasing code, because I don't care what someone else does with it.
Aside from someone using/modifying my code in a proprietary program without crediting me, can choosing MIT come back to me negatively?
This is exactly it.
You had the rights to further protect your work, but you didn't. That's what he means about not caring about your rights.
Hilarious combination there. Merge the patch first, then invent a solid problem for it to fix!
After 25 years of experience, one would expect some acknowledgement of the difference between the two concepts.
Open source vs free software is the opposite. Free software is about trying to claim the moral high ground, and proponents see a huge difference. Open source is about what works, and as long as it works all that silliness isn't all that relevant.
I would say that thinking they're the same means he's on the "open source" side of that, except that his "share-alike" promotional FUD is very clearly a "free software"-side argument.
:)
No bias here whatsoever. Nope.
Though, ironically, your justification for "open source" could just as easily be applied to proprietary software, rendering open source completely devoid of meaning.
Indeed, the term "open source" was coined as a marketing term for promoting free software:
http://jordi.inversethought.com/blog/5-things-we-have-forgot...
edit: sigh, every time I say there's no difference I have to contend with the downvotes. Go read my blog post above, please.
In the same vein, you call it "free software" when you're promoting it for the freedom and you call it "open source" when you're promoting it for the practicality.
> you call it software if you're selling it to hackers.
Wrong. You just don't pick up any software you look at the ecosystem: are they contributors, how many release, downloads etc.. it's not just a problem of software. Most hacker I know don't look at the code to say whether a software is good or not, but instead take the "execs" stance of looking at the ecosystem and quickly processed metrics.
I mean that "solution" is the pointy-haired boss way to say "software". The pointy-haired boss doesn't care how the problem is solved, just wants a solution. The hackers see the software itself as the fundamental thing, not some abstract buzzword "solution".
Another example: you may expand the "DRM" acronym as "digit rights management" if you think it's fundamentally about authors' rights or you expand it as "digital restrictions management" if you think it's fundamentally about user restrictions. Two different terms for the same thing.
My point here with these examples is that the only difference between "open source" and "free software" is how you're marketing the same software and the same licenses.
If you say Open Source it implies that the choice of a copyleft license is a strategy to improve your return of code, but the default is “just be open”. The goal is to get other people to support you.
If you say Free Software it implies that the choice of a lax license is a strategy to improve your spread, but the default is copyleft. The goal is Freedom. It sounds easy nowadays, since there is so much Free Software that if you have some free time you don’t feel the restrictions from proprietary software.
If you want to feel the restrictions from proprietary software again, try changing the layout of gmail and keeping it in working state for 5 years.
See iOS for how common this is, which is to say very.
And while Share Alike have their (good) use-cases, IMHO it is bad to recommend them as the default; the best standard is CC-BY or MIT/BSD.
Why? For me "open" means "open" - i.e. can be used by anyone, for anything (not "open, but only for the openness believers... and only of the same creed"). All share-alike clauses have issues:
- viriality (you have to get infec... I mean: accept another license instead of the one you are using),
- kosher rules (e.g. you can't combine GPL with CC-BY-SA).
So, with the openness, you can't beat the WTFPL (http://www.wtfpl.net/).
We've been happily using MIT Expat for everything we open source and have not had any issues with it. Criticism, yes. Issues, no.
Share-alike protects against such fragmentation, allowing any developer to always take any improvements made to a different branch and merge it back to your version; with MIT licenses, that is often not an option.
A modern paradigmatic example is KHTML, the LGPL rendering engine that was the basis for Safari. Without the share-alike, it's uncertain that Apple would have released Webkit, and it would have been almost certainly impossible for Google to fork it as Blink - most improvements would have been unavailable to the public, with Apple using hidden changes as a competitive advantage.
Hmm. They may well have eventually released it — WebKit did eventually get released (years after the code dumps of WebCore an JavaScriptCore).
They got complaints for just having code-dumps (or WebCore/JavaScriptCore) alongside releases, which made it hard to have any sort of individual patches. They were still in no way obliged to move to developing it in public, nor were they obliged to release WebKit.
There are many situations where this level playing field is useful. For example, consider it like a consortium. If you have many groups in the consortium, you want each group to contribute equally. The only way they are likely to do that is if one group doesn't get an unfair advantage.
So the downside of permissive licenses (like MIT) is that it can (in some cases) discourage cooperation. Let's say you have a library that you license with a permissive license. Your competitor may not want to contribute (publicly) to that library because they fear that you will use their changes in your proprietary code to gain advantage over them. In fact, there is an advantage to consuming permissive code and keeping your changes to yourself as long as you don't mind paying the cost of merging upstream changes.
Conversely, there are times when a permissive license is more appropriate/beneficial. In some cases, there is no real risk that others will "horde changes". For example, if you are the author of a programming language, it is in everybody's best interest to continue to develop it. Nobody really gets any advantage by making their own proprietary Ruby implementation, for instance.
People should think very seriously about which free software license they choose, because it makes a difference. Permissive licenses lower the barrier to entry, but potentially create one-sided advantages for some players. Share-alike licenses ensure that everybody is working with from the same place, but makes the barrier to entry higher.
Generally speaking, if you look at the free software ecosystem, you will see natural divisions. Software that creates an entire application (like a word processor, or image editor, etc) tends to use a share-alike license. They do not want someone to take their work, add some proprietary icing to it and take mind-share from their project. On the other side are development tools and libraries which tend to use permissive licenses. Nobody benefits from making proprietary versions of these things. Even if some tries to do so, nobody will be interested in it.
There are people who feel that ensuring everybody has the same opportunities is morally a better choice. Obviously some people disagree, but I often find it surprising that the two sides can't at least understand the other's point of view.
EDIT: copyleft library that I've modified.
If you're implementing an open standard to try and encourage use of higher quality implementations of that standard, a permissive license is probably the right choice.
If you're creating an open-source clone of some software (be it the GNU OS or LibreOffice), a copyleft license makes far more sense—the fact it is open-source is the defining characteristic of your software.
That's a terrible thing to aim for with your project, because anyone else can duplicate your defining attribute with the mere choice of a license. Why not aim to make the defining attribute that it's the best?
Freedom is a goal in itself, and “clone” defines how it’s the best: be directly usable to someone who knows the other software.
That's why I think the best model is offering open source code that is freely available for other open source projects (to expand "freedom" and all that) OR free/gratis software (or perhaps only to non-profits), BUT if you get paid for it, you have to pay for a license. I think it's more than fair that if you make money off open source software you should give a cut back to the creators of that open source code.
Right now we're in the shameful situation where large companies making billions of dollars in profit every quarter don't even pay modest sums to projects such as OpenSSL (this changed a bit, but only after Heartbleed happened, and there are many more such projects that don't get the same benefit).
I know there are some disadvantages to this model, such as having hardware built with open source software cost more than it would otherwise, but let's face it the alternative would be hardware that comes with proprietary unverified code that may cost even more. So I think this "compromise" is well worth it, considering it can get the open source developers the money they need to keep working on it and expand the project.
The old-style BSD license is considered rather awful due to requiring a notice in your documentation somewhere.
Requiring money based on what you're doing with the software is more complicated, and dividing it up between all the included and depended-on projects is even worse.
I disagree with your shism between open source projects and getting paid.
People should get paid for improving free software, because many others know that they benefit from that. Copyleft is a good tool to ensure that the improvements can flow back into the projects.
Please, please, please, do not use the WTFPL, especially if you say you care about "openness" and "kosher rules." The WTFPL is so poorly written no one knows what it really means. Consequentially, legally-sensitive people/organizations may actually have a harder time using a WTFPL-licensed project than a GPL-licensed project.
If you want a public domain-style license, use CC0 (https://creativecommons.org/about/cc0) instead.
I'm more of a GNU GPL guy myself, but the WTFPL isn't a bad license.
Edit: Ah oops, OSI did not approve WTFPL. Oh well.
He even points out that using it could get you sued due to the lack of a warranty disclaimer by default.
I've heard other stories of companies refusing to use WTFPL-licensed code, and that alone should discourage you from using it if you goal is really to let anyone use the code with no hassle.
Edit: the FSF doesn't recommend it (in contrast to CC0, which they do recommend if you want a public-domain license): http://www.gnu.org/licenses/license-list.html#WTFPL
As you say, CC0 is the way to go for transmitting things to the public domain (when it's applicable; many European countries do not have the concept of "public domain").
I think it's a valid, personal choice.
If someone wants to make the point that they think licensing legalese sucks, and wants to license their work accordingly, then fair enough.
It's a little absurd that I shouldn't be able to, in plain words, express "This is my own work, and you can do whatever you want with it". Eg. I shouldn't need 'warranty disclaimer' to not be at risk of liability, unless I was explicitly providing some kind of guarantee in the first place. (It's just a bit of freely available software, hardly leaving a dangerous item out on the streets.)
Any legal system that leaves its citizens unable to be protected by simply using clear, plain and unambiguous language is failing in its duty to some extent, so I'm perfectly sympathetic to developers who choose "fuck that shit" as a personal preference. :)
As a protest license, it makes some sense, but I do not think that's what draws most people to it. People choose it because they want their code to be used by anyone, because they think it's the most "open." This is the motivation that the parent commenter gave for the WTFPL. But as a protest license, it's ideologically motivated just like the GPL and does a poor job at letting anyone use their code.
> It's a little absurd that I shouldn't be able to, in plain words, express "This is my own work, and you can do whatever you want with it". Eg. I shouldn't need 'warranty disclaimer' to not be at risk of liability, unless I was explicitly providing some kind of guarantee in the first place. (It's just a bit of freely available software, hardly leaving a dangerous item out on the streets.)
As much as you may wish this to be the case, it's not. It would be a pretty expensive way to make a point if you end up being sued because of the lack of a warranty disclaimer. This is a risk which I think is not adequately conveyed to people who choose the WTFPL.
So sure, it's a personal choice, but if you do choose it you're not doing yourself or anyone else any favors.
Agree that it isn't a good choice if what you want is the most permissive, inclusive license.
(Completely with you there, and hadn't noticed the misjudged "with the openness, you can't beat the WTFPL" above.)
> Sure, it's a personal choice, but if you do choose it you're not doing yourself or anyone else any favors.
I wouldn't and don't use it for my projects, but I'd absolutely defend anyone else's choice to do so.
The choice to go with a license that actively eschews the standard reliance on legalese is a form of self expression. If someone chooses to use it and disregard the supposed legal risk, then I totally respect that.
I stopped reading at "merge first, fix later". OUCH!
I think wether such an approach works heavily depends on the kind of project (and as such shouldn't be posted as a general rule). For something relatively new and/or small it may work very well, but as soon as you reach a certain complexity it's unsustainable; at least if core components are involved.
Growing zeromq ideas mainstream will provide more value to the project of improving distributed software than changing drastically zeromq (to (re-)build nanomsg community).
> testing coverage completely matters.
testing matters not testing coverage.
Testing matters as way to give insight about the project, api and protocols as such integration tests more useful that unit tests. This help people jump in, it's a way to document the API/Protocol.
Achieving the API and protocols is more important than having a good code coverage. If there is no code, there is nothing to cover, and nothing to show.
He develop his ideas of good community processus in the chapter Sphere of Lights of Culture and Empire essay [1]
What I'm doing with these "Top 10" articles is documenting our experience over the last years.
I guess people said "OUCH!" a lot when Wikipedia said you could edit any page. It is really similar here.
For example, my current favourite Open Source project uses a permissive license, always finds consensus on the mailing list before pushing to master, and is huge. Which is in blatant violation of rules 2,3 and 9 from the article. And it's been growing in popularity for decades.
There is no such thing as general rules for Open Source projects.
I don't like the "merge first, fix later" advice, but I'm happy to see someone promoting the use of copyleft licenses. Thank you! You get it.
Glad to see this one in here. It seems like too many open-source project communities are incredibly hostile to newcomers or people with differing opinions. Linus Torvalds comes to mind.