9 ms·

"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

"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.

lhorie 11y ago
> Not every project needs its API documented to be successful. That's a counter-intuitive claim. Can you give an example?
- lighthawk 11y ago
  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 11y ago
    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 11y ago
      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 11y ago
> 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.
ArneBab 11y ago
“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-source-licenses 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 11y ago
  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 11y ago
    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.
    - 11y ago
belorn 11y ago
> (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.
- lighthawk 11y ago
  It depends on how you integrate the code into your product. Please read up on the licenses to understand how they are different.
- _puk 11y ago
  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 11y ago
    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.
ArneBab 11y ago
"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 11y ago
  "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.
Asmod4n 11y ago
You cannot include Apache License v2 code into GPLv2 code, but it works with the MPL v2, afaik.
squeaky-clean 11y ago
> 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 11y ago
  > 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 11y ago
    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 11y ago
"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!

lhorie 11y ago

> Not every project needs its API documented to be successful. That's a counter-intuitive claim. Can you give an example?

lighthawk 11y ago
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 11y ago
  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 11y ago
    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 11y ago

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

ArneBab 11y ago

“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-source-licenses 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 11y ago
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 11y ago
  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.
  - 11y ago

belorn 11y ago

> (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.

lighthawk 11y ago
It depends on how you integrate the code into your product. Please read up on the licenses to understand how they are different.
_puk 11y ago
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 11y ago
  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.

ArneBab 11y ago

"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 11y ago
"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.

Asmod4n 11y ago

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

squeaky-clean 11y ago

> 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 11y ago
> 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 11y ago
  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 11y ago

"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!