8 ms·

Rules for Open Source Success

89 points by c-rack 11y ago

mpdehaan2 11y ago
Lots of advice I disagree with here, testing coverage completely matters. It's not the most important thing, but it's very important. I stopped reading at "merge first, fix later". OUCH!
- anarazel 11y ago
  Yes, that made me cringe as well. 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.
  - amirouche 11y ago
    This is his writing style, he does shortcuts to keep thing readable and you have sort out the real world constraints yourself. That said the book is readable but some arguments that are difficult to understand.
- amirouche 11y ago
  This must be understood in the light of the philosophy of Peter Hinjens which is the community comes always first, before technical assets. Smoothing community process and interactions is (very) necessary for a project success. 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] [1] http://cultureandempire.com/html/cande.html#toc-3 http://cultureandempire.com/html/cande.html#toc-3
- PieterH 11y ago
  It hurts a lot when your assumptions are challenged. The process we use in ZeroMQ is successful beyond all expectations. See http://hintjens.com/blog:93 http://hintjens.com/blog:93. 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.
stared 11y ago
I am totally for Open Source (and Open Science), but I dislike copyleft licenses (cf. "2. Use a Share-Alike License"). 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/ http://www.wtfpl.net/).
- jobvandervoort 11y ago
  I don't understand the reason the author mentioned that you should use such a license. Why do you have to, in their reasoning? We've been happily using MIT Expat for everything we open source and have not had any issues with it. Criticism, yes. Issues, no.
  - TuringTest 11y ago
    The whole justification for share-alike (as opposed to permissive) licensing is traced back to the UNIX wars, where uncertain copyright attribution was a huge hindrance to developers and a source of commercial wars battled through litigation. 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.
    - gsnedders 11y ago
      > 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).
jevgeni 11y ago
If you love it, public domain it.
- _puk 11y ago
  vs If you liked it, then you shoulda put a ring on it?
- yarrel 11y ago
  If you love its users, copyleft it.
  - jevgeni 11y ago
    So your users can't use it commercially?
pif 11y ago
> I'm speaking about free software aka open source After 25 years of experience, one would expect some acknowledgement of the difference between the two concepts.
- tbrownaw 11y ago
  "In theory, theory and practice are the same. In practice, they're not." 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. :)
  - vezzy-fnord 11y ago
    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. 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.
- bcg1 11y ago
  Pretty sure hintjens is on (y)our side, he did after all give "free software" top billing. The "aka" part seems like an acknowledgement that in 2015 many people see the distinction as an ancient battle that perhaps doesn't need to be fought in every commentary on free software, and perhaps also a way to be more inclusive of people who don't see a distinction at all or have any trouble reconciling the terms as synonyms
- jordigh 11y ago
  There isn't a difference other than emphasis. It refers to the same set of software, but describes this same set of software differently. It's like saying "African American" or "black". The intended meaning is the same set of people. Indeed, the term "open source" was coined as a marketing term for promoting free software: http://jordi.inversethought.com/blog/5-things-we-have-forgotten-about-open-source/ 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.
lighthawk 11y ago
"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.
jakobegger 11y ago
The title is very misleading. Yes, those ten rules may work well for one project. But they are not at all applicable in general. The Open Source world is way more heterogenous than that. 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.
davexunit 11y ago
Came here expecting all of the HN startup people to dismiss copyleft. Wasn't disappointed. 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.
barbs 11y ago
> "10. Be Happy and Pleasant" 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.
- cosarara97 11y ago
  Torvalds is mostly hostile to people responsible for important parts of the kernel who do Bad Things, eg. breaking userspace. Oh, and that one guy who called stupid his decision to use C instead of C++ for git.
  - barbs 11y ago
    I don't think that kind of hostility and deprecation is ever justified. The worst part is that he publicly defends his way of dealing with people online and sets a terrible example.
blainesch 11y ago
When did submodules become "fancy" ?
jsargiox 11y ago
Try to match these rules with the linux kernel project... you'll be surprised...

