Giving up on Ruby packaging

I have finally reached a decision regarding my involvement in the Debian Ruby packaging efforts. I have decided to stop. This has been a very hard decision to make. I have invested huge amounts of time in that work over the years. I still love the language, and will continue to use it on a daily basis for my own developments. I still hope that it will succeed. I know that some people will be disappointed by that decision (and that others will think “your work was useless anyway, people should use RVM and rubygems”).

But I also know that I won’t be able to push for all the required changes alone. I just don’t have the time, nor the motivation. For the record, here are the changes I would have liked to see in the Ruby community.

The core Ruby development community should mature.
The core Ruby development community is still dominated by Japanese developers. While not a bad thing in itself, it is easily explained by the fact that the main development mailing list, where most of the important decisions are taken, is in japanese. ruby-dev@ should be closed, and all the technical discussions should happen on the english-speaking ruby-core@ list instead.

The release management process should also improve. Currently, it looks like a total mess. The following Ruby development branches are actively maintained:
ruby_1_8 (106 commits over the last six months)
ruby_1_8_6 (4 commits over the last six months)
ruby_1_8_7 (35 commits over the last six months)
ruby_1_9_1 (4 commits over the last six months)
ruby_1_9_2 (227 commits over the last six months)
trunk (1543 commits over the last six months)

While the state of the ruby_1_8_6 and ruby_1_9_1 branches is clear (very important bugfixes only), the state of all of the other branches is rather unclear.
What’s the stable Ruby branch? 1.8 or 1.9? If it’s 1.9, why are people still actively developing in the ruby_1_8 branch? How long will they continue to be maintained in parallel, dividing the manpower? Is a Ruby 1.8.8 release to be expected? Will it be ABI/API compatible with 1.8.7? Is the ruby_1_8_7 branch really bugfixes-only? How much testing of it has been done? If it’s bugfixes-only and regression-free, I should push it to Debian squeeze, due to be released in a few weeks. But would you recommend that? Due to past breakages in the ruby_1_8_7 branch, it’s unlikely that we will do it.
Is the ruby_1_9_2 a regression-free, bugfix-only branch? If yes, isn’t 227 commits over 6 months a lot? What will be the version of the next release of “trunk”? When is it expected? Will it be ABI-compatible with the current ruby_1_9_2 branch? API-compatible?
New releases in the 1.8.7 and 1.9.2 branches were done on december 25th. Why were they no betas or RCs allowing wider testing? How much testing has been done behind the scenes?

Most of those questions have no clear answer. The Ruby development community should build a common understanding of the status of the various branches, and of their release expectations. Releasing on december 25th of each year sounds fun, but is releasing when everybody is on vacation really a good idea?

It would be fantastic to have something similar to Python Enhancement Proposals in the Ruby community. But having open discussions in english about the major issues would already be great.

Ruby is not just the interpreter.
The Ruby development community should clearly define what the Ruby platform is. There are some big players, like Rails, and newer interpreter releases should not be done before ensuring that those big players still work.

Also, since we have alternative Ruby interpreters, like JRuby, Rubinius and MacRuby, we need a clear process on how they integrate with the rest of the ecosystem. For example, having each of them rely on their own outdated fork of the whole stdlib is ridiculous, since it’s not where they compete.

The Ruby community should acknowledge that RVM and Rubygems are not for everybody. People who say so should be laughed at. Of course, RVM and Rubygems are nice tools for some people. But it is completely wrong to believe that compiling from source using RVM should be the standard way of installing Ruby, or that all people interested in installing Redmine should know that Ruby has its own specific packaging system. The Ruby community should work with their target platforms to improve how Ruby is distributed instead of reinventing the wheel. That includes Debian, but also RedHat-based distros, for example. It is likely that it won’t be possible to reach a one-size-fits-all situation. But that’s real life.

Some people in the Ruby community should stop behaving like assholes. As one of the Debian Ruby maintainers, I have been routinely accused of creating crippled packages on purpose (FTR, I don’t think that the Debian packages are crippled, despite what the rumors says). Debian is not the only target of that. Just yesterday, someone called for abandonning YARV (the new Ruby VM in Ruby 1.9), calling it Yet Another Random Vailure. This kind of comments is really hurting the people who are investing their free time in Ruby, and is turning away people who consider getting involved. In Debian, we have had a lot of problems getting people to help with Ruby maintenance since they are getting shit from the community all the time.

