You mentionned RedHat Linux centric type corporations. There are a lot more businesses that are not Linux centric business wise. They use it but provide something else on top. Did you even read this article against your own statement ? :)
A huge number of occasional contributors were not reluctant to log a ticket and submit a patch instead of ranting about it. This is the main point you missed. That 'entry barrier' of yours does not stand with Linux. I would think hard about the reasons behind these numbers. There has to be some value added in the process of submitting patches. Luc P. On Sat, 18 Jul 2015 23:02:30 +0300 Bozhidar Batsov <bozhi...@batsov.com> wrote: > On 18 July 2015 at 22:52, Luc Préfontaine > <lprefonta...@softaddicts.ca> wrote: > > > Each linux kernel release involves hundreds of people. > > Many release had above a thousand contributors. > > This is for your enlightenment and are old figures: > > > > http://royal.pingdom.com/2012/04/16/linux-kernel-development-numbers/ > > > > Did you even read this article? "75% – The share of all kernel > development that is done by developers who are being paid for their > work." This doesn't exactly contract what I said. > > > > > > There are as many people not officially hired to work for linux > > operating system > > focused businesses that submit patches through the ticketing system. > > > > As for the development lifecycle of the linux kernel: > > http://www.linuxfoundation.org/content/22-lifecycle-patch > > > > You can read the other sections, if you find the Clojure dev. > > lifecycle arcane, you will > > freak at this one. > > Obviously, these guys must all be old fashion outdated folks in > > this era of instant > > communication and snapchat like media, there's no other explanation > > for such a > > bureaucratic process :) > > > > How much pain is it to upgrade to a new Clojure version ? Nil. > > How much pain is it to upgrade to a new linux kernel ? > > Not nil but considering the size of this project, its ramifications > > and the hardware > > changing every 6 months, not big. On par with Clojure I would say. > > > > How much pain to upgrade to a new version of Ruby on Rails ? > > Huge. I know, I have been through this a number of times. Not just > > major releases, even maintenance ones are a nightmare to upgrade. > > > > Disclaimer: I am not saying that Rails has a bad lifecycle, I am > > just stating feedback > > from me and other people that actually lived this. Gee, I sound like > > Mallard Fillmore... > > > > That's for the political correctness of this post. And to avoid > > being harassed, sued, whatever. > > > > I would like us to compare carrots with carrots, not with apples or > > strawberries but if > > you insist.... > > > > To me the result is utterly important. > > We deliver 24/7 software under linux using Clojure. We have up > > times of more than 300 days. One upgrade a year. This is the world > > that live into. > > > > Making it 'harder to contribute' like you state is the price to pay > > for some form of > > quality control. Contributing to something that eventually crumbles > > because of a > > lack of QA is of no value. To us all. > > > > Stuart has made this evaluation. Since it models by some aspect how > > a successful > > project like Linux is managed, I find it hard to throw a stone at > > the current lifecycle. > > > > That may look to you as an ultra-conservative approach. Let's put > > it this way, > > I would use Linux and Clojure to control a nuclear plant anytime. > > > > I am quite certain sure I would not use Rails or Ruby for this > > purpose. > > > > As this conversation isn't really going anywhere I'll keep my > thoughts to myself. > > > > > > Luc P. > > > > > > Luc P. > > > > Sent from my iPad > > > > On Jul 18, 2015, at 14:32, Bozhidar Batsov <bozhi...@batsov.com> > > wrote: > > > > On 18 July 2015 at 20:18, Luc Prefontaine > > <lprefonta...@softaddicts.ca> wrote: > > > >> Aaah ! The pull request looms again :) > >> > >> A bug tracking system is essentialy to coordinate efforts, pull > >> request are not a mechanism to track fixes/improvements and > >> discuss about them. That may work for a very small team. The # of > >> clojure contributors far excess that size. > >> > > > > So, Ruby on Rails is a small project, right? And if we have many > > contributors we should show no respect for their time - we should > > actually make it harder to contribute, so it'd be easier on us, > > right? > > > > > >> > >> Pull requests/gitbhub issues are used by Clojure library > >> maintainers outside of the core, > >> their respective contributor team size makes this usable. > >> > >> Choosing one tracking system is a feat by itself, Jira does > >> everything albeit it may be a beast to configure. > >> I think that the choice of Jira predates moving the Clojure code > >> from google to github but I may be wrong. > >> The github tracking system was not at par with Jira features at > >> that time anyway. > >> > > > > Many projects predate GitHub, yet they eventually adopted it. And > > it's never about GitHub in particular - it's only about making > > things efficient and pleasant for everyone involved. I work with > > JIRA for a living and my team mostly hates it, I can only imagine > > the willingness of casual contributors to deal with it. How do you > > do an inline patch review in JIRA? How do you update patches > > automatically? It's never about particular tools, it's all about > > making smart choices. > > > > > >> > >> Once that choice is done, moving out to something else requires a > >> significant effort, you need to pull all this history you built > >> about your software into your new bug tracking solution. You can't > >> loose this, it's your software collective memory. > >> > >> All this discussion around pull request IMO is more an expression > >> of human lazyness. Having to document is always seen as a > >> chore by most developpers. This is not an arcane human trait, it > >> has been known for decades. > >> > > > > Laziness? Time is our most important resource and we should always > > be mindful of the time people have to invest (waste) to contribute > > to our projects. For me lowering the bar to entry is the same as > > respecting the time of the person on the other end of the > > ticket/patch/whatever. If you take a look at my profile on GitHub > > you'll see I maintain a few projects and I go to great lengths to > > make sure all the projects are inviting and it's easy for people to > > start a conversation or pitch in. This pays off big time in the > > long run. > > > > > >> > >> Anything else requires a discussion forum if you want to maintain a > >> minimal level of quality and allow some discussions around the > >> issue being fixed > >> in a large team effort/critical piece of software. A mailing list > >> is not at par with a bug tracking system in this regard. > >> > >> Curiously, linux has a bug tracking system and people submit > >> patches or links are made to patches. > >> Take a walk on launchpad. > >> > > > > Curiously, most of the people who work on Linux are on the payroll > > of a corporation like Red Hat. If I was getting paid to do > > something, I'd definitely be more willing to through more hurdles - > > after all that's part of my job, right? > > > > > >> > >> No serious software business would drive their dev without a > >> tracking system. Open source projects are no > >> different if they want to attain some level of success. If > >> critical open source is to be used by businesses, it has to > >> play with similar tools. Clojure too me is critical to my business > >> and to many others. It cannot fail on us. > >> It would be like building pyramids on moving sand. > >> > >> Again there's no Kumbaya song playing here. > >> > >> As a last note, Alex Miller must dream about the emails exchanged > >> on the mailing list. > >> Suggestions are certainly looked upon and discussed upstream. It > >> does not mean that they will be considered > >> worth to investigate/implement or they may come out differently > >> (that ego thing looming again). > >> > > > > Alex is an amazing fellow, there's no denying this. I only wish we > > could clone him somehow. :-) > > > > > >> > >> +1 for Jira and patches. > >> > >> Luc P. > >> > >> > >> > >> On Sat, 18 Jul 2015 19:05:16 +0300 > >> Andrey Antukh <n...@niwi.nz> wrote: > >> > >> > On Sat, Jul 18, 2015 at 6:48 PM, Colin Yates > >> > <colin.ya...@gmail.com> wrote: > >> > > >> > > +1 (although I maybe wouldn’t be so mocking in my tone ;-). > >> > > Since when did software design by committee work; anyone > >> > > remember J2EE? (and yes, that does deserve my mocking tone). > >> > > > >> > > I have no idea about the details being discussed here/why > >> > > people’s noses are out of joint, but I can think of as many > >> > > success with a single overlord in place as there are failures > >> > > caused by political infighting. > >> > > > >> > > >> > In general, I'm pretty happy with the "benevolent dictator" > >> > approach. But some openness would be awesome. As first think > >> > that comes in my mind is: have a clear roadmap for Clojure and > >> > its core libraries such as core.async. > >> > > >> > Some channel for requesting features, and the ability to know a > >> > opinion of the clojure core team about the possibility of the > >> > inclusion of some requested feature. > >> > > >> > Also would be awesome have more painless contribution process. > >> > I'm ok for signing CA, but using patches instead of something > >> > like pull requests (with or without additional review tool) is > >> > very arcane and uncomfortable process. > >> > > >> > I don't suggest to change to something similar to "design by > >> > committee". I only suggest that make some facilities for > >> > contribute may attract more interesting people. And will make > >> > more happy excellent contributors like Zach Tellman or Aphyr. > >> > > >> > I think that things like this are not very complicated to adopt > >> > and has a lot of benefit. > >> > > >> > My two cents! > >> > > >> > > > >> > > On 18 Jul 2015, at 16:44, Luc Prefontaine > >> > > <lprefonta...@softaddicts.ca> wrote: > >> > > > >> > > Sure, indentation is what gets the code running on metal :)) > >> > > > >> > > Not ranting here, just my abs dying from the pain as I > >> > > laugh :)) > >> > > > >> > > As for the contrib process, go have a look at Linux. You'll be > >> > > happy that Rich is cool by every meaning of the word. > >> > > > >> > > There's this misconception about open source that we should > >> > > all wear flower collars and sing Kumbaya. Mostly a 60's view > >> > > of human collaboration. > >> > > > >> > > That ain't the way to get it done. > >> > > It works for ants and termites, they work as groups but we are > >> > > human beings with our strong individuality. > >> > > > >> > > Some form of central control is needed. Opposed by traction > >> > > from some individuals that would like to move faster or in > >> > > other directions. > >> > > > >> > > This is ok but not at the expense of the cohesion of the end > >> > > result. > >> > > > >> > > Hence this tensed balance. > >> > > > >> > > Rich created Clojure, he knows were he wants to go with it. Any > >> > > ideas we bring in the process is evaluated. However not all of > >> > > them make sense or are worth the effort to implement. > >> > > > >> > > Aside from our respective ego being hurt because our ideas are > >> > > not retained or our contribs vetted in the first pass there's > >> > > little damage done. > >> > > > >> > > If it was not the case Clojure would have zero traction and > >> > > Linux likewise. Search for Linus rants about contributors and > >> > > try to relate this with the level of success of Linux. > >> > > > >> > > They are not so many open source projects that have the same > >> > > stability from release to release as Clojure or Linux. > >> > > > >> > > Control and absence of complacency are key factors to achieve > >> > > this kind of success. > >> > > > >> > > Luc P. > >> > > > >> > > Sent from my iPhone > >> > > > >> > > On Jul 18, 2015, at 07:13, Andrey Antukh <n...@niwi.nz> wrote: > >> > > > >> > > Hi! > >> > > > >> > > I have some, maybe controversial, questions... > >> > > > >> > > A little bit of context: > >> > > https://twitter.com/aphyr/status/621806683908542464 > >> > > > >> > > Why this is like a normal approach for managing third party > >> > > contributions to clojure core? This kind of things the only > >> > > discourages the contributions. Maybe I don't have more context > >> > > about this concrete case, but seems is not a unique. > >> > > And in general, I have the perception that the clojure > >> > > development process is a little bit opaque... > >> > > > >> > > An other question: Why the great amount of clojure compiler > >> > > code has no indentation style and bunch of commented code. > >> > > > >> > > It is indented like a freshman. Sorry, I don't want offend any > >> > > one, but eyes hurt when reading the code compiler clojure > >> > > (obviously I'm speaking about the look and feel, and no the > >> > > quality of the code). > >> > > > >> > > Some examples: > >> > > > >> > > Indentation (or maybe no indentation): > >> > > > >> > > > >> https://github.com/clojure/clojure/blob/36d665793b43f62cfd22354aced4c6892088abd6/src/jvm/clojure/lang/APersistentVector.java#L86 > >> > > > >> > > Bunch of commented code and also no indentation: > >> > > > >> > > > >> https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/AMapEntry.java#L60 > >> > > > >> > > If you compare some clojure compiler code with different code > >> > > snippets from other languages, the indentation is clearly more > >> > > cared: > >> > > > >> > > Kotlin: > >> > > > >> https://github.com/JetBrains/kotlin/blob/master/core/descriptors/src/org/jetbrains/kotlin/types/AbstractClassTypeConstructor.java#L44 > >> > > Rust: > >> > > > >> https://github.com/rust-lang/rust/blob/master/src/libstd/io/buffered.rs#L165 > >> > > Ceylon: > >> > > > >> https://github.com/ceylon/ceylon-compiler/blob/master/src/com/redhat/ceylon/compiler/java/codegen/AttributeDefinitionBuilder.java#L233 > >> > > > >> > > This is a random list of code snippets from different > >> > > compilers with indentation that is more human friendly. > >> > > > >> > > I don't intend judge any one, but when a I learn Clojure > >> > > compiler I expect something different. I expect something more > >> > > carefully done. > >> > > > >> > > No body thinks the same thing that me? > >> > > > >> > > I think that have a sane, more open contribution policy, with > >> > > clear and more cared code formatting, is not very complicated > >> > > thing and is going to favor the clojure and its community. > >> > > > >> > > Andrey > >> > > -- > >> > > Andrey Antukh - Андрей Антух - <n...@niwi.nz> > >> > > http://www.niwi.nz > >> > > https://github.com/niwinz > >> > > > >> > > -- > >> > > You received this message because you are subscribed to the > >> > > Google Groups "Clojure" group. > >> > > To post to this group, send email to clojure@googlegroups.com > >> > > Note that posts from new members are moderated - please be > >> > > patient with your first post. > >> > > To unsubscribe from this group, send email to > >> > > clojure+unsubscr...@googlegroups.com > >> > > For more options, visit this group at > >> > > http://groups.google.com/group/clojure?hl=en > >> > > --- > >> > > You received this message because you are subscribed to the > >> > > Google Groups "Clojure" group. > >> > > To unsubscribe from this group and stop receiving emails from > >> > > it, send an email to clojure+unsubscr...@googlegroups.com. > >> > > For more options, visit https://groups.google.com/d/optout. > >> > > > >> > > > >> > > -- > >> > > You received this message because you are subscribed to the > >> > > Google Groups "Clojure" group. > >> > > To post to this group, send email to clojure@googlegroups.com > >> > > Note that posts from new members are moderated - please be > >> > > patient with your first post. > >> > > To unsubscribe from this group, send email to > >> > > clojure+unsubscr...@googlegroups.com > >> > > For more options, visit this group at > >> > > http://groups.google.com/group/clojure?hl=en > >> > > --- > >> > > You received this message because you are subscribed to the > >> > > Google Groups "Clojure" group. > >> > > To unsubscribe from this group and stop receiving emails from > >> > > it, send an email to clojure+unsubscr...@googlegroups.com. > >> > > For more options, visit https://groups.google.com/d/optout. > >> > > > >> > > > >> > > -- > >> > > You received this message because you are subscribed to the > >> > > Google Groups "Clojure" group. > >> > > To post to this group, send email to clojure@googlegroups.com > >> > > Note that posts from new members are moderated - please be > >> > > patient with your first post. > >> > > To unsubscribe from this group, send email to > >> > > clojure+unsubscr...@googlegroups.com > >> > > For more options, visit this group at > >> > > http://groups.google.com/group/clojure?hl=en > >> > > --- > >> > > You received this message because you are subscribed to the > >> > > Google Groups "Clojure" group. > >> > > To unsubscribe from this group and stop receiving emails from > >> > > it, send an email to clojure+unsubscr...@googlegroups.com. > >> > > For more options, visit https://groups.google.com/d/optout. > >> > > > >> > > >> > > >> > > >> > >> > >> > >> -- > >> Luc Préfontaine > >> > >> SoftAddicts inc. > >> Québec, Canada > >> Mobil: +1 (514) 993-0320 > >> Fax: +1 (514) 800-2017 > >> > >> Rabat, Maroc > >> Mobil: +1 212 6 98 00 64 47 > >> > >> > >> -- > >> You received this message because you are subscribed to the Google > >> Groups "Clojure" group. > >> To post to this group, send email to clojure@googlegroups.com > >> Note that posts from new members are moderated - please be patient > >> with your first post. > >> To unsubscribe from this group, send email to > >> clojure+unsubscr...@googlegroups.com > >> For more options, visit this group at > >> http://groups.google.com/group/clojure?hl=en > >> --- > >> You received this message because you are subscribed to the Google > >> Groups "Clojure" group. > >> To unsubscribe from this group and stop receiving emails from it, > >> send an email to clojure+unsubscr...@googlegroups.com. > >> For more options, visit https://groups.google.com/d/optout. > >> > > > > -- > > You received this message because you are subscribed to the Google > > Groups "Clojure" group. > > To post to this group, send email to clojure@googlegroups.com > > Note that posts from new members are moderated - please be patient > > with your first post. > > To unsubscribe from this group, send email to > > clojure+unsubscr...@googlegroups.com > > For more options, visit this group at > > http://groups.google.com/group/clojure?hl=en > > --- > > You received this message because you are subscribed to the Google > > Groups "Clojure" group. > > To unsubscribe from this group and stop receiving emails from it, > > send an email to clojure+unsubscr...@googlegroups.com. > > For more options, visit https://groups.google.com/d/optout. > > > > -- > > You received this message because you are subscribed to the Google > > Groups "Clojure" group. > > To post to this group, send email to clojure@googlegroups.com > > Note that posts from new members are moderated - please be patient > > with your first post. > > To unsubscribe from this group, send email to > > clojure+unsubscr...@googlegroups.com > > For more options, visit this group at > > http://groups.google.com/group/clojure?hl=en > > --- > > You received this message because you are subscribed to the Google > > Groups "Clojure" group. > > To unsubscribe from this group and stop receiving emails from it, > > send an email to clojure+unsubscr...@googlegroups.com. > > > > For more options, visit https://groups.google.com/d/optout. > > > -- Luc Préfontaine SoftAddicts inc. Québec, Canada Mobil: +1 (514) 993-0320 Fax: +1 (514) 800-2017 Rabat, Maroc Mobil: +1 212 6 98 00 64 47 -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
