How to poorly judge contribution in three easy steps
Posted: 2014-11-17 12:30


People get involved in open source for a lot of reasons. For some, it's their job. For others, it's to scratch an itch. People don't get involved for a ton more reasons.

Yegor Bugayenko of Teamed.io recently wrote a post titled "How Much Do You Cost?" on how people mis-estimate their hourly value, and the criteria he in turn uses to evaluate them. He covers several areas to form his evaluation, one of them being open source contribution. The good thing is that if you don't have any open source contributions to show for, Yegor gives three explanations why you haven't done them.

First, you're too shy to share your code because it's crap. Obviously, this is not a good sign. Not because your code could be bad, but because you're not brave enough to face this fact and improve.

Well, of course it's not a good sign! You're shy and you do bad work! It's a good thing there are two more reasons after this one - there's still hope.

The second possible cause is that you work from nine till five, for food, without passion.

Your employer is maybe paying for open source in one way or another, but have you paid the price? Even if they don't pay you for it, surely you have about 8 extra hours in your day and the entire weekend. This is modern software development, either you're in or you're out.

Pick your head up and put that crappy code out there!

The last possible cause is that you don't know what to write and where to contribute, which means lack of creativity.

Do you have to be told everything? Have you ever used some code and it just did its job? Yeah, right. You should probably go out of your way and improve things or find all the bugs, just because.

Come on, you have to get that crap code out there somehow. Sittin' there being all shy isn't going to bring the bugs out.


The justification for wanting non-shy non-crappy developers is that they have a very high bar when it comes to code quality, which is not really related. Bravery shouldn't have anything to do with code quality, unless you're looking to hire people you can shame and yell at about their code...which is how it appears to be when "you won't feel comfortable in our projects" comes after mention of negative feedback.

The paragrah about passion, which oddly isn't at all about passion, is quite telling. It reads more like how people get into gangs. The paragraph is about your use of personal time, not about your emotion and feeling toward the problems you're solving. Passion is something that really comes through in conversation, not in commit count. How much and when you work on something has little to do with passion.

The paragraph about lack of creativity contains very little to do with creativity. The features you want for a project don't always line up with the project. Sometimes they're just not good ideas. That's a thing that happens. That all results in code not being written, thus a seeming lack of creativity.

The sentence about finding, reporting, and fixing bugs ignores all of the problems people constantly run into with open source contribution. Finding bugs can sometimes be easy. Reporting them is sometimes easy. Fixing them is usually harder, but getting them accepted and into a release often requires a significant amount of effort. To then minimize the struggles all sorts of people have gone through, especially socially, by putting it like "you couldn't do this?" is just sad. That's their loss, as plenty of super smart people don't have time for kiddie games on the internet, or people who would carry this attitude.

When it all comes down to it, I'm fairly shy and write crappy code. I wonder how much I'm worth.

OpenStack SDK Post-Summit Update
Posted: 2014-11-11 11:00


This is a long post about the OpenStack SDK. It even has a Table of Contents.

Current Project Status

The OpenStack SDK is quickly heading toward being usable for application developers. Leading up to the OpenStack Summit we had a reasonably complete Resource layer and had been working on building out a higher-level interface, as exposed through the Connection class. As of now, first cuts of a high-level interface have implementations in Gerrit for most of the official programs, and we're working to iterate on what we have in there right now before expanding further. We also had an impromptu design session on Thursday to cover a couple of things we'll need to work through.

Project Architecture

At the lowest level, the authentication, session, and transport pieces have been rounded out and we've been building on them for a while now. These were some of the first building blocks, and having a reasonably common approach that multiple service libraries could build on is one of the project goals.

Session objects are constructed atop Authenticators and Transports. They get tokens from the Authenticator to insert into your headers, get endpoints to build up complete URLs, and make HTTP requests on the Transport, which itself is built on top of requests and handles all things inbound and outbound from the REST APIs.

http://i.imgur.com/A2U6yc4.png

Poorly drawn version of what we're doing

On top of that lies the Resource layer, a base class implemented in openstack/resource.py, which aims to be a 1-1 representation of the requests or responses the REST APIs are dealing with. For example, the Server class in openstack/compute/v2/server.py inherits from Resource and maps to the inputs and outputs of the compute service's /servers endpoint. That Server object contains attributes of type openstack.resource.prop, which is a class that maps server-communicated values, such as mapping the accessIPv4 response body value to an attribute called access_ipv4. This serves two purposes: one is that it's a place we can bring consistency to the library when it comes to naming, and two is that props have a type argument that allows for minimal client-side validation on request values.