So, what’s the future for Ruby in Debian?

  • For the interpreter, the two other maintainers, Akira Yamada and Daigo Moriwaki, are of course free to continue their work, and I wish them good luck.
  • For the pkg-ruby-extras team, which maintains most of the Ruby libraries and applications, the future is less clear. The team was already badly understaffed, and I feel that I should probably clean up its status by orphaning/removing the packages that are unmaintained otherwise. This won’t affect all the packages that the team maintains: some packages (like redmine) are actively maintained, and will stay.
  • For me, it just means I will have more time for other things (possibly not Free Software-related). If things improve dramatically, I might also come back to Ruby packaging at some point.

Update: there’s also a number of interesting comments about this post on this site.
Update 2: First, thanks a lot for all the interesting comments. I will make some follow-up posts trying to summarize what was said. It seems that this post also triggered some reactions on ruby-core@, with Charles Olivier explaining the JRuby stdlib fork, and Yui Naruse clarifying that all questions are welcomed on ruby-core@. This is great, really.

82 thoughts on “Giving up on Ruby packaging

  1. “ruby-dev@ should be closed, and all the technical discussions should happen on the english-speaking ruby-core@ list instead.”

    Imperialists never change.

  2. This is not about imperialism. This is about finding methods that doesn’t force some contributors to stay second-class contributors. English is not my native language either (I’m french), but I’m very fine with using english where it is necessary to allow collaboration. At some point, one need to decide whether the project should stay a little project between friends, or if it should open up to the wider world. You can’t have it both ways.
    Another example of a similar problem is with VCSes. There are some projects that insist on using a specific, rather unknown VCS (for example, monotone, mercurial, darcs). This is an additional entry barrier for potential contributors, though it’s probably less severe for software developers to say “you have to learn $VCS” than to say “you have to learn japanese”.

  3. @FFms: what makes you think Lucas is a native English speaker? Like it or not, having ruby-dev in japanese is excluding a large number of developers – I’m willing to bet there’s way more potential ruby developers that don’t speak Japanese, than those who don’t speak English.

    @Lucas: sad to read this. I had hoped that Ruby in Debian (and other distros) would improve Ruby; I don’t get why there was so much pushback. I think the Ruby developers forget there’s users out there too. (Building from source isn’t an appropriate install experience for users, no matter how “easy” it might be).

  4. Thank you Lucas for taking such a hard decision. It isn’t easy to give up on something when you have invested so much time.

    Now I wonder, which of your reasons do also apply for PHP? :-)

  5. Surprised you held on this long. I would’ve given up years ago. Dunno if mercurial is considered niche though..?

  6. Also English is the lingua franca (as it were) of technical discussion. There’s a reason Torvalds never even considered writing the kernel in Finnish. You get the most possible contributors if you write in English.

  7. @anonymous: mercurial is not niche is some communities, like Python. But if you write something not related to Python, it’s probably not a good idea to use mercurial if attracting contributors is one of your goals.

  8. For what it worth, I have just removed RVM this week end and installed Ubuntu package instead, and it works perfectly. Thanks for your work Lucas.

  9. Sample from my life, few years ago I have written a couple of scripts and then publish them. I just thought that maybe there is someone that would like to execute the same code as I have written. I have used my own native language (non-English) for variables and I just ignored all the comments in code (I thought, who needs comments). I thought they are excellent scripts working like a charm, I was very proud of my code. I received comment or two from local language community, but one of them purposed to change all non-English variables/comments to English language and I checked his work for consistency and program was working fine. I immediately got wider community around code. A lot of testers got reported tens of bugs in some situations that I have never thought about. I start getting patches, for users using older versions of Ubuntu that this scripts were not working, I also got suggestions from non-Ubuntu distributions and got a patches for them and how to write a script code multi-distribution working etc. Got some requests to add features and from other users got a code for that. I never expected to get such a response just from changing non-English to English. What is the best is? I invested huge time to get first version. But invested so little time to get all others versions, a lot of code maintained by others, learned so much more about how to write good code etc. Now I know what a great power is free software and what a power is if lingua franca is used.

  10. Sorry to hear this, your work is much appreciated. I also don’t bother with RVM, most people just want the stable version.

  11. Imperialist or not is beside the point. Most core contributors are Japanese and for most of them their English ranges from bad to nonexistent. If you were to insist on English as the development language you would completely shut out many of the current developers.

  12. The funny thing is that ruby, java, python, ALL LANGUAGES are written using “English”. Good developers typically know English pretty well and that goes for not only Japanese developers, world wide. Assuming the core contributors can’t speak English is lame… Sorry to see you leave @lucas.

  13. @Janne: you seem to assume that I’d like developers to write correct english. Honestly, I don’t care if the english is grammatically correct or not. The point is to understand each other, not to write a novel. I know that it is harder to write in a foreign language (it’s harder for me to write in english than in french). But that’s an effort that most serious projects have been making.

    Also, I’d like to point out that the language issue is not my main problem with Ruby. I’m quite sure that, even if I knew japanese, most of the other issues would still apply.

  14. Lucas,
    First of all, I say “thank you” for your working overtime for ruby on Debian.

    What is the source of the this blog article?

    My knowledge about discussion for ruby on Debian is limited, which came from some ruby related package maintainer in Debian.
    I think Lucas, Akira and Daigo’s direction of ruby on Debian are in perfect harmony.

  15. “Honestly, I don’t care if the english is grammatically correct or not. The point is to understand each other, not to write a novel. I know that it is harder to write in a foreign language (it’s harder for me to write in english than in french). But that’s an effort that most serious projects have been making.”

    Lucas, my experience with Japanese software developers and engineering-oriented academics is that they don’t do English at all. As in, how well does your typical American or British software engineer do French or German?

    The typical developer is somebody who, after all, excelled in school doing math, science and programming, not studying foreign languages (or history, or social science or home economics). There’s lots of Japanese with good foreign language skills of course. There’s lots with great software expertise. But the intersection is fairly small.

    Software people from small language areas like the Scandinavian countries tend to do English well. They don’t have the luxury of translations so they all have to come to grips with foreign languages or give up their profession.

    But people in a large country like Japan can count on having most foreign stuff translated outright (I believe most or all of O’Reilly’s entire catalogue is available in Japanese) and having lots of good original works appearing for every conceivable subject.

    If you are a Japanese software developer then no, you really do not need English. And if you’re going to learn a second language professionally you may well elect to start on Mandarin instead.

  16. While I agree on the core Ruby interpreter and the ess of the various branches (and more importantly what gets committed in each!) and I’ve said it several times on ruby-talk, I will strongly object to the Rubygems comment.

    Ruby being a language for several platforms, each with its specific packaging systems, all incompatibles between Debian, FreeBSD, Redhat and others, need Rubygems. It works rather well across all platforms and I think it is easier than to shoehorn gems into the Debian system (even if FreeBSD has managed to get gems registered in both the system and gems).

    Thanks for your work (even though I do not use Debian nor agrees with the way the Ruby ecosystem is managed in Debian…).

  17. Decided you can’t compete against RVM and decided to give up with a useless rant. Thank you. You made my day.

    Since RVM came out I have never bothered to use your stuff. Even in production I use RVM which is quite production ready (with gitpusshuten gem)

  18. @Seivan: wow, well done for proving at least one of Lucas’ points right by being so obnoxious.

    These are all really difficult problems, exacerbated by the sheer speed of releases in the Ruby environment versus Debian’s slow and measured approach. Both of which have problems!

    I think a hybrid is always going to be the solution. I still use the stock interpreter from Debian but am thinking of switching to RVM even though I hate locally compiled stuff.

    Thanks for your work Lucas.

  19. @Seivan: glad to see you playing rvm and rubygems in production environments, may be you have time and money for that. Who care ?

    Many thanks for your work Lucas, I wish you a happy new year!
    Hope the situation will evolve in a more mature way too.

  20. The entire point of RVM is to manage multiple Ruby installations. As well as keep clean Gemsets. As a developer this makes it very easy for me to test against multiple versions and branches. In a deployment scheme I no longer have to limit my production box to a single copy of Ruby. To my knowledge Ubuntu’s package system does not provide this functionality.

    Comparing RVM to the Ubuntu package is not a fair argument. If you’re only using RVM to install Ruby then you’re doing it wrong.

  21. Reliable repeatability is essential to successful development of large and complex systems. The best tool stacks allow us to automate build, test and deployment on top of components with mature development processes. When we finish we need to be able to leave things in a maintainable state, for they will be maintained for years, decades, by people who did not build the thing and are not of the same mindset.

    It appears the Ruby community has some maturing to do. The last few years have shown the great promise of Ruby for broader adoption, now the question is can it be delivered.

  22. If Ruby developers don’t know english, why ruby language is like “if tlah then mlah end” when it could be like “tlahしmlah末尾の場合”?

    I agree with all your comments to Ruby. I came to Ruby from PHP but I don’t know which core developers are worse and more arrogant.

  23. In a deployment scheme I no longer have to limit my production box to a single copy of Ruby. To my knowledge Ubuntu’s package system does not provide this functionality.

    @Brian Cardarella see Debian Alternatives

  24. @Andris: Note that Debian’s Ruby doesn’t use alternatives at the moment. The main problem is that alternatives are for software that provide very similar functionality, and can be used interchangeably. That’s not the case: you cannot use ruby 1.9 instead of ruby 1.8 and expect that all your (Debian packaged-)applications will still work.

  25. Lucas, I think Debian’s mission flies in the face of Ruby’s mission at this time. You can’t have both stability and rapid development; you can’t have both a reference implementation and documented stable API; you can’t have a relatively closed group of Japanese developers vs a relatively open group of Debian users world wide. I am not passing judgement on any side: we have to acknowledge that Ruby has strong Japanese roots; and that has both strengths and weaknesses. In my opinion, the BEST thing you could do is throw in the towel and not package Ruby with Debian *at all*. This way it’s up to everyone to install their own Ruby. I know for a face that most developers and admins do this anyway. By not wasting your valuable time re-packaging every Ruby out there, you are making it clear that Ruby is just not stable enough to be included with Debian. To me that sends the perfect message. I am more than happy to run a ./configure && make && sudo make install, in fact prefer it immensely over the system-packaged Ruby. Maybe in a few year’s time the situation will have stabilized and you can rethink packacking it all up. In the mean time I really think nobody will blame you for just getting out of harms way.

  26. while I really don’t think users should be building their rubies and gems with native extensions, I do feel there’s a mismatch in what dpkg can offer and ruby & gems need.

    dpkg doesn’t allow to install different versions of the same package, which is something that is probably more or less required for different ruby applications. So mapping gems to debian packages is difficult, without complex naming schemes and a lot of effort.

    maybe in the (very) long term debian should think about enabling dpkg to allow parallel installation of multiple versions of the same package, just like how Nix or NixOS do, at which point more or less automatic conversions from gem to deb would be possible (with a bit of cooperation on the gem side too)?

  27. To bad to hear this, Lucas.

    I think the comment on Y Combinator about the perspective of a system administrator vs the perspective of a developper was spot on.

    These issues are not just about Ruby, they are about Python, LUA, Haskell and Perl as well.

    However, it mostly affects interpreted languages. For languages that produce binaries, the production requirements are different from the development requirements.Also, in thpse cases, you can always opt-in to statically link unsupported libraries.

    For interpreted languages, it is quite crucial that these environments are very similar. Then comes the discussion who gets to decide the platform: the developer or the system administrator.

    What you see, is that PHP is so common, that people use shared hosting, and the system administrators rule the platform choices. For Rails, there are much less options out there, so developers tend to run their own VPS per application or something.

    I don’t think anybody had the right to mean to you. And i’m sorry if people were. But i was never going to use the distro provided ruby packages.

    We need to make sure that the ruby environment is the same on OS-X, Windows and Linux. That’s the highest priority, and we pick a distro for production to suit that goal. The developers are free to choose a distrobution or OS that suits their needs.

    Perhaps the best strategy for debian, is to embrace upstream and separate the needs of developers from those of system administrators.

    The debian philosophy makes a lot of sense in the context of desktop applications: providing a consistent user experience. But it’s counter productive for developpers.

    We don’t write rails applications that target a specific version of Debian. Nobody is ever going to do that.

    If the applications we were writing would be opensource applications, that would be included in Debian, it would make sense to lock us into the versions and libraries and patches of Debian. But we’re not distrobuting our application as a debian-package.

    And I think the Debian philosphy needs to change. (but without all the hate please). Just separate the needs of the developer from the system administrator.

    What would be perfect is there would be simple script to install ruby/rubygems/rvm from upstream. And to have packages that are debian-ruby-version. That version is used for other debian packages dependent on Ruby. Like puppet, or Diakonos.

  28. Applications must not require different versions of the same gem (unless major number change). If it is required for Ruby applications those gems are not mature enough to be used.

  29. @Janne:
    In order to become a good programmer, you need some sort of tech-english. It is as simple as that. As for your small-countries argument: Do you seriously think that Germany is smaller than Japan or has less of a language tradition? Nevertheless EVERY german programmer worth his/her salt knows some sort of pidgin-english.

  30. Hi Lucas, I’m really sorry to hear about it – I think the hardest thing must have been trying to apply (or even adequately communicate) the rigid goals that Debian adhere to onto the general swamp of Ruby development.

    We took a compromise route at Bytemark and have a (not very well publicised, because we’re not trying to serve anyone else – yet ) apt-ruby.bytemark.co.uk server which serves lots of auto-converted gems as Debian packages. rubygems is gone from our production environments; we think gems are anathema to a stable system, and happily live without it. I’ve even got a bridge library that turns gem gymnastics into no-ops, and run Rails on top of it.

    I agree with Joost, Debian doesn’t need stale packages and if you’re not sure your colleagues are willing to fill the breach, it might be more sensible to remove them. Is there anyone at Ubuntu who is working on Ruby packaging? I do find a few useful ones in their ‘multiverse’ repository but I’m not sure of the discipline behind it.

    We’ll carry on building our own server which currently backs onto Debian/lenny and Ubuntu/karmic, and I’ll see whether there’s anything we can offer. The system we’ve built tries to do the job automatically but helps us to build patches to send upstream to remove some of the really heinous stuff that gem authors like to do – relative path references, mixed up namespaces and so on.

    We’ll certainly be talking about this development next week when we get back to work – good luck with refocussing your efforts.

  31. @Lucas, thanks for the awesome work! We’ll miss it a lot. It is and will continue to be as necessary as python, lua, … packages. Hope someone gets it soon and that s/he do it as well as you did all this time.

    Comparing RVM to the Ubuntu package is not a fair argument. If you’re only using RVM to install Ruby then you’re doing it wrong.

    @Brian Cardarella If you’re only using RVM to install Ruby then you’re doing it wrong [2]. Absolutely right.

    @Seivan .deb packages are more than necessary in Debian-based systems. If there not available, users of ruby-based applications would never install them, due to dependency problems.

    @Lucas I’m afraid @Janne has a point when talking about the core development. You both have a good view of it. My recent attempt to get some patches into the core can show your correct views.

    I was one of the guys that have participated on Rubysoc last year, and I’ve been thinking of how to make my patches go to the core for a long time, wondering what I’d have to do to get my patches there. One day, I’ve met @tenderlove at rubyconfBR, and he gave me a lot of awesome tips on how I’d have to evolve my code to get to the core, and specially, what it’d be necessary to make it into the core: someone from inside the core community, that could speak both english and japanese, would have to give a help.

    It’s true that keeping all the communication in Japanese, potential non-Japanese commiters are being lost. On the other hand, doing it all in Japanese would kick most of the core developers off the community.

    An intermediate solution, ruby-core, exist. And that’s good. But it could (and should) be way better. I don’t think that transferring all the talk to ruby-core would be good at all. But it should receive much more attention.

  32. @Lucas: Thanks for all your hard work. I hope things change enough for you to want to return to the scene soon. Ruby is a great language, but it is frustrating trying to keep things up to date. Anyone who claims you don’t need deb packages have not tried to keep applications working across multiple machines for years at a time. Good luck!

  33. Lucas – thanks for all your work. Your decision is unfortunate for the rest of us, but understandable.

    I’ve long used the Debian packages for ruby and rubygems and still prefer them to RVM.

    As I just said over on HN, there are a multitude of cultural differences between the Debian and the Ruby communities that gives the ruby packaging team a particularly challenging job. Your efforts to bridge the two communities were selfless.

    In the end, I guess something had to give.

  34. I always post ruby-core rather than ruby-dev. However, I sometimes need to post it to ruby-dev in Japanese because some of core committers tend to overlook a mail in ruby-core. I agree the benefit of closing ruby-dev, however, it will make us loose win32/64 support, rational, complex, date, openssl, druby, REXML and irb. That’s why I hav e not proposed to close ruby-dev and I continue to sometimes post to ruby-dev.

    To keep Ruby maintained, I need contributions to the libraries from ruby-core before closing ruby-dev. But it might be a problem about egg and chicken.

  35. Sorry to hear you got so much Hate. I think its the few rotten apples that are the spewers, but that does not reduce the pain….

    The language issue is a problem. The only human language I know is English. I’m glad/spoiled that its generally the lingua franca of the Internet. But I’m wondering what’s going to happen when there are way more Chinese speakers/writers than English on the Internet. There are already 400+ Million Chinese on the Internet and growing. There are also a lot of Chinese tech folks and growing…. And most of them don’t know English and have no need to learn it. And we can expect a lot of Open Source software to come from China as well…

    Hopefully translation tools will get much better :-)

  36. Although I respect your decision, I think some of your problems could have been improved (or resolved) by communication. Maintaining software is a series of compromise between different needs from people with various background. Of course, we core developers and Debian maintainer have different demand.

    As for ruby-dev, most of core developers do understand English, and appear in the core mailing list. All of documents, ChangeLog entries are in English. So you don’t have to consider English-speaking developers second class, despite the existence of Japanese-speaking ruby-dev mailing list. I don’t think we have to remove it.

    For versions, as you know, 1.9 was a huge jump. So we had to keep 1.8 for far longer period. But as a Debian package manager,
    you can safely ignore 1.8.6 and 1.9.1. They are only for maintenance. We have virtually three versions, 1.8.7, 1.9.2, and trunk. Having versions for development (trunk), stable (1.9.2) is not unusual. Having 1.8 is a bit exceptional.

    RVM and gems. Conflict between packaging system for the language, and general purpose packaging system like Debian is common problem; Perl has CPAN, PHP has PEAR and Ruby has RubyGems. I am not yet sure there’s good solution for it. Probably we can work together.

    Assholes. I feel sorry. I also have been sick of trolls for last 15 years.

    matz.

  37. People don’t need one dominated national language they need have an international auxiliary language — something like Esperanto

  38. I express an emotional opinion first of all.
    If you don’t want us Japanese to read and to write Japanese,
    the United Nations should have forced us to using English in
    1945.
    Yes, you know, they did not do so (thanks MacArthur!).
    So you should complain to them.

    OK, let’s go calmly.
    Well, all important announcements about the future of Ruby
    are sent in English, to ruby-core for the developers and to
    ruby-list for the average users.
    The reporters are often Japanese, so they send same announcements
    to ruby-dev and/or ruby-list, but they often omit to translate
    them to Japanese, so we read them in English :(
    In the issue, especially about important announcements, English
    readers receive same informations as Japanese readers.
    I feel dissatisfied that we Japanese readers should read English
    messages in Japanese ML.
    But, from this fact, you can understand that English readers have
    not received the disadvantage.

    BTW, I who dislikes English most in ruby committers object in
    English.
    What is hoped for any further? :)

  39. @U.Nakamura:
    It is not about announcements, but about discussions about the future of the language. For us non-japanese-speakers, only the outcome is available, while some of us would like to participate in the discussions, or at least know the reasoning behind some decisions.

    Basically, at some point, the decision must be taken: should ruby stay a japanese project, or should it become an international project? If the decision is that it stays a japanese project, it would make sense for frustrated non-japanese developers to fork it.

    > BTW, I who dislikes English most in ruby committers object in
    > English.
    > What is hoped for any further? :)

    heh! :-) for the record, that’s really appreciated.

  40. @Lucas
    > For us non-japanese-speakers, only the outcome is available

    You have misunderstood it.
    The conclusion is only mostly sent as for Japanese ML.
    Us and you are looking only at same information.
    So, if you have some questions, you must ask it
    (of course, in English, if you like it).
    And if you have some proposals, you must send it
    and start the discussion (of course, in English,
    if you like it).

    I strongly agree that the decision making process
    in Ruby is indistinct.
    But it’s not because of Japanese.
    The process is in someone’s head.
    Nobody except them can observe it.

    For their honor, of course, they are not
    intentionally concealing something.
    Their proposals might be only seen the conclusion
    in case of almost.

  41. @nona, what you (and many Python/Ruby developers) don’t understand is that installing several versions of the same module at once is not a solution. Quite the opposite, even: this is the problem.

    You cannot turn a system into a production without stable versions for each of its components, and you cannot expect long-term maintenance of each of those versions. As such, you can prototype your applications with a language like Ruby, but you cannot put them into production in decent conditions.

    This is true for Ruby, this is also often true of Python, unless you use a contained set of modules with emphasis on long-term compatibility and support, such as Django.

  42. Your pain is understandable lucas, you’ve put a lot of effort into maintaining something borderline unmaintainable. However, I think some of the comments people have made make a lot of sense, and should be considered in a followup post. It’s easy to get caught up in the heat of the moment, right?

    As someone else pointed out, you are trying to shoehorn a rapidly changing environment into a stability oriented OS packaging system. While something like RVM doesn’t fit everyone’s needs, it fits most needs in my opinion. It adds order to the chaos that is the Ruby community, and allows both devs and admins to easily manage the ecosystem. Trying to squeeze that beast into an OS package management system is a nightmare at best, and the fact that you’ve managed to work with it for so long is a testament to your abilities. Unfortunately, it’s just been an uphill battle trying to pound a square peg into a round hole.

    In regards to the Japanese/English “problem”. I work in Japan for a game company (this blog post was pointed out to me by a coworker, I’m the only English speaker here), so I have a slightly moderate level of insight into the feelings of Japanese I believe. The truth is, Ruby is a globally used programming language that was mostly built and supported in Japan. From what I’ve seen Japanese people in the technology realm do their best to work with people in English, but the truth is Japan doesn’t use English at the level most bilingual European countries do. Sadly most people outside of Japan assume that they are fully bilingual, but the truth is the level isn’t really all that high except in regards to people that have studied abroad in an English speaking country. There are going to be huge gaps in communication, and that’s just a cultural related fact that won’t go away.

    I do not mean anything bad in regards to Japanese when I say this, it’s just how their culture operates, but trying to get them to change something is like trying to pull teeth. As someone working in the tech industry this can be immensely frustrating, but as an outsider I have to understand that this is just how things are done here, and no amount of singular effort will make any huge impacts in regards to change.

    Ultimately if the English speaking community wants the development process to change, they’re going to have to fork the project. As long as everyone uses the RSpec’s, then there technically shouldn’t even be a problem beyond differences in implementation. If the EnglishRuby team still takes the time to work with the JapaneseRuby team, I am fairly sure that over time the project will be remerged back together with EnglishRuby and English language management working on the core.

  43. I agree that a followup post is needed. I will probably make several of them, separating the different issues. This will take some time, though.

  44. It’s easy for folks to stand behind walls and lob rocks. That’s what makes criticism so popular: anyone can do it relatively safely. Constructive criticism means shutting one’s mouth, rolling up sleeves and producing thoughtful insights and difficult truth with maturity and care. It also means attempting to come up with viable alternatives. Specifics. Not generalities. And Not too many critical people want to put their own work up alongside something they’re criticizing, opening themselves up to scrutiny, evaluation, and yes, even criticism. And given their behavior, they’d not to be on the receiving end of such scorn, no matter how ignorant or ill-informed it is.

    When we put our work out here, we get opinions, informed opinions, and hogwash. Distinguishing between them is sometimes an exercise in futility distracting us from the work and bogging us down in defensive ego-driven posturing. That only serves one thing: ego. Not the work, not the greater community. Small minded wannabes have it easy: they can benfit from excellent work, pass it off as their own, in many cases, and simultaneously take toss rocks at it or worse, personally attack those who actually deliver the value that naysayers so greedily benefit from.

    Sad to hear that back biting fools would rather feed the fire of their ego by flaming the good hard work of folks like you. Just know there’s legions of us less noisy folks out here who are humbled and deeply grateful for your efforts and contributions, your vision, and your results.

  45. @Brian Jones:

    >While something like RVM doesn’t fit everyone’s needs, it fits most needs in my opinion.

    Do you have any statistics to back up your claim?

Comments are closed.