[lighthawk]

"1. People Before Code"

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.

[ArneBab]

"Merge first, fix later"

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.

[PieterH]

"Quality" is a false goal. Remember the first arguments over Wikipedia and article "quality"? It is exactly the same here. You need people, contributors, eyeballs. Get that, and quality will emerge smoothly over time. Losing a contributor because "quality" matters more is self-destructive.

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.

[belorn]

> (L)GPL v3 (not v2) is also great if you don't want it to be integrated into business products.

Starcraft 2 has LGPLv3 libraries in it. Its hard to not see Blizzard as a business nor SC2 as a product.

[_puk]

I understood that was the point of LGPL over GPL; it stops the GPL licence bleeding into other areas if you are simply using a library as is.

This makes it viable to integrate LGPL libraries into commercial products.

[quadrangle]

you can use GPL in commercial products. Just follow the GPL. It's not ant-commerce. Oh, you meant "proprietary" products? The set of commercial and proprietary is not a union, it only overlaps.

[lighthawk]

It depends on how you integrate the code into your product. Please read up on the licenses to understand how they are different.

[ArneBab]

“Most people suggest Apache”

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.

[lighthawk]

Though it would be great if you could, don't use blackduck as the measuring stick. (Used to be Ohloh now) Blackduck is not a full view into the current state of open source and free software. I gave up on trying to keep my projects updated not long after the transition from Ohloh to Blackduck.

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.

[ArneBab]

If you have a better source, feel free to share it. This is a datapoint which strongly disagrees with your claim. It might be flawed, but that does not make it invalid. Do you have data which supports your claim?

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.

[lighthawk]

When I say "most people suggest Apache", I mean that for as long as I have been contributing to and developing with various open-source projects most people that I have talked with about licensing open-source or free software projects have suggested using the Apache license. I have also had someone tell me that he wouldn't use my project since it was MIT licensed, and suggest I start writing code under the Apache license if I didn't want to use GPL. Personally I have frequently not chosen to use the Apache license, but that is changing and actually I've been using GPL v3 in some recent work.

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.

[lhorie]

> Not every project needs its API documented to be successful.

That's a counter-intuitive claim. Can you give an example?

[lighthawk]

It depends on your definition. API is application programming interface, which means that if your product doesn't intend for it's internals to be called or it is a DSL, etc. you don't necessarily need to have formal API docs- you just need usage docs. If it is a C, C++, Java library, then yes, you probably want API docs/Javadocs.

[jharger]

This is just my opinion, but if you want any other contributors besides yourself, I think you definitely want API docs. Just because it's not exposed to the public doesn't mean nobody cares what a function/class does.

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.

[lighthawk]

I think you and I have different idea of what API docs are.

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.

[jordigh]

> First, RMS hates the term "open-source", so it's funny that the idea is to promote GPL here.

RMS isn't the only proponent of copyleft. The Mozilla license also has some weak copyleft clauses.

[squeaky-clean]

> If you don't give a crap about your rights, choose MIT.

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?

[cosarara97]

> someone using/modifying my code in a proprietary program without crediting me

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.

[Khao]

So what do you recommend? I just open-sourced my first library and I chose MIT licence because I feel it was what was recommended by github when they ask you to choose a licence. I really didn't explore my options much.

[tedunangst]

"3. Use an Zero-Consensus Process" "Merge first, fix later" "4. Problem, then Solution" "Every patch must be a minimal solution to a solid problem"

Hilarious combination there. Merge the patch first, then invent a solid problem for it to fix!

[Asmod4n]

You cannot include Apache License v2 code into GPLv2 code, but it works with the MPL v2, afaik.