Since December 2010, I've been working directly for the Ruby community on a full-time basis, with no formal sponsorship or funding beyond individual contributions. I want to make this sustainable on an ongoing basis by accepting small monthly payments from folks who want to support my community projects. At the time of writing this post, I have 59 subscribers backing me for a total of $608/mo before paypal fees. Taking in account my wife's income, I still need to come up with about $1500-$2000/month more to maintain our current lifestyle. However, the current subscribers have given me a great start, and I'm continuing on with the experiment for now. To remain transparent, I am doing frequent updates on what I've been working on so that folks know what their money is supporting.
Mending RubyGems Fences
Since the last progress report, I've managed to throw myself into a difficult situation in the hopes of addressing some serious issues within the Ruby community. In particular, I have volunteered to act as a mediator to help defuse the intense drama that is currently surrounding the RubyGems project. I won't go into great detail in this report, because I've written extensively about it on this blog, but I can give a quick summary of what my goals are. First and foremost, I'm trying to collect some dispassonate information about the main source of tensions between the RubyGems maintainers and the community so that those on the sidelines can find out what's going on without getting sucked into the drama. Secondly, I'm trying to find areas in which compromises can be made so that folks on both sides of the fence have less reasons to be angry at each other. This approach seems to be working, though not as fast as some might hope. Lastly, I am trying to demonstrate by example that nerdrage is unproductive and harmful, and that acting civilly will not only help prevent people from getting so stressed, but also make the process of affecting positive change happen more rapidly. The results so far have been varied, but I feel the process is worth it and will be continuing on with it in the coming weeks, assuming nothing goes nuclear.
Ruby Object Model Book
Jordan (@Jordan_Byron) and I worked on building out the website for purchasing my book, because I do need some additional revenue streams coming in other than subscriptions, at least for now. But because the book is going to be released under a pay what you want model with a free option, I'll be happy to occasionally post excerpts here so that you can see what I've been up to. As a pre-requisite for prepping the book site, I needed at least a little sample content, so here are the first three micro-chapters as a PDF. At a first glance, this format might seem a bit weird to you, because it introduces classes, modules, and objects in the method lookup order rather than the way you learned OOP in school or in a Java/C++ book. It's an experiment that I think will ultimately be epic, but if you don't like the feel of it right now, wait until I have some more chapters written to express your doubts. I have what I think are good ideas for how this all will work but they're still tied up in my head.
Ruby Mendicant University
I've still been cranking away at helping our May students make it through the core skills course, but because I've been so busy with the RubyGems fiasco, I've also been leaning heavily on my assistant instructor, Shane Emmons (@semmons99) to make sure our students get the attention they deserve. When you add in our mentors and our visiting teacher Steve Klabnik (@steveklabnik), the students have had no shortage of available help and the results have paid off, this is our best retention rate in the last few days of the course ever.
In addition to the core skills course, we also have admissions open for new students who will join us in July. Four have applied already: two were accepted, and two are still pending review. Many people are attempting the PuzzleNode problemset, so that means that we'll likely see more applications soon.
Finally, as I mentioned in the last status update, we are sitting on a treasure trove of ideas from RailsConf, as well as a brand new idea that came to me last night, many of which will have direct impact on the community as a whole, not just our students. However, I've decided to wait until the end of the May session so that we can include our new alumni in the discussions. Expect news within a week!
Want to contribute?
If the things I'm working on sound worthwhile to you and you want to support it, please subscribe! It will help me keep doing good stuff for the community without having to focus too much on making ends meet. I've been doing this since December but only recently started accepting funding, so it will really help me counterbalance several months of burning through my savings.
Catch you again next week! I will get a mailing list and IRC channel set up for subscribers before the end of the month, but for now, if you have questions or thoughts to share, feel free to leave them in the comments section below.
My free online school, Mendicant University, has a lot in common with a startup environment even if we're headed down the nonprofit path. In particular, we share an endless amount of interesting ideas, a lack of available time to implement them all, and a goal of reaching some level of sustainability before the money we've scrounged up runs out. The more ambitious our plans become, the more I see what a hard job it is to start something. While the title of founder is something I originally gave myself just to be a bit facetious, now that Mendicant University is starting to become a real thing, I'm having to earn that badge.
As an entirely volunteer organization, we are always limited in resources. What this means to me is that any student or staff member who has decided to lend a helping hand needs to be working on the things that will help make sure that Mendicant University will still exist a year from now. There are a thousand interesting things we could be working on, in fact, last week's RbMU summit at RailsConf probably gave us enough ideas to last us all a lifetime. But in that lifetime of work, the question remains: What can be done today that will help make sure that we will be here tomorrow?
I don't have an answer to this question just yet. But what I do have is maybe a strategy for helping to find that answer. It's something that should be familiar to object oriented programmers: Do one thing and do it well. If the single responsibility principle works so well as an organizing principle for software systems, perhaps it will work for human systems as well. I even know the one thing that Mendicant University can do well, though it's far from surprising: We're really fucking good at teaching.
Yes, it's true that now that we've been around for almost a year, we're going to need to start treating this like a real organization and not just one of my experiments. That means we'll need to think about ways to engage the public, we'll need to consider fundraising options, we'll need to continue building up our infrastructure and do all the extra behind the scenes work that any medium sized organization needs to do. But the important thing to remember, throughout this all, is that all of this serves exactly one goal: to create an environment where high quality, personalized, experience based teaching can slingshot smart and interesting people into doing awesome stuff for the world.
So no matter what it takes for us to get there, that's what we'll be doing. What is the one thing you want to do well?
My post that called upon Ruby hackers to stop raging against the maintainers of RubyGems was unsurprisingly controversial. There are clearly a bunch of wounds that haven't healed yet, and no immediate sign that they'll get better. Personally, I think this whole situation sucks, and I want to help fix it.
Effective immediately, if you've got an issue that you felt was ignored, disregarded, or otherwise not properly handled by the RubyGems core team within the last six months or so, you can email me and let me know about it. I'll be collecting these emails, grouping them together, and then meeting up with the RubyGems maintainers to try to figure out what went wrong. I'll collect some notes and then do one of two things: a) get back in touch with you about how you can work to get the change you want to see made integrated into RubyGems, or b) write up a technical report with an official response from the core team about why your idea isn't going to work out.
I won't be rude to you, I won't ignore you, and I won't judge you based on your current or previous personal or technical conflicts with the RubyGems team. I will read what is bothering you, contact you for additional details if necessary, and try to get some honest and helpful answers for you from the folks who really know the RubyGems internals. In most situations, these are the sort of conversations that are best to happen in public, but we've seen how that hasn't been working out lately. I'm throwing my hat in the ring in the hopes that if I'm nice to you, and if I'm nice to the RubyGems folks, that we'll see some real progress instead of a bunch of worthless conflict that generates more heat than light.
If you haven't had a bad experience with the RubyGems team, I recommend that you continue to submit pull requests, bug reports, and support requests as needed via the ordinary process. Be civil and I think you'll get a civil response. But if that doesn't work out for you, contact me and I'll do what I can to get you answers. Let's face it, our most important project feels a bit like a powderkeg right now, and it doesn't have to.
One important thing to note is that I am not an active RubyGems contributor. This puts me at both an advantage and a disadvantage, since it means that my knowledge of the history of RubyGems is somewhat limited. What I'd ask you to do when you send me emails is to please give me enough context so that I know what you're talking about, and ideally make it so that your email is fairly self contained. If what you want to discuss is too complicated to give me an executive summary, at least provide links back to other resources so that I can do my homework and when I talk with the maintainers, I know where to point them to.
Please send your candid feedback about problems you've experienced with RubyGems to gregory.t.brown@gmail.com. Use the subject tag [rubygems] to help make sure I see your email. I will respond letting you know that it has been received, and then after I've got enough to go over with the maintainers, I'll get back to you with what I find out.
It is my hope that this sort of liason role I'm independently volunteering for is very much temporary, and can go away just as soon as we dig out all the thorns that have been jammed in our collective backsides for quite some time now. My main goal is not to convince anyone of anything about the project itself, but instead to see if I can better educate the Ruby community about what's going on with RubyGems, and also hopefully tie together some loose ends so that we can go back to focusing on doing awesome stuff, rather than fighting over the most boring but essential project we all work with.
UPDATE: Loren has responded with his side of the story in the comments section below. Worth checking out for a bit more perspective.
Want the RubyGems maintainers to take you seriously? It's not as hard as you might think. In fact, I can give you three counterexamples illustrating what not to do, and pretty much tell the whole story.
1) Don't name a bug report "Scary warnings are scaring helpless developers who can't do a thing about it". While quite descriptive, a better title might be something like the following: Suggestions for improving deprecation warnings and reducing their impact on end users. I can't help but think that a patch with this title, followed by a description with a similar tone would at the very least be rejected more gracefully by the maintainers.
2) Don't create your own fork of the world's most used Ruby project without at least submitting a patch or two first. We now have SlimGems, but according to Ryan Davis at least, Loren has never even attempted to submit patches to RubyGems. I won't deny that there are obviously underlying personal conflicts at work here, but there are classier ways to solve this problem. The right to fork is sort of like a nuclear bomb, it could be used as a deterrent, but once you actually use it, it's pretty much leads to widespread destruction with little benefit.
3) Don't write flamebait patches. Giles Bowkett wrote a one character typo fix but decided to name his commit message: "ENGLISH MOTHERFUCKER, DO YOU SPEAK IT?". This pull request was promptly closed and ignored, and rightfully so. While you can swear all you want in your own projects, on stage, or wherever else you want, if you are making a commit to a project that ultimately gets merged upstream into mainline Ruby, just resist the urge to quote sam jackson, and your patch will be merged. I re-submitted the same patch with a sane message and it was merged very shortly after I sent a pull request.
I'll also throw my own personal opinion into the mix, just for good measure. Right now, the person we have as the front man for RubyGems is Ryan Davis. I've been in the Ruby community long enough to know that Ryan can be outright rude to people sometimes. But in my experience, if you act civilly towards him, you'll at a minimum be treated civilly in response. The examples above are not ones of civility but instead the sort of passive-aggressiveness that surrounds what should be a totally uncontroversial project.
The RubyGems project is one that is infamously known for burning people out and making them head for the hills. Working on that project is thankless work, and while I don't want to hold up Ryan (or Eric, or anyone else who's worked on the project) as a poster boy for how communities ought to be run, I have respect for the difficult position they are in. It's easier for you to be civil to them in your interactions then it is for them to come out from under the culture of negativity that permeates through this project.
Remember that old saying "Matz is nice and so we are nice"? Last I heard, it hasn't yet been amended to "Matz is nice and so we are nice, unless zenspider acts like a dick to us". So please, check your nerd rage at the door, submit real patches and bug reports to RubyGems without throwing gas on the fire, and you may be pleasantly surprised at what you find.
I want to continue my Ruby Mendicant experiment on an ongoing basis by accepting small monthly payments from folks who want to support my community projects. At the time of writing this post, I have 55 subscribers backing me for a total of $576/mo before paypal fees. Taking in account my wife's income, I still need to come up with about $1500-$2000/month more to maintain our current lifestyle. However, the current subscribers have given me a great start, and I'm continuing on with the experiment for now.
Since the last progress report, I've primarily been running the May 2011 Core Skills Session at Ruby Mendicant University as well as attending BohConf 2011 (at RailsConf). On Tuesday 5/17 we held a mini RbMU summit with several of the alumni who were in Baltimore for the conference. A tremendous amount of progress was made in figuring out what our plans will be for the next year as Ruby Mendicant University continues to grow and change. Unfortunately, because I want to give the rest of the alumni who weren't in attendance a chance to review the ideas and plans that came up, I won't be able to talk about the details of what we went over just yet, though I promise to reveal some of them in the next progress report.
During BohConf, I spent a lot of time with prospective students who were interested in Ruby Mendicant University, helping them figure out what educational programs and resources would be best for them in their current situation. Luckily, since both Steve Klabnik (of Hackety Hack) and Andy Lindeman (of P2PU) were also in attendance, I was able to help folks who weren't quite ready for RbMU find someone who could help them. Interacting directly with a number of folks at different skill levels revealed some interesting patterns that are probably worth blogging about.
Because I spent much of the last week or so interacting with people face to face and listening to their stories, I didn't get a whole lot of hacking done, and so don't have much to share over the interwebs just yet. Here are some things you might be interested to know, nonetheless:
While the last week's efforts have mostly had to do with making progress behind the scenes, the next few weeks will surely bring plenty of publicly visible progress on my various projects. If my progress so far has convinced you that it's worth contributing $4, $8, $16, or $32 a month to help me keep working full time on community projects like these, please do subscribe below. Whether or not you're a subscriber, if you find my story interesting, I'd appreciate if you share a link back to this post on twitter or wherever else it might reach people who would appreciate it.
Catch you again next week! I will get a mailing list and IRC channel set up for subscribers before the end of the month, but for now, if you have questions or thoughts to share, feel free to leave them in the comments section below.
Two week ago, I announced that I want to continue my Ruby Mendicant experiment on an ongoing basis by accepting small monthly payments from folks who want to support my community projects. At the time of writing this post, I have 53 subscribers backing me for a total of $556/mo before paypal fees. Only three of these were new subscribers within the last week, so maybe I need to ramp up the promotions somewhat. That said, the lack of new subscribers has not stopped me from keeping on with my work, and here's what I got done since last week's progress report.
I probably did other things within the last week or so, but these are the things that haven't yet slipped my mind. If my progress so far has convinced you that it's worth contributing $4, $8, $16, or $32 a month to help me keep working full time on community projects like these, please do subscribe below. Whether or not you're a subscriber, if you find my story interesting, I'd appreciate if you share a link back to this post on twitter or wherever else it might reach people who would appreciate it.
Catch you again next week! I will get a mailing list and IRC channel set up for subscribers soon, but for now, if you have questions or thoughts to share, feel free to leave them in the comments section below.
Over the next several months I'll be working on my book, teaching at RbMU, and doing some other writing and coding for the free software community. Because I'll be doing that stuff full time and keeping my commercial responsibilities to a minimum, I have both a need and an opportunity to adjust my ways of communicating online to avoid a feeling of being always on. My new schedule isn't going to be anything radical, but it is a big change for me because recently I've gotten in the habit of obsessively checking twitter and email since there's always something there.
Effective immediately, unless you have scheduled a meeting with me or I've said I'll be around otherwise, you can expect me to be active on twitter and email at these times and these times only:
For those of you who might have a need to reach me urgently, you can always feel free to ping me on Skype. It's one of the few services that I typically only use for SERIOUS BUSINESS, so it's not a distraction to keep it on throughout the day. Of course, please consider whether your need to contact me is actually urgent before contacting me this way, as most things can safely wait a couple hours.
This shouldn't have any effect on when you can send me emails or mention me on twitter. It's only a schedule I'm imposing on myself to help me have greater periods of uninterrupted focus throughout the day, which should help me make the Ruby Mendicant Experiment that much more successful. Also, since this is primarily about me managing unanticipated or casual communications rather than pre-scheduled meetings, don't worry if I'm meeting with you at a time outside of this schedule, as long as you've worked it out with me ahead of time.
This may be the most boring blog post I've ever written, but making a public commitment to at least try this out is going to help me get it started. I'll report back in a month with how well it worked out (or didn't).
About a week ago, I announced that I want to continue my Ruby Mendicant experiment on an ongoing basis by accepting small monthly payments from folks who want to support my community projects. At the time of writing this post, I now have 50 subscribers backing me for a total of $544/mo before paypal fees. That puts me 20-25% of the way to a livable revenue stream within the first week of this experiment, which isn't a bad start.
One of the things I promised my backers is that I'd do a weekly dump of what I've been working on, and so here's the first one. Enjoy!
I probably did other things within the last week or so, but these are the things that haven't yet slipped my mind. If my progress so far has convinced you that it's worth contributing $4, $8, $16, or $32 a month to help me keep working full time on community projects like these, please do subscribe below. Whether or not you're a subscriber, if you find my story interesting, I'd appreciate if you share a link back to this post on twitter or wherever else it might reach people who would appreciate it.
Catch you again next week! I will get a mailing list and IRC channel set up for subscribers soon, but for now, if you have questions or thoughts to share, feel free to leave them in the comments section below.
Hello, my name is Gregory Brown. I am the founder of Mendicant University, a free online school for software developers.
I am passionate about community service, education, and the free software movement. If you're interested in getting to know me a bit better, feel free to send me an email: gregory.t.brown@gmail.com
