Interview with Jay Pipes, North American Community Relations Manager at MySQL

Interviewers: Scott Swigart, Sean Campbell

Interviewee: Jay Pipes

Jay Pipes

In this interview, we speak with Jay Pipes North American Community Relations Manager at MySQL.

We talk about:

Jay Pipes: My name is Jay Pipes. I work for MySQL. I’m the North American Community Relations Manager. Part of our job as community managers is to monitor, encourage, and grow the external MySQL ecosystem as much as possible. [This involves] responding to concerns of the community, pushing those concerns internally, being an advocate for the community within MySQL—being a liaison between free and open-source projects and companies and MySQL. Also, each of us has different responsibilities. I do a bit of development work for the MySQL Forge website. I work a bit with engineering. I do a lot of conferences and speaking engagements on performance tuning, and blogging, and writing, and that kind of thing.

Scott: I get it. You’re greasing the wheels between MySQL and the community at large, and trying to keep the information flowing friction-free in both directions.

Jay: Yes, I want to remove the friction points between contributors to MySQL and users of MySQL, developers and DBAs, and the flow of information from MySQL to make sure it’s accurate—that they understand. Especially with MySQL, we’re in a unique position. We provide this open-source software and we have this enormous, ubiquitous user community, but at the same time we’re selling products. So, because it started out as an open-source project, and the community knows that, a lot of people don’t even realize that MySQL is a company.

A lot of times we have to explain that MySQL as a company has to do certain things to provide revenue that will in turn benefit the open source community. Sometimes that’s the challenge. There’s this push and pull between commercial and the community. And the community team at MySQL, including me—a lot of times we get asked to advocate for the community within the company, but we also have to have an open mind. We are a revenue producing company, and at the same time, we want to be good for the community. That kind of balance is most of what my job is.

Scott: It’s interesting that you bring that up. There’s still this feeling like it still works the way it did six or seven years ago where open-source was people working on stuff in their basement. But if you look at any of the major projects out there, the model has really shifted. If you look at the Linux kernel itself—that’s a lot of engineers at Red Hat, IBM, Intel, and various different companies that are really doing the bulk of coding. If you look at something like RedHat/Enterprise Linux—again, this is a commercial enterprise, right? This is an ongoing business that has come up with a business model around something open source. And so, with you guys—help me understand it a little bit…

Jay: I will try and clarify something. A lot of people say, “Well, when MySQL just recently (in September or October) split between the community server and the enterprise server in MySQL…“ A lot of people equated that to RedHat/Enterprise Linux split. One of the things significantly different between MySQL and RedHat, is that within RedHat does produce its own pieces of software within the RHEL stack and the Fedora community packaging, it doesn’t have total control over its software — their software stack is dependent on upstream committers. Obviously its engineers contribute to the Linux kernel and various other things.

But MySQL has always been 99% completely written by MySQL employees. So, it’s a different model in that RedHat (until more recently where they’ve started to create more of their own software) has been more of a packager than it has been a producer of software. And there is a difference there. It’s what’s made it difficult for people to say, “Well, MySQL has done the Fedora versus RHEL split.

Scott: OK.

Jay: It is different because we are producing almost 100% of the code that we’re selling in the enterprise and then giving away in the community. Does that make sense?

Scott: Totally. And so, I’m sure you can explain this better, but if you’re using MySQL as part of an open-source project, then MySQL can be freely distributed with that project. But if you’re building something commercial on top of MySQL, then my understanding is that’s where you actually have to purchase a license. Or do I have it all wrong?

Jay: Well, it depends. A lot of people are confused by the licensing. Some of the confusion stems from the fact that it is GPL. Some confusion is that we sell commercially-licensed MySQL for those OEMs and ISVs that embed MySQL within their product and then distribute it. So, GPL is all about distribution—reciprocity and distribution.

