 The previous talk that this actually is implemented in Perl 6, and you can use it now, called junctions. Anyway, what is Padre? What did this work? Yeah, well, Padre stands for Perl Application Development and Refactoring Environment. Of course, this is a really bombastic name, but in fact, this is just a text editor. It's a slightly oversized ego. In order to prove that, I have a slide here that shows how the application looks like. You can see that it basically looks like a simple text editor, a Notepad, or something like this. Anyone here is actually a Perl programmer, by the way. Who is Perl programmer? Just hands up. OK, good. About half of the people. Good. So this is how actually the application looked. It doesn't always work. How the application looked about a year and a half ago when we started the project. This was basically the first release. Since then, we added a couple of more features in order to turn it into a real IDE. So these are the features that usually you are expecting from an IDE, or at least people writing Java, or C++, or programming in similar languages, are expecting. And these IDEs can actually provide this for both Perl 5 and Perl 6. The IDE also has about 56 plugins at the various stages of development for various additional features. And this is how it looks like, or actually how it looked like a couple of months ago. This is 047. That was released, I think, about two months ago. As you can see, this is a German version of the IDE. We have it, I think, in like 15 or 16 languages. And you can see that there is some more complexity in there. But the basic features are the same. So when you open it the first time, it still looks like just a notepad and allows people to write code without thinking about other things. So when I'm talking about a project or thinking about a project, I would like to see where it can fit in the user space or market in some terms. So I ran a poll in October 2009, a couple of months ago, to find out what editors or IDEs people are using for Perl development, writing Perl code. So their answers were really interesting. And within just three days, I got more than 300 answers. And most of the people were actually saying that they are using either VI or Emacs. Apparently, they were using Linux and Unix. And the percentage of answers was 47. So you can see that quite a lot of people are using these two editors. So the problem is, of course, that those are only for the geeks. And Padra is not for geeks, really. So Padra is for the normal people. So it leaves for us about 53% of the population, which is sort of OK. Of course, this little poll also proved us something else. We know now that the normal geek ratio in the Perl community is about 1.12. By the way, I'm a Veeam user. And the Padra user, which probably puts me in the slash, but I don't know really. Anyway, in the poll, we saw that there are a couple of other less geeky editors for Linux and Unix. And they got about 10% of the vote. On Microsoft Windows, there are the so-called programming editors. Some of them you can see here. Some of them are commercial. Some of them are shareware. Some of them are open source, actually. They got 21% of the vote. On Macintosh, you have these two that got 7% of the vote. As I understand, they are the best thing on Earth, just after Belgian chocolate. But I don't really know, but I never try to use them. So some people might know. And there were two IDs that got votes. Commodore ID, which you might know, it's developed by ActiveState. And it's a commercial ID. It costs something like $300. And Eclipse, which is open source, and it has a plug-in called Epic, which is for Perl development. They got about 12% of the answers, which really means that really a low percentage of the Perl users are actually using something like an IDE. And that's something we would like to change with Padre. So there were about 3% of people who answered Padre, the Perl ID, which is, of course, a bit skewed because probably all of the Padre users have answered. But I was happy because we got more than 100 answers just for Padre. Actually, we got 101. So there is some Padre user base already. So what is Padre? Padre is an IDE for Perl. And it's an IDE written in Perl. So you might ask, why would I write an IDE in Perl and why would I write an IDE for Perl? Well, the four question is, there are a couple of reasons to write an IDE for Perl. First of all, there are lots of beginners who are starting to learn Perl. And they need something to help them more than the VI or Emacs would help them or Notepad or something like this. They need more help in the language. They might need a debugger. They might need language help and so on. And an IDE can do that very well. There are also a huge other segment. People using Perl relatively rarely. There are tons of people who are using Perl two, three hours a week. So they might have been using it for three, four, five years, but still they are not experts. They are not Perl programmers or application developers. And they still need some more handholding than someone who's writing Perl for his main income. And then even them, even those people for whom Perl is the primary programming language, they might need an IDE because earlier there were no real refactoring tools in Perl and Padre is changing it. Padre already has a couple of refactoring tools. And when you're writing a large application, you might like to see your whole code base at the same time. You would like to see the classes and so on. So IDEs can fit to that place as well. But why would I write it in Perl? Well, we know Perl and our users know Perl and that means actually that every user and that's actually a rare case, even in the open source world, every user is a potential developer. And in fact, we see that about half of our user base have already contributed to the project, which probably will go down as the user base grows, but it's still a nice percentage. So when I started the project and basically that's what I think I wanted to talk about, I faced a couple of problems. The first of all, that most of the Perl programmers, as you could see, are using either Linux, Unix, or Macintosh and they're not really aware of the problems of Windows users, for example, that they don't have a usable shell to get information from there and so on. But even them, but they are also usually not that aware of people, of problems people facing that are coming from Java world or the C++ world and so on. Also, the hardcore Perl developers are using or Vi or Emacs, as you could see from the poll. So it means that it will be hard for me to get people from that community to contribute to the project because Vi, Emacs people, they won't change their editor anyway and they don't even understand why anyone would need anything else than them, than Vi or Emacs, respectively. But it's okay. Anyway, when I ask people about this, about IDs and talk about this, then I get all kinds of answers such as Perl does not need an IDE or a language is bad if it needs an IDE to write it in. Well, I was wondering a bit about this because I was thinking if I write an IDE, does it turn the language into be bad or but I decided that I don't have such a power. Anyway, as the last thing to say, they usually say, ah, yes, but there is already Eclipse and Epic and they use that. Well, we have more problems actually that I'm not a good programmer. So that is a slight problem for writing an IDE and actually an IDE, as I thought, it's gonna be a huge project. Actually, as it turned out, it's very bigger than I thought. Anyway, how do you solve this problem that you don't know how to program really? And you need to read a huge application. You generate community support. So let other people write it. So the first thing, one of the first things I did, I created a plugin system that will allow people to play with the project without actually getting involved directly in the project which let people play around with the tool and then get involved. A little bit of history. I started the project in May, June, 2008. The first public release was about July in 27 July and then the first public appearance about the project was in Yapsi, Europe, which was in August, 2008, which is the European Grassroot Conference of Pearl. That was a year and a half ago. Today, we are after release of version 0.56. We had more than 10,000 commits in subversion and more than 50 developers contributed to the project. As you can see from this graph taken from Olo, we have about 15 developers every month contributing to the project. So it seems that the project took off quite nicely and we have a contributor base. So what did happen in Yapsi, Europe in 2008? It was in Copenhagen. I gave there a lightning talk. And lightning talks in the Pearl conferences are five minutes long, so you don't have to, you don't talk so much. The main point what I made is I gave a list of all the features I would like to have in Padre and then I told the people it will, everything will be there if you write it. And the just two or three hours after this talk, I could add the first contributor to the project. So it was for me a successful talk. Then this is the place for the promotion. Actually, Yapsi, Europe, 2010, is going to take place in Pisa in Italy in August and if you'd like to hear a bit more about it, there is a Pearl stand in the AW building and we are happy to tell you about that more. Anyway, so how were we doing project management? In many open source projects, the open management, project management is quite strict. We took a liberal approach or I took a liberal approach in the beginning and then other people took it with me, giving out coming to be basically to everyone who asks. The box project, which was the first implementation of Pearl 6 took the same approach and it took off really nicely. Same with Padre, but actually it will, at one point we'll have to stop this because when the project gets big, it's getting a bit crowded there. Anyway, other thing that we were doing is adding features, even if they weren't full, even if we knew that they were full of box with the hope that other people will come in and fix those bugs and then improve the project and that's actually how it happened and most of the features that are in Padre now have been rewritten about two or three times already, which is really good. It means that we can gain a lot more commit bits. Commits. Other thing that I've been doing is relying on existing code. So for Pearl, it's good because we have CPAN, the Comprehensive Pearl Archive Network that has about 20,000 packages for all sorts of things to be done and they have automatic tests. So a large part of this is a quite high quality and good code, so we were using it. So how much Padre was using is CPAN. CPAN actually depends on 83 packages within CPAN and there are five more packages that we are using just for testing. But these packages, these CPAN packages, libraries, they also depend on other things. So in the end, we have about 200 dependencies just for Padre and if you take in account all the plugins of Padre, we easily reach the 500 dependencies, which is really good and code reuse is really good, but it actually has several faces. Yes, the good, the bad and the ugly. So what is the good? The good is that we don't have to write that code. The bad is that we don't control that code and why is the mouse there? And the ugly is that we have to install that code and we gave a talk about the distributions and stuff like this and this is really fitting there because we know that in order to gain market share, most, much more important to be easy to install than to have high quality. It's an anonymous proverb. And he say, anyway, we have to think about distribution, how we are going to distribute our code or project. So the first choice is obviously for us per project, per developers and per project is to distribute the code on C-PAN in source code format. That's the standard way to distribute packages. It's also a good way to distribute applications because then all the per programmers who are already familiar with C-PAN know exactly how to install it and we don't have to have any other explanation. We already have the tool chain in place, we already have the testing system in place so it's quite a good way to distribute source code. Then, of course, in order to make it more available, we need to be able to package into distributions. So really early in the project, I think after I released the first public version, I started to talk to the distributions. There are two mailing lists, the Linux Fedora and the WM mailing list for distributions and I asked them to package Padra. This is the list where it's already packaged. And lastly, we created downloadable standalone binaries for the major operating systems. We have for Microsoft Windows, MSI and ZIP. For Linux, we have a turbo that you just un-tar and run it and there are other things and the last thing I have to say that you talk about it, unfoss them. Sorry, that was a bit fast. Thank you very much. Thank you.