89 points by c-rack 11y ago

Lots of advice I disagree with here, testing coverage completely matters. It's not the most important thing, but it's very important. I stopped reading at "merge first, fix later". OUCH!

anarazel 11y ago
Yes, that made me cringe as well. 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.
- amirouche 11y ago
  This is his writing style, he does shortcuts to keep thing readable and you have sort out the real world constraints yourself. That said the book is readable but some arguments that are difficult to understand.
amirouche 11y ago
This must be understood in the light of the philosophy of Peter Hinjens which is the community comes always first, before technical assets. Smoothing community process and interactions is (very) necessary for a project success. 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] [1] http://cultureandempire.com/html/cande.html#toc-3 http://cultureandempire.com/html/cande.html#toc-3
PieterH 11y ago
It hurts a lot when your assumptions are challenged. The process we use in ZeroMQ is successful beyond all expectations. See http://hintjens.com/blog:93 http://hintjens.com/blog:93. 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.

stared 11y ago

I am totally for Open Source (and Open Science), but I dislike copyleft licenses (cf. "2. Use a Share-Alike License"). 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/ http://www.wtfpl.net/).

jobvandervoort 11y ago
I don't understand the reason the author mentioned that you should use such a license. Why do you have to, in their reasoning? We've been happily using MIT Expat for everything we open source and have not had any issues with it. Criticism, yes. Issues, no.
- TuringTest 11y ago
  The whole justification for share-alike (as opposed to permissive) licensing is traced back to the UNIX wars, where uncertain copyright attribution was a huge hindrance to developers and a source of commercial wars battled through litigation. 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.
  - gsnedders 11y ago
    > 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).

jevgeni 11y ago

If you love it, public domain it.

_puk 11y ago
vs If you liked it, then you shoulda put a ring on it?
yarrel 11y ago
If you love its users, copyleft it.
- jevgeni 11y ago
  So your users can't use it commercially?

pif 11y ago

> I'm speaking about free software aka open source After 25 years of experience, one would expect some acknowledgement of the difference between the two concepts.

tbrownaw 11y ago
"In theory, theory and practice are the same. In practice, they're not." 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. :)
- vezzy-fnord 11y ago
  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. 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.
bcg1 11y ago
Pretty sure hintjens is on (y)our side, he did after all give "free software" top billing. The "aka" part seems like an acknowledgement that in 2015 many people see the distinction as an ancient battle that perhaps doesn't need to be fought in every commentary on free software, and perhaps also a way to be more inclusive of people who don't see a distinction at all or have any trouble reconciling the terms as synonyms
jordigh 11y ago
There isn't a difference other than emphasis. It refers to the same set of software, but describes this same set of software differently. It's like saying "African American" or "black". The intended meaning is the same set of people. Indeed, the term "open source" was coined as a marketing term for promoting free software: http://jordi.inversethought.com/blog/5-things-we-have-forgotten-about-open-source/ 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.

lighthawk 11y ago

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

jakobegger 11y ago

The title is very misleading. Yes, those ten rules may work well for one project. But they are not at all applicable in general. The Open Source world is way more heterogenous than that. 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.

davexunit 11y ago

Came here expecting all of the HN startup people to dismiss copyleft. Wasn't disappointed. 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.

barbs 11y ago

> "10. Be Happy and Pleasant" 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.

cosarara97 11y ago
Torvalds is mostly hostile to people responsible for important parts of the kernel who do Bad Things, eg. breaking userspace. Oh, and that one guy who called stupid his decision to use C instead of C++ for git.
- barbs 11y ago
  I don't think that kind of hostility and deprecation is ever justified. The worst part is that he publicly defends his way of dealing with people online and sets a terrible example.

blainesch 11y ago

When did submodules become "fancy" ?

jsargiox 11y ago

Try to match these rules with the linux kernel project... you'll be surprised...