If you distribute your product with MySQL, and your product is not GPL or a GPL-compatible license and is not an open-source product, then yes, you are required to pay a licensing fee to My SQL. However, a lot of people will say, “I’m distributing my product as a non-open-source piece of software. it can connect to MySQL.” So, if you have a MySQL server running on your network, my application can connect to that server and run against it.

There are different ways of using MySQL, but a lot of where the licensing comes in is when you’re an original equipment manufacturer and an independent service vendor—or whatever ISV is anymore—and you’re embedding and distributing MySQL as an integral part of your application.

That’s where the licensing comes into play. But not for web applications, when you have MySQL installed on the server and you’re a service-oriented application provider. That’s not where the licensing comes in. That’s where we sell the MySQL Enterprise edition, which is the support and services offering.

Scott: Got you. So, just to make sure I understand that: If I’m an ISV and I’m selling my software, and I package MySQL with it, I have two options. I can distribute my software under the GPL license, or I can pay a licensing fee to MySQL and distribute my source under a proprietary license. Is that it?

Jay: That is correct.

Scott: OK. OK, good.

Jay: And in the past, there’s been confusion about the protocol, but that’s not the issue. I think people have blown that up out of proportion. What you just said is exactly what it is. If you are distributing your application packaged with MySQL and you’re not releasing under GPL or a GPL-compatible license, you have to buy a license for each copy of your software that you distribute, because you are then distributing MySQL. Now, the licensing costs have also been blown completely out of proportion by a lot of people. People say, “Oh, it costs $595 per distribution.” That’s not right either..

The pricing depends on whatever the sales team at MySQL and you agree on. It’s just like any other company. But that is the case when you need to buy licensing, when you embed MySQL and you do not want to release your source code as GPL or compatible licensing.

Scott: Cool. And I’m just not involved enough in the community to really even be aware of what have obviously been contentious conversations, probably over the years. So it’s just me trying to understand it, coming…

Jay: No, no. I understand where you’re coming from. I was referring to this kind of myth that MySQL licensing is overly complicated. I work for MySQL, so I’m biased. But I don’t particularly think that is a complex process to understand. I think that the complexity really stems from the fact that there are just a ton of open-source licenses out there that all have these weird idiosyncrasies to them. And I think that complexity lends itself to, “Well, MySQL is open source, so it’s going to be complicated.”

Scott: Right. So, the main thing we’re focusing on is how software is built. We’re looking at things like Apache and the Linux Kernel. From the outside it kind of looks like they’re built over a mailing list. In other words, there are these core mailing lists, people post code to them, it gets reviewed, there’s a maintainer who decides whether it gets checked into the main tree or not.

Jay: That’s absolutely true, with Linux, Apache and Eclipse. Eclipse is more bureaucratic than that; they have hierarchies and procedures and policies and incubation periods and all that stuff—as does Apache.

Scott: With you guys, it looks more like a traditional proprietary shop. I’m guessing that you sit down and have meetings. You discuss what features are going to be slated for the next release. You come up with project plans; you come up with specs.

Jay: If only it were that simple. Yeah, on the outside is does look like a traditional software house, in that we have maybe 120 engineers working on various teams, from people that work on the connectors and the GUI tools to people that work on the server runtimes or the backup and replication folks.

Scott: Which is a lot. When you talk about 120 engineers,that’s a mid-size software company.

Jay: Absolutely. Absolutely. And yes it’s true that we have scrums internally. We have internal roadmaps. And up until, I would say, December or January of this year, what has been more of a cathedral-type model, meaning more of a closed-source model for development at MySQL. It’s now starting to open up significantly.