Resource objects are slightly raw to work with directly. They require you to maintain your own session (it's the first argument of Resource methods), and they typically only support our thin wrappers around HTTP verbs. Server.create will take your session and then make a POST request populated with the props you set on your object.

On top of the Resource layer is the Connection class, which forms our high-level layer. Connection objects, from openstack/connection.py, tie together our core pieces - authentication and transport within a session - and expose namespaces that allow you to work with OpenStack services from one place. This high-level layer is implemented via Proxy classes inside of each service's versioned namespace, in their _proxy.py module.

Right now many of these Proxy implementations are up for review in Gerrit, but openstack.compute.list_flavors is currently available in master. It builds on the openstack.compute.v2.flavor Resource, simply calling its list method inside list_flavors and passing on the Session that compute was initialized with.

What the high-level looks like

There are a bunch of example scripts in the works in the Gerrit reviews, but some of what we're working on looks like the following.

Create a container and object in object storage:

from openstack import connection
conn = connection.Connection(auth_url="https://myopenstack:5000/v3",
                             user_name="me", password="secret", ...)
cnt = conn.object_store.create_container("my_container")
ob = conn.object_store.create_object(container=cnt, name="my_obj",
                                     data="Hello, world!")

Create a server with a keypair:

from openstack import connection
conn = connection.Connection(auth_url="https://myopenstack:5000/v3",
                             user_name="me", password="secret", ...)
args = {
    "name": "my_server",
    "flavorRef": "big",
    "imageRef": "asdf-1234-qwer-5678",
    "key_name": "my_ssh_key",
}
server = conn.compute.create_server(**args)
servers = conn.compute.list_servers()

Where we're going

General momentum has carried us into this Connection/Proxy layer, where we have initial revisions of a number of services, and by default, we'll just keep pushing on this layer. I expect we'll iterate on how we want this layer to look, hopefully with input from people outside of the regular contributors. Outside of that, results from conversations at the Summit will drive a couple of topics.

  1. We need to figure out our story when it comes to versioning APIs at the high level. Resource classes are under versioned namespaces, and even the Proxy classes that implement the high level are within the same versioned namespace, but we currently expose high level objects through the Connection without a version, as seen in the above examples.

    On one hand, it's pretty nice to not have to think about versions for APIs that only have a v1, but that won't last. Along with that, we're working in a dynamic language on growing APIs. Not pinning to a version of the interface is going to result in a world of pain for users.

  2. We need to think about going even higher level than what we have now. Monty Taylor's shade library came up both at his "User Experience, SDKs" design session, as well as during the impromptu OpenStack SDK session we had, and once we get more of the Connection level figured out, we're going to look at how we can tackle compound operations.

  3. Docs, docs, docs. Terry Howe has been putting in a lot of work on building up documentation, and now that we're moving along more smoothly up the stack, I think we'll soon hit the point where code changes will require doc changes.

    I'm also working up a "Getting Started" guide for the project, as we have some people interested in contributing to the project. Thursday's python-swiftclient session ended in that team being interested in shifting their efforts to this SDK, so we need to make sure they can easily get going and help improve the client and tool landscape.

    For the time being, doc builds will appear at http://python-openstacksdk.readthedocs.org/

  4. PyPI releases. Terry put together a version of the package that could reproduce the examples we showed in our talk on Monday, comprised of master plus a couple of his in-flight reviews for compute and network and mine for object store. As we progress and want to try things out, and to enable people to try along with us, we'll probably keep cutting more releases under 0.1.:

    pip install python-openstacksdk
    

    Keep in mind this is absolutely a work-in-progress, and API stability isn't yet a thing, so check it out and let us know what you think, but don't build your business on it.

  5. Need to get back into some of the administrivia that we've been avoiding recently in the name of expanding the Resource layer. The wiki page could use a refresh to reflect where we're at and what's going on. We need to start using more blueprints and the issue tracker, especially as more people become interested in joining the project. We were able to work without most of that when it was just a couple of us wanting to get this off the ground, but we need to make better use of the tools around us.


Overall, the SDK is coming along nicely. We had some good talks at the Summit and got a lot of interest from people and projects, so the coming months should be another good period of growth for us.

Summit Presentation with Terry Howe

On Monday, Terry Howe and I presented "Getting Started with the OpenStack SDK", a 40 minute talk on why we're doing this, how we're doing it, and where the project is going. Both of us had presented at conferences before, but never jointly, so it was an interesting first time experience, and it seemed to work well. The general gist is that I covered the most of the "why" and "where", and Terry covered most of the "how".

The first half focuses on three key ideas that brought this SDK to being: fragmentation, duplication, and inconsistency in the library and tooling landscape around OpenStack. I dove into each of those areas with examples of why they're an issue, such as how many different clients there are, and how different it can be to work with them. From there I covered some of the goals we have while trying to improve those issues, such as building solid foundations and providing consistent user interfaces.

The second half focuses on showing where we're at and what can be done. Terry took a working example that creates a network, sets up various security group rules, starts up a server, attaches a floating IP, and results in a running Jenkins server. After that, he dove into some of the internals, showing how session, transport, and authenticator work together, and explaining the resource and proxy levels.

After we were done, we had a good 10 minutes of questions, and about another 20 minutes of conversation in the hall afterward. A university professor came up to me to say he wants to use the SDK with his students, which was awesome to hear.

Check out the video here - 42 minutes total.

SDK Conversations at the Summit

In the Marketplace

While spending most of Monday through Wednesday in the Rackspace booth in the marketplace, I talked to a lot of people about the SDK project. It's fun to give away t-shirts and raffle off prizes at conferences, but I'm there to talk with people about the experiences they have with Rackspace, OpenStack, and other platforms, and to advocate for the first two.

I've gotten the SDK "elevator pitch" down fairly well by now for when people turn around and ask what I do. The good thing is that no one thought it was a bad idea! People were excited over various parts of it, mostly between reducing the fragmentation by offering all of the libraries from one package, and a lot were excited about coming up with more consistent interfaces across services.

Overall it was a lot of small conversations that ended with a smile that we're both doing fun stuff and it's all getting better.

Impromptu Design Session

Although we didn't have a session on the schedule, we created one of our own Thursday morning in the Le Meridien lobby. Dean Troyer, Jamie Lennox, Terry Howe, Ken Perkins, and myself gathered to talk for about 40 minutes on where we're going. We talked about two main points: an even higher level than we currently provide, and our multi-version story.

Even Higher Level

Currently we provide an abstraction that gets a user to the point where they can call, e.g., object_store.list_containers(), and they'll receive a list of containers. We've taken care of the lower-level plumbing bits like authentication, session, and transport within the Connection class, which exposes the object_store namespace, containing the higher-level view on top of the account and container resource level.

It was mentioned during this session, and during Monty Taylor's user experience session, that Monty is working on a project called Shade. Shade flies at a higher level where you say give me a working server and it does what's necessary to make that happen. The tool aims to abstract away provider differences in order to complete the task, such as how Rackspace gives you a VM with a publicly accessible IP and HP VMs need to be added to a network and have a floating IP attached to them.

"Give me a server" is a pretty common first step for newcomers, so that's an obvious starting place. "Upload this directory to object storage" is another. If you have others, we'd love to know, and we'd love help to implement them. With where we're working right now, we're not yet on to provider specific plugins, so high-level multistep tasks on vanilla OpenStack are what we're looking for.

Multiversion APIs

At the high level within openstack.Connection, we're not currently making any attempt to expose multiple versions of a service's API. We support authenticating via either a v2 or v3 Keystone, and we support multiple versions of APIs at the resource layer, but you end up with high-level access to a set of unversioned service APIs. On one hand, that makes it fairly nice to work with methods on openstack.object_store, especially since there is currently only a v1 API, but should that actually have a v1 somewhere in there?

A point was brought up that we pin versions in other places, such as our requirements. We couldn't have an unversioned dependency in requirements.txt and expect our code to continue working against its APIs forever. When they go from v1 to v2, things will be different and potentially affect what we've coded against. If you've written against the v1 API, you probably want to stick with it until you've written and tested against the v2 API. As much as the unversioned namespace may feel more friendly, it's eventually going to cause pain.

The "Improving python-swiftclient" Design Session

On Thursday, John Dickinson held a session on how to improve the python-swiftclient project. I'm not a contributor there, but was interested to see what they were planning to do and maybe chime in on getting a few more eyes on the SDK, especially since I threw together a high-level Swift view.

Within the first few minutes, the bulleted list that the group had come up with looked a lot like the bulleted lists we came up with to start the SDK project. They have a lot of work they want to be doing, and we're already on our way doing much of the same. Dean Troyer beat me to the punch of grabbing a mic and asking if it's possibile to put some of these efforts behind both OpenStackClient and the SDK.

Dean and I then gave very quick talks on where OSC and SDK fit in to what they were aiming to accomplish. From there, the conversation shifted towards 'Can we accomplish this over there?' and 'Do we want to accomplish this over there?' The answer to both turned out to be 'yes'.

Coming out of this meeting, we're going to have to quickly bulk up our documentation of the lower-level parts so we can bring these folks up to speed, as one of the first topics was their HTTPConnection class, and the second was from Jamie Lennox on using Keystone's sessions.

We're also going to need to bulk up on a "Getting Started" guide for new contributors coming out of this session and a few other talks I've had. Welcome everyone!


If you got this far, wow. See me at a conference some time for a high five.

Writing a PyCon Proposal
Posted: 2014-09-03 11:29


With the PyCon 2015 Call for Proposals ending in 12 days (on September 15), a few people have been asking "what makes a good PyCon proposal?" We've written up some proposal advice in the past and gathered a bunch of proposal resources as well (including a sample proposal I wrote about putting a pug into space), but we still get questions on filling out the actual proposal form.

Speaking at PyCon, or any conference or meetup, is an awesome experience. With a conference the size of PyCon and with the amount of proposals that are received, competition is pretty intense. The following guidelines have been helpful to others, and I hope they'll be helpful to you. Keep in mind that I'm only one individual reviewer - these aren't PyCon's "official" guidelines.

Tip

If you want to follow along, create an account on the PyCon site and then enter your dashboard. From there, choose the "Submit a new proposal" button and then the type of proposal you want to submit. If you had an account last year, we carried them over to this new site.

Title

A couple of words represent all of the work you put into this proposal; your slides, the rehearsals, and everything else about it. The title is your big shot to attract people, and it's also one of the few ways to find your presentation after you give it. Substance is much more valuable than flash here. It doesn't have to be dry like a patent application title, but shy away from memes.

Duration

PyCon has a limited number of 45 minute talk slots, and asking for one is merely a suggestion to the program committee chair who constructs the schedule. If you think you have a 45 minute talk, go ahead and select it, but be aware that it might not fit in the schedule and you may instead be offered a 30 minute slot.

Description

Your description will end up both in our printed program and in the online schedule. It's limited to 400 characters, so it's a nice supplement to your title. If I bumped into you in the hallway and found out you were on the way to give this talk in two minutes, what would you tell me? Write that down and you're golden.

Audience

Since PyCon attracts a wide range of people across a broad range of skill sets, you're going to end up with some attendees who are learning your topic for the first time, some who know about it, some know it, and sometimes even the people who created it. Who do you really want to reach out to the most? Who do you want to hear questions from at the end?

Python Level

Be as accurate as you can be. A lot of people come into PyCon looking for talks that will help them level up across the board, so you may get a beginner who is going to try and attend a bunch of intermediate talks and push themselves. If we're all fairly accurate, we can put information in that person's hands that is within reach to help them learn. That's why we do this whole thing in the first place.

Objectives

What do you want people to get excited about? Maybe you started off your proposal by saying "hey, I wish people knew X, Y, and Z". Boom. Maybe you started it off with a generic topic and formed a more specific proposal within it. Either way, think about what you'd want to talk about in the hallway after you give the talk. What do you want your attendees to tell their friends about?

Detailed Abstract

This text ends up on our website, clickable from the schedule and talk lists. You hooked 'em with your title, your description made it sound even better, and now it's time for business. This is where you dig in and explain what you're going to talk about for 30-45 minutes, with some amount of detail into the topic. Let readers know why you're giving this talk and what they'll get out of it. If the Description was what you'd say to me two minutes before the talk, this is what you'd tell me at dinner the night before.

This field is Markdown enabled so you can jazz it up with links and other formatting. Some people like to put their full outline in here, which is fine. If you do that, just note it in the Outline box.

Outline

This is only visible to reviewers. A lot of people like to put a Detailed Abstract in paragraph form and then break it down into an outline to show how the talk would be organized. The outline helps reviewers get a feel for your level of preparedness on the topic as well as how organized your thoughts are in covering the topic in a live presentation. If you've thought about how much time you want to spend in a particular area, a lot of people add that, which is helpful as well.


Good luck with your proposals!

Hanging out with Hackers & Hookers in San Francisco
Posted: 2013-10-23 14:44


It's that time of year again: Halloween. The season is changing, leaves are falling, pumpkin spice lattes are everywhere, everyone's digging out their hoodies, and we're all planning our next mind bogglingly thoughtless party.

Oh, wait, you weren't doing that last one? Well that's alright. It's good, even. Hacker Hideout, "a member based community center in San Francisco for thinkers and builders; tech lovers and business moguls; students and teachers alike", is taking care of that one for this year. On Friday, the "social event center" will be hosting "Hackers & Hookers", representing the Hideout's social entertainment services.

If you're one of the Hackers at Hacker Hideout, "you are supported by a community of others that are living and breathing, and dreaming of making something great, changing the world, and being rewarded for it." Basically, you're alive and you want to do stuff and be rewarded for it.

Think about being a hooker for a second. That definition runs something like, "you turned to prostitution to keep food on the table or were forced into it, you abuse drugs to clear your mind of what you now have to do, you can't stop being a prostitute because you won't have money to feed the addictions, and even if you get out of the sex trade, you'll likely still turn to drugs to scrub your mind of what you had to go through in the past. You dream of another life."

The Hacker network at Hacker Hideout, "provides valuable resources; at a minimum through others’ expertise and experiences you will take part in a knowledge share that can only enhance and help you prepare for your own execution plan."

Think about the hooker network for a second. Their pitch runs something like, "the community uses your body for small sums of money and you will take part in it for the foreseeable future, spending most of your income to numb your mind."

Members of the Hacker group were "just like you at one point." They had dreams, plans, and profitable business models. They were working towards their goals, and now they're united by a physical hub, destined for greatness.

Members of the hooker side of the party were also just like you at one point. They had dreams and plans. Now they're having sex for crumpled twenties so they can buy a honey bun and a couple of hits of dope.

The people who run Hacker Hideout don't take equity: it's for the hackers. Ever heard of a pimp?

Sounds like a great event. The flier says there will be girls there.

Why I don't feel so bad
Posted: 2013-02-20 09:45


Yesterday I came across a post titled The Python documentation is bad, and you should feel bad. It made me feel a little bad, but not too much. Here's why.

Weighing in at over 2,000 words, it makes a few decent points, but it makes broad conclusions based on small samples, and makes a few cringeworthy points towards the end. 200 words would have made the relevant points, or just a bug report or two. That's not as fun as writing a rant, though.

I disagree heavily with a few things he wrote about, namely what I think is a view of the community clouded by a lot of other negativity he was feeling around the topic of documentation. It's no secret that our documentation can use some work, but I think the community gets a bad name here when it isn't called for. There also seems to be a misunderstanding of how work gets done.

The Community

The section on "The Python Community" was pretty unfair and doesn't really seem to reflect reality. While it states that the section isn't all about #python, it's pretty clear that the poster's experiences with #python colored his beliefs. Unfortunately, the IRC channel isn't always known as one of the most friendly places to find help. That sucks, and I hear from some trusted folks that it's changing for the better, but it is somewhat of a common opinion, so I'm not 100% surprised he feels that way.

The later mention of fanboyism, specifically towards Twisted, likely comes from his experience in #python, because that's one of the few places I consistently saw Twisted being recommended. They get a ton of questions every day, many of them repeats, and they probably try to limit the set of answers they need to give. It's a very busy channel and they try to help as many people as they can, so they need something to make it easier for them.

Whether or not you like Twisted, it does solve a lot of the network questions people have. I'm with the author that being told "just use Twisted" isn't always helpful and isn't a possibility in some cases, but it doesn't make the whole community unhelpful and hostile. Just like "install linux" isn't a helpful answer to "How do I install pywin32?", which pops up on Reddit here and there, sometimes you just need to ask in another place to get more (useful) opinions. Hostile and unhelpful would be some of the last things you could say about support avenues like comp.lang.python or Stack Overflow.

The post has an edit to clarify that his opinions don't seem to apply to Reddit and Stack Overflow, which is good. However, I don't see the differentiating factor between any of those sites and the many other communication channels. One the author attempts to provide is "communities that consist mostly of Python developers, and do not have a very distinct culture of their own," probably referring to mailing lists. Having participated in all of these sites, mailing lists, and IRC channels, it still looks like the painting is being done with an awfully wide brush.

Community Norms

"The general norm for the Python community appears to be that if you are not already familiar with the language, you do not deserve help," is something that could not be further from reality.

How many beginners books do we now have? How much free introductory material do we now have? How many colleges, traditional and otherwise, are now teaching Python? There is no better time than now to learn Python, and the amount of resources has never been as plentiful.

The tutor mailing list, a resource for those beginning with Python, looks pretty active and helpful. I just looked at the February archive and what do you know? The very first post on that page is by Alan Gauld, author of "Learn to Program Using Python". Funny story: My father was one of the reviewers of that book leading up to its publishing in 2000, and I wrote my own small review of the book (he gave me the $200 they were paying reviewers at the time, I bought a new baseball bat). His response is a wonderful showing right off the bat, and a quick perusal through the list shows some good help being given.

python-list is another resource and tends to be for those who have gotten their feet slightly wet, but it's really open to anyone. This list is very active, and while I haven't followed it in years, a quick look through the archives shows the same generally helpful user base that I'm familiar with.

When it comes to being involved in development efforts, we have the core-mentorship list that serves as a great place to get involved in a helpful and friendly atmosphere. Many beginners have come through this list and gotten started on their way to having their contributions accepted into the Python source tree. Even python-dev is good about working with first timers when they come up.

PyCon, a conference generally stocked up with intermediate to advanced material, has two tutorials not only for beginners to Python but for complete beginners to programming as a whole. There are also two days of childrens tutorials being given for free.

The Python Software Foundation has a committee devoted to helpful and friendly efforts. The Outreach & Education committee funds efforts around the world to teach Python to various groups of people. There's a budget and a list of excellent committee members, and a network of people around the world that are interested in helping the cause.

The rest of the paragraph goes on with wild hyperbole about people saying you're horrible for having less than optimal code. I'm not usually one to say "cite your source," but, cite your source.

I'm aware of the confirmation bias I have at times when it comes to Python being a nice and friendly place, but I'm well aware that it's not actually sunshine and roses. The community at large may need tuning as growing pains hit from time to time, but it's not a current issue as far as I've been made aware of.

Reading the Source

Speaking of sources, the poster goes on to resist reading the source. While a valid point in general if you're just trying to find out the signature of a function, there's a lot to be learned by reading the source of code you're using. When it comes to Python, a language generally referred to as "readable", in some cases the code really is a good thing to rely on.

However, it shouldn't be the only thing, so I can see why he got upset with it. Pointing people to the source isn't usually a good beginner response unless you can point them to where in the source their answer is going to be, and even then you have to make sure it's not going to overcomplicate what they're looking for.

If we didn't have documentation for winreg.OpenKey and I told you to read the source, would you know it's a C file in PC\winreg.c of a source checkout that you likely don't have? No. He's got a valid point, but I would recommend everyone does take a look at the code they're importing and using at some point. It doesn't have to be a black box and you could learn a thing or two along the way.

Mind Reading

Perhaps the most egregious claim in this post is that someone should be working on the points this author just wrote about. For one, in order for something to be fixed it must first be determined that it is broken. We tend to do that through the use of bug reports. http://bugs.python.org is open for business 24/7.

I think the author does bring up some valid points about documentation that could use a discussion, so hopefully they are submitted. We don't know about them until you report them. What's obvious to one may not even register to others, so there surely can't be any effort underway when not everyone is on the same page.

Keep in mind that it takes effort to get things fixed in an all volunteer project. It takes some effort to engage in a discussion, and it takes a lot more to complete the changes.

However, I must say that I don't have high hopes for changes in this area if the reporter isn't interested in helping. Changing open source software isn't a drive-thru experience. Sometimes you have to get behind the grill and flip your own burger if it's not being served fast enough.

The demand to "make it happen" was particularly funny to me, reminding me of Guido's "make it so" comment in his response to approving PEP 414 (if you don't get why this is funny, Guido created Python). This right here simply doesn't work, especially ending it with "that's what developers do." The author could stand to learn a thing or two about respect, given again that an all volunteer workforce isn't exactly waiting at the beck and call of everyone with a blog.

A lot of the developers of Python work on things they want to work on in areas they're interested in. An overwhelming majority of us put in these efforts off the clock, hacking in the evenings or on the weekends, in order to contribute to a project that we like. Knowledge of that will hopefully result in a better tone moving forward (it's pretty much required).


In conclusion, I think what could have been said in a bug report or two became an unfair smear of the Python community. For me, the good points were mostly marred by trying to fill up a rant post, and I'm not optimistic that anything positive will come out of it. That's a bummer because we could always use some help.

Contents © 2014 Brian Curtin