The story of VLC’s rise to fame.
Rich: I’m speaking with Matthias Ableitner, who is a developer on the Spring RTS Engine.
Rich: Thanks so much for speaking with me. Could you tell us what your project is?
Matthias: It’s hard to say. It’s not a single project, it consists of many small projects. We have some game developers, we have some engine developers. There’s also some infrastructure, like a download site where game developers or map developers can upload their stuff and the lobby client can automatically download the files. Players can use the lobby to directly connect to the lobby server, and the client can automatically catch these files that the game developer made.
Our project tries to make a really good platform for strategy games.
Rich: This is a framework – an engine for building games on top of. Is that correct?
Matthias: Yeah, that’s correct.
Rich: What games are currently available on this platform?
Matthias: There are about ten well-maintained games. It’s difficult to say, as there are also many modifications of those games. On the biggest download page there are many 50 games, but some of them are unplayable.
Rich: How long have you been working on this project?
Matthias: I joined the project in 2010, and I’m the newest developer. I had contact with the game developers, and I wrote some stuff to the content platform – to Spring files. So I know many of the people who made the games, too. It’s a very nice and big community.
Rich: When someone simply plays a game it’s not obvious to them the complexity of what’s behind that – the game server, the game engine, all of the different parts that go together for that. As someone that just plays the game, it’s amazing to see all the layers of complexity that are behind it. The Spring RTS project itself is the game engine, is that correct? And the games themselves are available elsewhere. Am I understanding that correctly?
Matthias: If you want to be exact, Spring is the engine only. Spring was first a game called T. A. Spring.
Rich: What things are in the future for the project. What are you goals?
Matthias: Our current biggest goal is to make it easier to use. We have some small improvements. The biggest one on Windows, but it’s difficult to make it easy to use on Linux, because the engine has to be exactly the same version if you want to play online. We currently make many updates, and if want to make an update on Ubuntu, for example, first a package has to be built, and this takes time, and it’s hard to make it automatic for each platform.
Rich: If someone were interested in becoming part of your project, what could they do? What sort of skills would they need?
Matthias: It depends on what he wants to do. He can make a game, or he can help with the engine.
Some people wrote an AI for an exam, or for University.
We really need help in the engine currently, I think, but it’s very hard to get close to it. It’s very complex. We have about 300k lines of code. That’s not a few, so it’s not so easy to handle and understand.
Rich: I’ve noticed over the last few months that there are many different game engines on SourceForge. What distinguishes one game engine from another? Is it the type of game?
Matthias: Yes, there are many different engines. Spring is one of the few engines that works in sync. Floating operations are on calculated the same on all platforms. This means that only the commands of players are transferred over the network. This allows us to have many, many units on a game. Many other engines only transfer a few of the game states. There’s a game server and the game server sends position of units directly, and our engine transfers only the commands a player makes. This allows us to have many more units on a map, or on an online game. That’s a big difference. This is why it’s an RTS engine.
Rich: What do you in particular really like about working on this project?
Matthias: I enjoy that when I make something new, I can be sure to get some feedback. Often it’s not positive, but it’s awesome how much feedback you get. Sometimes it’s too much, but it’s really nice.
What I really like about the project is that it’s so easy to try out new things, for game makers. You can grab some already-written script and modify it, and easily make your own game with that. Or modify an existing game. It’s really nice. As we have a full infrastructure for that, game makers can focus on the things they want to make. I think that’s something really special.
Rich: Thank you very much for speaking with me.
Matthias: Thank you.
This week, we feature a new list of projects, ranging from a 3D planetarium to an econometrics library. As always, I’m impressed by the breadth of projects on SourceForge, as well as the professionalism these projects put into their works. Thank you all for being part of the SourceForge community!
Stellarium renders 3D photo-realistic skies in real time with OpenGL. It displays stars, constellations, planets, nebulae and others things like ground, landscape, atmosphere, etc.
SystemRescueCd is an improvement of the gentoo live cd. It aims to provide an high quality bootable CD-Rom, with all system utilities that can be required to repair your system.
Luminance HDR is a graphical user interface (based on trolltech’s Qt4) that provides a workflow for HDR imaging.
A slick, intuitive web based photo gallery. Gallery is easy to install, configure and use. Gallery photo management includes automatic thumbnails, resizing, rotation, and more. Authenticated users and privileged albums make this great for communities
GNU Regression, Econometrics and Time-series Library
Ever wanted to get rid of Outlook ? DavMail is a POP/IMAP/SMTP/Caldav/Carddav/LDAP gateway allowing users to use any mail client with Exchange, even from the internet through Outlook Web Access on any platform, tested on MacOSX, Linux and Windows
Wings 3D is an advanced subdivision modeler that is both powerful and easy to use (inspired by Nendo and Mirai from Izware).
The Pure Data (short Pd) project on SourceForge unifies the extensions (or externals) written for the Pure Data Graphical Computer Music System written by Miller Puckette with contributions from many others.
This application creates off-line atlases of raster maps for various cell phone apps on Android, iPhone and WindowsCE as well as GPS devices (Garmin, Magellan and others)
When I first interviewed for the job of “Community Growth Hacker”, I was told that a major part of my job was helping SourceForge projects be “successful.” Naturally, I asked what “successful” means. I asked this of our CEO, and of my boss and co-workers, and got a number of different answers. I also asked the question of colleagues in Open Source, and got other answers there.
In the last few months, I’ve asked this question of people on a variety of SourceForge projects. I ask the question in many different ways, but I always ask it. The answers vary greatly.
This shouldn’t be too terribly surprising, of course. Open Source is driven by people who are volunteers – they’re working for a wide variety of different motivations, and not just for profit. So their definitions of success, too, will vary widely.
Some value fame (ie, popularity, large numbers of downloads, large user base). Others value utility – does the project do what I set out for it to do? To others, success means frequent releases, or quick time-to-close on tickets. And to others, success means happy customers or users. All of these are important, but which one the project admin values most will no doubt shape their attitude towards building their product and community.
Frequent readers will no doubt note that two of the authors of the paper are also authors of the heartbeats paper I mentioned back in February, which is how I came across it.
I wonder if attitudes have changed at all in the 9 years since this paper was written. My experience is that they haven’t. People still do Open Source for an enormous variety of reasons – profit, fame, resume fodder, utility, boredom, interest in a particular topic, desire for community, altruism, and many others.
What do you think? Why do you work on Open Source? How do you know when your project is successful?
Rich: Today I’m speaking with Alan Ezust about the jEdit project
Alan: I’ve heard it pronounced that way. Sometimes people say jEdit. That’s what I like to say when I’m using it in everyday speech. Which isn’t all that often, really. Most of the time it’s all written.
Rich: Tell us about j Edit. Or jEdit, if you prefer.
Alan: jEdit is a programmer’s text editor. It’s incredibly customizable and extensible. Right now there are more than 200 edit modes for different languages, and you can define each one in XML format, so we receive contributions of edit modes from the community. And they can be even non-coders. You can extend this editor with plug-ins. I suppose that’s one of the reasons why it’s famous. And you can download them dynamically through the plug-in manager, which is very convenient. It is written in Java and Swing. I suppose you could say it’s a little like Eclipse, in the sense that it’s language neutral, but is it much more light weight and fast. And you only have an editor. You don’t get an IDE unless you install certain plugins.
Rich: What’s the timeline of jEdit? When was the first release?
Alan: I actually had to ask Slava directly this, because some of the pre-Sourceforge history is not available to us. jEdit version 1 came out around August 1998. So that makes this program 13, turning 14 this year.
Rich: That’s the same age as my daughter.
Alan: Releases to version 2.2 were just zip files that Slava published on his free Geocities page. Some time in ’99, he hosted his code in CVS on the site called the Giant Java Tree, or GJT.org. And that lasted less than a year before he moved to SourceForge, and that was December 1999, where it’s been ever since.
The first release on SourceForge was jEdit 2.3pre2, in early 2000.
Rich: And how about you? How did you get involved?
Alan: I’m not one of the original developers. Originally I was just a user. The project first became known to me around 2002, and by that time jEdit 4.1 was considered a mature product. It has this brand-new integrated plug-in manager, which allowed users to download and install plug-ins dynamically from a repository on-line. And there were over 100 contributors. In 2003, there were about 50 plug-ins available. Now there are over two hundred. There’s a database and web service that provides plug-ins to users dynamically, and that’s actually another project on SourceForge, called jEdit Plugin Central.
Originally I was just a user. I needed an XML editor to write my book. jEdit worked well for me at the time. I was collaborating on the book with my dad, three time zones away. I had to show him how to use it, and I also had to deal with his bug reports. I was opening lots of bug reports. He was too lazy to do it himself. Some of them were getting closed, but disapointingly few. So I joined the developer team in 2004, and that was apparently just before Slava, the original developer, left.
I started by fixing a couple of the bugs that were annoying us the most. These happened to be in many different plugins, and some even in the core. So I had to contact not only Slava but many of the developers to personally ask them to either close my bugs, review my patches, or for permission to modify their code. I found that after giving a little note, they were very responsive.
Most of my work was to just make jEdit more keyboard friendly, since I don’t like having to use the mouse. Once I got commit permissions, I was compulsively fixing documentation errors that I noticed. The documentation was in XML, and I was developing and testing the XML plugin, so I could do both the documentation development and testing at the same time. A little later I subscribed to the commits mailing list.
jEdit has a bunch of different mailing lists. If you are a developer, you have to join both the developers list and the users. That’s just a rule. It’s optional – you can join the commits list as well, and that just shows you who commits what, and when. It also shows you the diffs. Just reading these every day, I found it very educational, and sometimes even exciting to watch. If I saw someone was working something I was interested in, I’d be the first to test it and give feedback.
Alan: At some point I became involved in the plugin packaging and release process. As part of releasing new plug-ins, I would test the submissions myself. And this resulted in more interactions with other developers, because I would find little things they would want to slide in right before the release.
I became project admin of both jEdit and Plugin Central around 2006, and after that, I started promoting the most active contributors to project admins. These days most of my time is spent applying other people’s patches, merging bug fixes, and helping to close old tickets. Sometimes I do a bit of coding, but mostly it is in plugins.
Rich: What kind of rewards do you feel that you get from your involvement in jEdit?
Alan: It’s funny – I get a bit of an emotional lift. It’s almost like a caffeine high, whenever a ticket I open gets closed by someone else. And I also like closing tickets myself, so it just sort of feeds upon itself that way. These days I do it mostly as a way to procrastinate working on other things, or even as a way to unwind. Most people I know do their social networking on FaceBook, or maybe Google+, but I’ve been hanging out on SourceForge for the past few years.
Rich: How large is the project – how many developers are there on the project.
Alan: That’s a good question actually. If you look at the project, you’ll see that there are more than 200. I don’t consider myself one of the main developers actually. The amount of code I write is relatively small, compared to Dale, Matthieu, and Shlomy, who are the top three contributors at the moment. Right now there’s a second generation of developers who still write new
plug-ins, fix old ones sometimes need to modify the core to accomodate them. So I’d say there are about five regular contributors, ten semi-regulars, and another 25 of what I call irregulars. They make contributions once in a rare while, and it’s usually a surprise.
But the rest are probably inactive. We have a couple developers who are adding features to the core, but whenever possible, our development is focused on the plug-ins. And sometimes that’s controversial. Some people think we should package jEdit with a core set of plug-ins. But agreeing on what that set should be, or managing a special distro of jEdit, is something no-one has stepped up to volunteer for yet.
We had a lot more admins, actually, and I just de-admined six of the inactive ones. Pretty much all of the original developers who were working with Slava are no longer active now.
Rich: I’m very interested in project governance models, and I’m curious – when you de-admined these people, was that after a conversation with them or did they simply not respond? And more interestingly, if they were to come back, would they have to reacquire their karma? Or is that always there?
Alan: I believe that all of the people that I de-admined, if they ever wanted to come back and contribute again, all they’d have to do is ask, could I be admin again, I want to be involved, and I’d change it like that. Their contributions are already very clear, if you look at the change logs. Their karma will not expire.
Rich: You mentioned you don’t like Swing a lot. What do you prefer?
Alan: I don’t to a lot of Swing these days. I do most of my work in QT, which is a cross-platform and cross language toolkit. All of the Swing work I do is just for jEdit. But it keeps me up to date on Java and developments in that language world.
Rich: Tell me what’s been happening recently in jEdit.
Alan: Well, we’ve been on a bug hunt. If you just look at the tracker statistics for three months – from November, December, and January, you’ll see 245 opened tickets, 593 closed. I am very proud of those numbers. I was inspired by reading one of the articles that was published earlier last year by SourceForge, about – to see how well a project is doing, you can tell pretty well by looking at the tracker activity. Ours was relatively stable. The numbers of opens and closes were pretty close to each other over, for years up to the bug hunt. But then I started triaging a whole bunch of old tickets, and other people joined in, and it became a frenzy.
jEdit 4.5 was just released at the end of January 2012. It has a lot of bug fixes, performance improvements, large file handling, and code enhancements, and a system desktop tray icon.
But to me, jEdit 4.5 already seems like old news, that’s been frozen, and in a stabilization phase for almost a year now. We’ve been furiously at work on jEdit 5.0, which is our next release.This has more performance improvements, edit modes, bug fixes, UI fixes, and a new feature we call “Keymaps”, allowing you to name and customize sets of keyboard shortcuts. With jEdit 5, you can easily switch between an “emacs” or “MacOs” keyboard mapping, or create your own. I am hoping we can release 5.0 before the end of 2012.
Rich: What interesting plugin developments have there been?
Alan: Most of the development is actually in plugins, so you don’t get a full picture of what’s happening unless you include that. Of the 200 plugins that are available now, 50 of them have been either released or updated in the past year.
There are some core plugins, the ones that most of the users are using.
Rich: Now, when you say core plugins, these are not shipped with the base, or they are? You mentioned that earlier.
Alan: There are no plugins actually shipped with jEdit when you download the installer. It’s pretty small – about 2MB, package. When you install plugins, they are always coming down off of the network. But we have a few that are just so important, and they are used by all of the core developers, that we pretty much treat them as important as the core.
The main ones would be Console, SideKick, and ProjectViewer. Each of these have ways of being extended. There are plugins that are extensions of plugins.
For example, SideKick is a tree that shows you the structure of the file that you’re editing. It has language parsers for different languages.
ProjectViewer manages a collection of files. But how do you decide in a tree of directories, what files get included? ProjectViewer has ways of being extended that support different revision control systems. So you only get the files that are under revision control.
Then there’s Console, which gives you different command line tools and shells.
There are other plugins that are under heavy development now: SVN, JDiff, Navigator, Character Map. Lucene Plugin gives you indexed search through your projects. Marker Sets, which is way better than bookmarks. TaskList, which is up to date and working very well. JavaSideKick is making lots of improvements, especially with completion. XML now has hyperlink support so you can click on links in your XML documents, and it will open the linked document at the right spot. Updater updates jEdit itself.
Then there’s “Optional”, my first plugin, which was just integrated into the core as of jEdit 5.0. It’s just a UI improvement which saves a lot of mouse clicks.
Rich: What interesting things have you learned as a jEdit developer?
Alan: It is because of my work with jEdit that I had to learn how to use CVS, SVN and later Git. And it is those tools that make it possible for me to do all the remote work that I do now. So indirectly, I have jEdit to thank for my current “work at home” situation.
Rich: What sorts of things would you like to see in jEdit’s future?
Alan: Each developer has their personal idea if which way it should go. I am interested in developing a toolbar API so that plugins can provide toolbars that can be enabled or disabled using a common UI, and saved/restored along with the docking layouts.
I would also like to see HTML5 completion and validation – so that we can say jEdit is truly an HTML5 editor. HTML5 is really big, and I think it’s in all of our futures. I suppose that would be an extension to the XML plugin.
I really wish someone would fix up the Python edit mode, and update the Jython related plugins. JPyDebug used to be quite a nice python debugging environment but it is totally out of date now.
For Console, it would be nice if we had a real VT100 terminal, perhaps also supporting tabs. I don’t know if I will do that myself, but I am thinking that we might be able to incorporate jcterm, another sf.net project, and reuse that for the terminal part.
I hope more people use jEdit and contribute to the project.
Rich: If I wanted to contribute to the jEdit project, what kind of opportunities are there for that, and what skills would I need to contribute?
Alan: A strong sense of â€œattention to detailâ€ is important. Also, good communication skills, since a lot of the work for me is in composing well-thought messages in the trackers.
If you find a new bug, search the existing tickets, see itâ€™s really new, and can create a good description for it that makes it easy for other devs to reproduce, you are making a valuable contribution to the project.
If you are a coder and use jEdit, you probably can already think of a bunch of things youâ€™d like to do to it. Whether itâ€™s in a separate plugin that you write yourself, or working on someone elseâ€™s code, is pretty much up to you. There is a huge amount of flexibility in that sense, with a project like jEdit.
Rich: Thanks so much for talking with me. I wish you a lot of success in your project. It sounds like you’re already having a lot.
Alan: It was nice talking with you.