Recently, we opened up our internal work log system, which is as close as you’re going to get to a list of roadmap tasks that we’re working on. This is for anything from MySQL 5.2 and up to MySQL 8.1 and beyond from all sorts of crazy wish-list ideas to stuff that’s actually going into the code at this point. We’ve opened that up publicly on our MySQL Forge (http://forge.mysql.com/worklog/). People can comment on these tasks, provide suggestions and vote on things that they’d like to see. We’ve also started accepting more contributions from the outside community. So, it’s starting to be more of mix of an open-source project and a commercial company model. We’ll see how it goes. I’m obviously pushing for more of the open-source development model, having more outside committers and contributors that are providing both external tools to the MySQL server, but also fixing bugs and provided patches for small features within the server itself.

Scott: That’s interesting that you’re transitioning from the cathedral to the bazaar, to some degree.

One of the things that I don’t understand about things like the Linux Kernel is how really big sub-systems get built or worked on. At the point where IBM decides, “OK, we just need this in the kernel.” They don’t ultimately kind of get to say, right? If Linus doesn’t like it, it doesn’t make it in. At the same time, corporations are sort of doing the bulk of the development.

So, with MySQL, how do you see that shaking out? Certainly MySQL, the company, is going to control the direction of the product, you’re opening it up to take more community input both in terms of suggestions and ideas and in terms of actual feature code and things like that. But I’m guessing there will still be a pretty significant section of the product that will be spec-ed out. A team of engineers will be put on it to build out a feature. It’ll go through…

Jay: I think it will be a mix of both. And we’re still going through these growing pains of figuring out how this is going to work. The community team is going to be pushing more and more contributions from the community, and MySQL doesn’t dictate those in any way. Someone can hop on there and say, “You know what, I want to implement check constraints, and here’s the patch for it.” What will be the issue is which version of MySQL will that patch make it into. And will it be a module that will be marked as experimental? Will it be something that will be patched into the core kernel?

That’s the process that we’re currently going through. We’re still in these growing pains. We’re still really just now figuring out how to handle these kinds of contributions. So, over the next year or two, I think we’ll start to hammer that out, and understand, “This is going to go into the community server, and this is going to go into the core kernel.” I think, as we make the core server more modular, that issues like that are going to start to disappear a little more, because someone can provide a module, just like mod_ssl for Apache.

Scott: Right.

Jay: It can be a self-contained component that isn’t necessarily going to kill the main, core kernel of MySQL. And so it’s not going to be as big of an issue, because we can package and version up that module separately from the core kernel, and the community person can have it out there. Until we get to that modular core piece of MySQL, it’s going to be a little bit of a difficult road, as we decide how to patch that stuff in. But, on the commercial side, we’re always going to have companies that will provide us with what we call NRE, non-recurring engineering.

Scott: Right.

Jay: Which is basically, someone’s paying us to put a feature into MySQL that is vital, or mission-critical, for their business. So recently, a lot of that type of work has gone into the NDB Cluster tool, which is our high-availability tool. Telecom companies that extensively use MySQL Cluster would like certain things, and they’re paying for those things to get included. And we’ve got those type of projects going on all the time. In the next year or two, we’ll start to see a bigger balance of community driven activity, in engineering, and commercially driven activity.

Scott: Looking at successful open source software, I think you’re exactly right. Modularity seems to be completely essential. I might have trouble getting something into the Apache core, but I wouldn’t have any trouble writing a module and just putting it out there, and if people like it…

Jay: Absolutely, absolutely. And that’s the key to the community driven coding, is that once we get that architecture completed — the plugin interface — where people can write add-ons and extensions to MySQL – that problem of, “OK, which version of the server? Can we put this in there without destabilizing the core runtime?” Those kinds of questions will cease to be an issue. And so will packaging issues, because the community person can put it on their website: “Hey, this is my module for MySQL. Go download and install lit.”

Scott: Right.

Jay: Just like you would with any of the weird Apache modules that are floating out there.

Scott: Right. Apache, Eclipse. All of these things have a modular architecture. To be an open-source project that’s taking community contributions, it seems essential to have that modular architecture.

Jay: I think it is, yeah. It’s going to be a long ways to go. From my understanding, from the engineering team, it’s not something that happens overnight and, certainly, is going to take lower precedence to some of the commercial work that we need to get done on the server. And obviously, our roadmap is years ahead of time. [laughs] The stuff that’s going into MySQL 6.0 and 7.0 is already on the block.

Scott: Right.

Jay: Bringing stuff up like the modularization of the core kernel, we’re looking at two years down the road. But it’s still, in my opinion, vital to start thinking about this now if we’re going to really get to a point where a community is actively contributing to MySQL.

Scott: So, from a software development standpoint, that seems like it would be a particular challenge for MySQL is just that MySQL runs on so many different platforms. You guys have, I don’t know how many kind of distros for a given version. You run on Windows. You run on Mac. You run on a whole bunch of different Linux flavors. How much of the engineering effort do you feel like goes into features themselves, versus how much of the engineering effort goes into making a distribution that runs on such an enormously wide variety of platforms?

Jay: Yeah. I’m not privy to the exact numbers. I can take a guess, though. I would say that the portability layer that allows us to run on these various platforms is fairly stable. Not that it runs perfectly on all the platforms, but that we do run on all the major platforms. And the reason we can do that is an underlying subsystem that takes care of the portability between those systems. That’s been around for a while, so, unless we’re talking about newer things, like Windows 64-bit running on Falcon — which is our new storage engine coming out — I think a lot of that’s already been done. So, most of the work is really in the features, and a lot less in the portability layers.

Scott: OK.

Jay: And I would say that is the case with, say, PHP or Apache or Python, or many of the major open source projects. That core portability layer was a key thing early on, and it’s stabilized pretty dramatically recently, so that’s not really what people are working on; it’s more of the feature-wise stuff.

Scott: Got you. Got you. So, the only time the portability layer really needs significant engineering, like you said, is if you’re porting to a whole different architecture, like 64-bit, or something like that.

Jay: Or when you’re specifically profiling bottlenecks on a specific architecture.

Scott: Right.

Jay: But that’s more of a performance thing and less of, “Will it work on the platform?”

Scott: So, talk to me about some of the other stuff that goes into building a product, things like testing and QA. How does that work? MySQL, I’m assuming that it’s got pre-release beta builds, or daily builds, or things like that, that you can pull down.

Jay: Yeah. In fact, the release schedule of MySQL, on the way it’s built, I don’t think is going to be much different from most other open-source projects. We have an internal build team, which I think there’s four or five people on it, maybe. They are responsible for the overall release management: making sure that the builds compile on all platforms, that the binaries are stable on the major platforms. And also, building up the release notes, making sure the flags and switches that are relevant for each platform are turned on or off depending on what’s needed, and that everything runs through our internal push build system, which, essentially, is an automated system that says, “Will this build on this architecture?” And then, we also have a QA and testing team.

It used to be a single team. Now, we have one man, Omer Bar Nir, who’s the QA architect over the whole thing. But we have QA engineers, now, attached to each of the development teams. And so, they are focused specifically on the QA and testing of, say, backup and replication, or the storage engines, and things like that. So, where it used to be that the QA was across the board, now they’ve split up and focused on specific pieces. And I don’t think that’s very different from any other open source project. The way we release is, we use a tool called Bit Keeper for our source control, and we do nightly or daily snapshots from that, which you can take and build the source code yourself.

And then, once in a while, we’ll package up the source code into tar balls, or zip files, depending on what platform you need. And then, depending on what version of MySQL, whether it’s Enterprise or Community, they’re built into binaries and then distributed. All the distros that I know of don’t use the binaries at all. All the Linux distributions, they actually take the source, from either BitKeeper, or from the source tar balls for a release, and then modify it to suit their needs, mostly by where the configuration files go on install, what’s in there by default, all that kind of stuff. And then they package it up into a. DEB or an RPM, or whatever it is.

Scott: Right.

Jay: Now, for Windows folks, the vast majority of Windows users don’t have the ability to compile software locally on Windows. So, it’s much more important that we provide binaries for MySQL on Windows than it is for the Linux folks. So, that’s most of why MySQL has been providing binaries for so long. Also, we say, “If we built the binary, we’re assuring you that it’s stable on that platform.” And to be honest, most of the Linux distros are very stable as well. The same goes for Mac and Windows. We built the binaries so people can download them and install them.

Scott: So, what percentage do you feel like of the QA or of the bugs that are found and posted for you guys to fix, how much is found by internal QA versus how critical is the community to wringing those bugs out of the product while you’re posting the daily builds, moving towards release?

Jay: That’s a good question. I would have to refer to Omer and the MySQL group, they kind of have these stats. But I would say that, internally, probably 10% to 20% of the bugs are found by MySQL engineers or support engineers. And then you’re going to come across this gray border between who’s a user and who’s a customer.

A lot of users are also customers. Sometimes we’ll get a fairly large installation, say, Yahoo Finance or Google, that submits a bug on a specific version of MySQL. But a lot of times we’ll get larger installations from users as well.

We also have something called the Quality Contributor Program, which is for users that are really our bug seekers. They’re actively trying to find edge cases where stuff just blows up. And so we have a program for people like that. But overall I’d say it’s fairly spread out between internal folks finding bugs, customers finding bugs, and then the larger communities finding bugs.

Scott: Got you.

Jay: But we do get a ton of bugs. The majority are small. In other words, documentation type stuff. Whenever I’m giving a talk on MySQL, I talk about community. And I always say that bugs are gold to MySQL. We value them just as much as anything else from the community—especially a reproducible bug case.

Scott: Right.

Jay: Because it saves so much time for the engineers. Run this code and there, it crashes. That kind of thing is gold to MySQL. So, I’m always encouraging people, “If you ever find a bug in MySQL, don’t ignore it. Send it in.”

Scott: That makes perfect sense. Talk about the work that MySQL—I mean, obviously it’s used so pervasively now, and lots of mission-critical stuff is built on it—what things do you do around security, reliability, all of the “itys” that people talk about with software?

Jay: All the “itys.” [laughter]

Scott: Stability, reliability.

Jay: That’s a good… Performanceability. [laughter] Usability.

Scott: Usability, scalability.

Jay: The three things that MySQL always strived for are performance, reliability, and ease of use. Those are the three binding principles of how our engineers kind of evaluate how well we’re doing. Is it easy to use? Does it perform well? Is it reliable? As far as security and stuff, as an open-source project we tend to worry a little bit less about security. There are just so many people looking for security holes in the software, because they can see the source code and look at it. They can see major problem areas and we usually get notified quickly and respond very quickly to those kind of things. Let’s see… Scalability. I’m biased, but I think we scale very, very well. And it’s always something we’re thinking about internally, because performance doesn’t necessarily mean scalability. You can get a hundred concurrent connections for doing web pages or responses at half a millisecond, but if you can get 10,000 concurrent connections at 0.7 seconds, it’s less performance but better scalability. And there’s sort of this constant refactoring process going on. How can we make this better? How can make it scale better. All that kind of stuff.

Scott: Cool.

Jay: Which I’m sure is the same with any closed-source software house and any open-source project as well. You’re always thinking about all those “itys.”

Scott: Right, right. Well, you’ve got a mature product, so you’re not engineering it from scratch to have all of those, but you’re evolving it, and a lot of the work now is more in terms of…Either there’s a well-defined opportunity to rewrite something and increase performance and scalability, or you’re really just — as you add new features — trying to make sure you don’t negatively impact those areas that are already good.

Jay: Right. As you increase the features in the code base, you increase the code complexity, and you always look out for performance regressions because of that. And there’s a way to combat that, but the general rule of thumb is, the more code you add to something, you’re going to impact the performance. So, there’s always this balance. Do we need this feature? Because the last thing I think MySQL wants to become is—no offense to Oracle or PostgreSQL—a database that has a million features that no one uses.

Scott: Right.

Jay: And that’s something that does go through the mind of the software architects at MySQL. Is this a critical functionality that the majority of users are going to use and are going to value, or is it going to be passed over and just slow down the code?

Scott: That seems to be a key challenge of closed-source proprietary companies, is that they really have to guess. They have to shoot in the dark in terms of… First they have to come up with big features, because if they don’t, they can’t compel people to buy the upgrade.

Jay: Right. Which is the opposite of how MySQL sells our stuff. We’re not trying to be this enormous feature-rich database piece. We’re trying to be the best and fastest online database. And so the features that we’re adding are designed for highly-scalable web applications and online databases.

Scott: And I would guess, too, as you open it up to more and more community input, it will become easier to identify features which will be widely used. Because, the worst thing in the world is to write a feature, nobody uses it, but you can’t ever cut it because it’s actually not that nobody uses it, it’s that three people use it.

Jay: Yeah. And this goes back to that, what’s commercial versus what’s community? And I think that actually closed-source software companies have more of a problem with this, in that a large customer really, really wants this feature in there. And it’ll be added into the code base and sometimes significantly affect performance of another piece, but it’s been bought and paid for by a customer and will stay in there. And unless the software is written in a modular fashion, it will impact adversely everyone else who will never use that feature. And I think the open-source model, which tends to lean towards a more modular architecture, can handle that dilemma better.

Scott: And also, in things that are very, very open source, where most of the code is coming from community contributors, there are no features that are being written because somebody thinks someone else will want them. The only features that are being written are, “I’m writing this feature because I need it.” So, that’s at least a little validation that the feature is needed by somebody.

Jay: Sure.

Scott: But, doesn’t MySQL have just exactly the problem you talked about? Because you mentioned that you guys do some nonrecurring engineering.

Jay: Yeah. And that’s the dilemma that all commercial software companies are faced with. Which is why I’ve said as we move more and more into that mix of community input and also making that core kernel much more modular, I think that we can significantly offset the disadvantage of that, or the drawbacks of having nonrecurring engineering work done.

Scott: So, initially, I’m guessing the main driver of having MySQL be open source was just so that it would be used and accepted. In other words, it’s a much more difficult proposition to sell something that’s completely closed-source proprietary that targets Linux as a primary platform. And so, it seems like a lot of companies open-source their software and they derive their revenue off other things, support and that kind of stuff.

Jay: And packaging.

Scott: Yeah, and packaging. Otherwise you’re just not in the game.

Jay: Right. Well, one part of it is the revenue, right? When you look at open source versus commercial, commercial has just an enormous advantage from a revenue perspective because of their control over their product, right? The open-source company doesn’t necessarily have that. From the exact opposite end of the spectrum, the open-source company doesn’t have nearly the amount of cost involved in R&D, QA, and testing that a closed-source company does.

So, the big shift that’s happened is that you’re going to see closed-source companies start to open source products that they are tired of spending money supporting, and let the open-source community take on the cost of that support. Now, I’ve read recently that Microsoft is open sourcing Visual FoxPro, which I thought was awesome. And then I started thinking about it. I’m like, “Well, they’re probably just tired of supporting it. And just give it to the open-source community and see what they do with it.” And I think that’s where we’ll start to see the first major shift with closed source companies that open-source products because they realize that the cost benefit of doing that, and letting that source out there to the open-source community to test and QA and support, is just so much more worth it than keeping an older product in-house that’s really is not making any revenue.

Scott: Well, and one of the places where you see something similar to that is Adobe open-sourcing the Flex SDK. And to them it makes sense because it wasn’t something that they ever sold anyways.

Jay: Right.

Scott: So, it was free to begin with. There doesn’t seem to be a lot of downsides in open sourcing it.

Jay: And there is a difference between free as in no-cost and open source. And MySQL is open source, and free and open source as in free as in freedom. But it doesn’t necessarily mean that just because something is GPL or is open source that it’s free of cost.

Scott: Right.

Jay: And the original definition of free and open-source software really had nothing to do with cost.

Scott: Right.

Jay: Right. So, when I talked about Microsoft or other companies open-sourcing and making free software, I meant it more in the sense of free as in freedom, so that the developers can get their hands on it, and tool with it, and tweak it, and completely change it, and support it themselves. It had less to do with charging for it.

Scott: But it seems to me like a place where companies are looking at open-sourcing products and making them free as in freedom, are places where the product was already free as in cost, or maybe it wasn’t free but it’s just not generating a lot of revenue.

Jay: Exactly. It’s costing more for them to support it than it would the open-source community. And that’s where I think the first round of closed source becoming open source is going to happen.

Scott: So, MySQL started out as being open-source, but developed by a for-profit company. And at this point you’re moving to more of a traditional open-source model. And I’m guessing it’s because as the product has grown, and as it’s gotten more complex, and there are more and more features to it, there’s a need to kind of force it to be more modular. There’s a need to get more community involvement in the development…

Jay: Yeah, and input. Right.

Scott: And just to really shape the direction because it’s not just a single little standalone database anymore, right? I mean, this is a pretty massive product that you have. And, you’re at that point where you need that cost savings that the community can provide. And you need the input, and direction, and expertise that the community can provide to really move the product forward in the best possible way. Am I summing it up correctly?

Jay: Yeah. Yeah, although I don’t think the plan was ever to push it towards the Apache or Linux model. But we want more of a balance, just like you said, so that we can get the benefits of the community. But also, so we can give more back to the community, and have them happier with the product that we’re providing.

Scott: Sure, sure. There’s more buy-in when it’s something that you can actually work on.

Jay: Right.

Scott: And there’s more buy-in when you touch the product, so to speak, I guess.

Jay: Right.

Scott: OK. Well, I guess, what else would you like to say? I’ve gone through the questions that I had. I’ll go ahead and hand you the microphone. And any message that you think is important to get out that I didn’t cover, feel free.

Jay: Yeah. Well, I definitely did want to point out that the MySQL community headquarters is becoming the MySQL Forge website. And that is http://forge.mysql.com. And, right now, what we have in there is a list of open-source and MySQL-related projects in a project directory (http://forge.mysql.com/projects/). A whole directory of code snippets in various languages on how to use MySQL, or coded in C++, PHP, Perl, SQL,.NET, you name it is in there (http://forge.mysql.com/snippets/). And then we also have our public worklogs, which I mentioned earlier. It essentially represents our big roadmap. And it’s broken into specific tasks that are unassigned or assigned to a specific developer. And the developers really want input from the community. So there’s a way of commenting on those work blogs that I highly encourage people that are interested in MySQL to go and give your input to the developer of that specific piece, and let them know what you think about it. So, forge.mysql.com. And then there’s also a huge Wiki that we’re developing as well. That would be the last thing I’d say.

Scott: So then, if people want to contribute code to MySQL, if they want to actually work on it, how set up are you to take community contributions at this point? Or what do you think the timeline is to where you’ll really…

Jay: We’ve accepted, I think, about 80 contributions already this year—contributions meaning one-line patches to semi-large features. So, we’re already set up to do that. If anyone is ever interested in doing that. I would highly suggest going to http://forge.mysql.com/wiki/Contributing.

Scott: Got you.

Jay: And, that is how you can get all sorts of information on the various ways you can contribute, the different IRC channels where the hackers hangout, and where you can get help, how you can build a test case, all that kind of stuff. How you can build locally, and all that kind of information is all in that page?

Scott: Jay, thanks for taking the time to chat.

Jay: Thanks.

Bookmark this: