Webmin 2.0 development road map

Howdy all,

Jamie, Ilia, and I have been discussing a roadmap for the next major release of Webmin, and I’ve made a wiki page with a rough outline of where we’re going for the 2.0 release, and what the rough schedule looks like. We plan one major release per year going forward, for all four of our projects (Virtualmin 5.0 was the first of those annual big releases, Cloudmin 9.0 was the first for Cloudmin, Webmin and Usermin, being much larger, will actually start the cycle early next year).

We need more hands on deck for this project. If you know Perl or JavaScript, in particular, we need your help! Webmin is about a half million lines of code, and we’re a tiny team. Jamie is a genius and a code generating machine, but even he has his limits. If we’re going to bring Webmin through another decade of being one of the the most popular tools of its kind, we’ve got a lot of work to do.

So, check out where we’re heading in the near-term future, comment on what you think priorities should be, and tell us if you can help:


My personal priorities for 2.0 are:

  1. Making it easier for developers to get involved. The Webmin code base is older than some of its users, and has a lot of very old style idioms throughout (some of the code hasn’t seen significant re-factoring since the early 2000s). It’s a testament to Jamie’s code quality that it’s rarely needed poking once written, but it doesn’t lend itself to modification if it is still in a style of Perl that many people have never seen, and no one is writing today.
  2. Making it more provably secure, through static analysis, fuzz testing, better encapsulation and separation of concerns, etc. The recent security issue in the theme was a hard reminder that view and control need to be isolated strictly. We’ve got some big hairy audacious goals in that direction, which will take years to realize(and aren’t on this roadmap as they’ll come in 3.0 and 4.0, over the next two years), but also lots of low-hanging fruit that even developers without a lot of experience can help with. The strictures/warnings project is a great place to get your feet wet on a big Perl project.
  3. More modern Perl. No, this doesn’t mean porting to Perl 6 (yet), but it does mean making use of a lot of really cool stuff that has come into Perl core since 5.8 (our current minimum version), the standard library, and some pure-Perl modules like Moo, Type::Tiny, Try::Tiny, etc., that make working with Perl 5 a lot nicer, and more familiar/comfortable to developers coming from Python or Ruby. For 2.0, our target minimum Perl version will be 5.10.1 (the version shipping with CentOS 6). That opens a lot of doors for new techniques. In a couple more years, we can bump that minimum up to 5.16, which brings tons of great stuff; particularly the keyword API.
  4. More friendly to service-based architectures. This one is a bit amorphous at the moment. I dunno what it looks like, but it’s important for the future. It’s probably a 3.0 goal, but the architectural changes we make in 2.0 will forge a path to those goals.

So, what’s your priorities for Webmin’s future? (We can talk about Virtualmin 6.0 priorities in a few months, once Webmin 2.0 is branched…so, let’s stick to Webmin for this discussion.)