Hacker News new | comments | show | ask | jobs | submit login

The whole page is images, and it's a non-existent product, it's just a theory/proposal.

Buried in the text is it would be a fork of wordpress.

Net is filled with that sentiment, but it never takes off:


If you want to replace wordpress you need a modern rewrite, not a fork.

The #1 problem of wordpress (among many) is it loads every darn thing on every darn page and it's now a godzilla of a program so it's becoming a huge nightmare. A cache miss in WordPress on a busy server is a horrible, horrible thing.

You cannot escape that problem by a fork.

This would absolutely be better solved by an entirely new application, written from the ground up.

And the whole-page-is-images thing really bothered me too. Some nice designs and interesting ideas for sure, and knowing CSS isn't a prerequisite for being a designer, but damn, I have some doubts about the understanding of the technologies here.

Which is probably exactly where the concept of "forking Wordpress" came from—a misunderstanding of exactly what that would entail.

Modern rewrite is what's needed, definitely. But don't call it anything related to Wordpress. Don't need to.

I've been committing code to the core WordPress codebase for 3 years, so while I'm not a PHP developer - I have some idea.

Perhaps one thing overlooked in the argument for fork vs new build is that there aren't a huge number of developers with the skills to make this happen who would do it entirely on an Open Source contribution basis as opposed to, say, a startup basis. Appealing to existing WordPress developers, businesses and users, as well as cutting down time to ship first working concept, are (in my mind) some important arguments in favour of a fork.

I'm relatively new to the WP scene, and already its totally clear that WordPress is tolerated because it has a vibrant ecosystem. Getting to keep that is way bigger factor in uptake over the next five years than anything a rewrite could deliver.

I think you could gain momentum surprisingly fast with a new project if it offered a quality alternative. (I say this as the author of a CMS in another content-type space which has done that fairly well)

First, let me say this: I love what you've done with the Ghost design. I think it's clean and useful. More on this below...

I am one of the early contributors to WordPress (you'll see my name on wp.org's About page near the bottom), and one of the founders of the Habari Project. We started the Habari Project for many explicit reasons, but in part because the curators of the project (Automattic) were not behaving in a way that we felt was beneficial to the community they had begat. So let me tell you a little about our project:

Not only is the Habari Project an entirely Open Source platform, but it recognizes participants in the project appropriately based on their contributions, something that I did not observe during my tenure working on WordPress.

Habari employs the Apache Software License, which is more permissive than WordPress' GPL. Want to develop a plugin or theme? Is the code tainted by the GPL? In WordPress, I don't really know for sure what parts can be redistributed, if any. In Habari, you can sell your themes and plugins for profit if you want to, or contribute them back to the community -- most themes and plugins so far have been.

The passion of the Habari community for producing good, documented code has (in my mind) been one of the driving forces behind WordPress' "recent" adoption of similar policies. The quality and friendly tone of assistance I get from people who know about Habari has been consistently orders of magnitude better than anything I've seen come out of WordPress, which is a characteristic that everyone working on Habari strives to maintain in the project. One of our guiding principles has been to be a project that is useful for web development education; We've seen a lot of people join our project and learn how to code well, both in the method they use and in the collaborative environment our development often lives in.

We've accepted a policy of keeping up with as current a deployment of technology and standards as our core users can stand. We recently adopted a PHP 5.3 minimum version, and I'm pushing hard to take that to 5.4. Habari simply does not run on PHP 4, and never will because it's no longer secure. We code for HTML(5). We're using CSS3. Our roadmap (admittedly difficult to find online) includes PSR-0 and namespace adoption to more easily integrate with vendor libraries. The use of current technology and techniques is really good for developers, and a refreshing change from projects that insist on supporting every old (insecure) server architecture out there.

And I'm currently making a living (yes, paying the mortgage) deploying Habari as a CMS for clients. It is viable. It is open source.

I know first hand how long it takes to build a working product with a small community. We are admittedly behind in our implementations of some features that WordPress was able to steam ahead with due to their larger community. There are also non-dev areas like marketing where we could use some work. We've been trying (albeit weakly) to lure those kind of contributors to the project.

We had a talented designer help us with our current admin design, and one of the things people comment on most about it is how it's not as cluttered with st as WP's. I like the design you've used in Ghost because it's similar to ours, yet modernizes, and I think our community would like it, too. We've been talking heatedly about a new admin design for our next release...

Habari may not be the thing for you, but I do encourage you to take a look, visit our IRC channel on freenode, and take from it what you can. If you still want to try to bend a WordPress fork, I'm at least interested in the story of your effort and struggle. And if you want to chat about why we started over (though I think it's obvious, maybe it's not to everyone else) instead of forking, or why a new project with a handful of addons (compared to a competitor) can still be a contender, I'm happy to chat. Here we are: http://habariproject.org/

I looked at the code, installed a test site and read the Wiki. Is this project on a down low at the moment with only 19 commits and low activity since late last year ?

Also, when you mention that you manage to pay the bills with development of habari powered sites, do you draw from a community need for habari developers or are these clients that you persuade to use habari ? I'm curious about the overall community and where it's going.

Thanks !

In my work, clients mostly need a site built to perform a specific function, and if Habari fits that task, I use it. There isn't an explicit demand for Habari developers, but there is a high demand for sites that Habari is suited to produce, which overlaps a bit with WordPress' capabilities.

As others mentioned, the main habari/habari repo commit count is low because the main development doesn't happen there, but in a submodule'd repo, habari/system. The purpose of this is to allow you to easily fork the main repo to add your own plugins and themes to it, while the submodule continues to pull from the system repo. It's very beneficial from a maintenance standpoint.

I'm not sure how to explain the community. My involvement has been nothing but beneficial for me, and it has been a similar experience for the people I know the community has touched. Development has been reasonably continuous, as you can see here: http://www.ohloh.net/p/habari

The work happens at https://github.com/habari/system, which is very active.

I can't answer for @ringmaster, but for me it's client work, though it's a sideline to my main job at the moment.

Code is maintained in https://github.com/habari/system

+1 for Habari, especially for keeping it relatively sane compared to WP.

http://octopress.org/ is essentially something written from the ground up that addresses many of the concerns in ghost, but that doesn't mean its the solution.

Because WordPress is built on PHP it has a wider array of deployment options, including many low-cost options, while maintaing a relatively easy to use sheen.

I think it makes sense to evolve WordPress to merge the benefits of something like octopress with WP.

I love it, been looking for something like this for a while. Thanks for the link.

No need to either fork Wordpress or write anything from the ground up – build it on top of ProcessWire (http://processwire.com).

A small distributed team could probably build basic Ghost functionality in a couple of weeks based on PW.

I see no reason why it can't be a fork. You may not want it to be a fork, but that's different from it needing to be a new project.

There is a very popular piece of software that millions of people use today that was a fork of a large, sprawling suite of a mess of several programs that used an actual Godzilla as its mascot: Firefox.

And, if I recall correctly, Mozilla had a hard time keeping it at the same level of WebKit/Chrome, partly because the code was too old and needed a lot of changes.

One should be careful not to frame a new product as an engineering problem. Users don't care if it's a Wordpress fork or a rewrite. Users care about the product experience, what it delivers, benefits, etc.

Having said that, you may be right.

Slow loads are an individual implementation problem as much as it is a Wordpress problem. Wordpress will happily give you more than enough rope to hang yourself with (e.g. Recent Comments), but even slightly savvy engineers should be able to avoid the pitfalls and AJAX expensive queries when needed.

I agree that Wordpress should have saner defaults but it is not impossible to build a fast site with it.

I'm not talking about front-end, I mean back-end.

WordPress is over 100 files of code 3mb size, loading on every page, BEFORE plugins.

It's impossible to build an active, non-cached site with it.

I have 100% dynamic php forums running side-by-side with wordpress and they are completely uncached - for WordPress that's impossible at the same load.

I used the sociable plugin (like/tweet/+1 buttons). Out of extremism I tested under elinks, saw some weird empty ul/li hanging around, inspected the plugin config and then went into the code. The latest release at the time was barely beta code, large spans of deadcode, copy/pasted pages-long loops that were 90% similar. Wordpress plugin pages quote millions of download for this plugin. Who needs quality ?

(100% totally non sarcastic here)

This is what I love about PHP devs. Imagine how much effort it was to write that. The author may not have have the chops to refactor that into something elegant, but he wanted it done and was perfectly willing to just do it the hard way and FUCKING SHIP IT, warts and all. Its easy to laugh at code after the fact, but you can't argue that a ton of people aren't finding the author's work valuable.

I think there's a false logic present in arguing that "lots of people use it, so it's ok even if it's shit." Apply this same argument to one of several poorly coded plugins that have introduced basic security vulnerabilities and had widespread adoption. I think this is even worse when there's no commitment to improving it.

I find it curious we don't necessarily aspire to quality; and I think we should. I'm not happy just FUCKING SHIPPING IT.

Sure, but "working" is a perfectly reasonable lower standard.

Allowing for introducing security vulnerabilities is not at all "reasonable", IMO.

How are end-users supposed to judge whether they just blew an enormous hole in their site, by selecting a plugin from the repo?

Since there are always bugs, all code is an opportunity for security vulnerabilities. Users take their site security into their own hands whenever they have to trust others' code, as well as trusting their own coding skills (if applicable).

Time to reflect upon a classic of the genre: http://cm.bell-labs.com/who/ken/trust.html

There is an entire WP ecosystem of people having to judge whether they blew an enormous hole in their sites by selecting one of the zillions of plugins available, why is this one different?

I didn't mean to imply this one is different.

But with web programming, if you're not good at it, but you have the perseverance to bash on code until it's "good enough that it works" (which is admirable, don't get me wrong), there's a very high chance it's got some major holes.

This is a real consideration to me, cause I'm working to teach kids technical computer skills, including programming. If I'd teach them PHP, I'd have to wall off the server, because many of their projects are bound to be full of holes, and we can't take the chance that one of those would affect our organisation's website. It's volunteer-based, so there might not be money to get a separate hosting package. Same if I were to give them all their own WP install, some of the projects are going to be forgotten, and I'm not going to be the one making sure they're all being kept up-to-date and secure for the rest of their lifetime.

And that's a cool article you linked. I already knew it, but for those who don't: it's worth reading, check it out!

Sure, can't refute that. However it's the same mentality that allows the same, basic vulnerabilities to persist throughout the years. The code basically works so sod it, who cares.

Of course, I fall short of offering a solution, because there is none that doesn't imply writing bug-free code (impossible if it's not trivial); spending inordinate amounts of our spare time vetting this code; or otherwise stopping people from learning in the first place. The other one is to tell people not to use these plugins, or to be more careful, but they need to know what's currently'safe' and what isn't.

I just don't like the mindset that 'shipping' code is the be-all and end-all when as masters of our craft (hyperbolic?) we should at least aspire to more than 'good enough' or 'working', even if it's unattainable.

i'm reminded of one of my favourite programming blog posts ever, "slumming with the basic programmers" [http://prog21.dadgum.com/21.html]. i reread it every so often, just so that i keep that perspective in mind.

Agreed, and my question was half sarcastic / half pragmatic. But I don't know where I stand on this issue. Answers lie somewhere in the middle, and to me, this case was quite out of balance.

Yes, this is could be a much better project if it was written fresh, and preferably in a different language altogether.

PHP has the big benefit of being deployable anywhere. Without that fact it is unlikely that projects like Drupal or WordPress would've taken off as they have.

Newer languages aren't? Every linux distro that matters (including BSD, Gentoo, and others with a ports system), heck even Windows, has a full Rails stack that's about two commands away from being fully set up.

Unless I misunderstood what you mean, here :)

Sure, you're right. But i suspect that 95% of all WP installs are by non-techies on shared hosting, that very rarely have Rails or Python support.

Yes thats the way to create great new products. Make it easy for non-techies to get them up and running and make sure they run on shared hosting and are created in a language that beginners use to learn about programming.

I can't tell if you're being sarcastic or not, so I'll just assume the worst.

Yes, it is - there's a lot more non-techies than there are of the other kind, so it makes sense that you focus your efforts on the larger market.

As for the whole "language that beginners use to learn about programming", do you mean Python or Java? PHP is everywhere but the last I checked, Python and Java are the teaching and taught languages.

PHP itself is designed to get things done, not necessarily elegantly. For all it's problems, it is a workhorse and blaming the language for what the users have done is just wrong. Programming languages are like hammers and should not prevent one from doing something stupid or irresponsible. Doing the smart or right thing is the responsibility of the user.

Back in the 1900's and even before that electric cars were invented by several people. In 1916 some inventor called 'Woods' created the frist hybrid car. One reason for the decline of the electric car market was that the infrastructure eventually could not facilitate them. Read; hosting providers didn't support them. Another reason was they were slightly more expensive, especially when Herny Ford came along. Read; shared hosting is cheap. Another reason I have heard told is that electric cars had less parts that you could tinker with. It was more interesting to have a fuel car because you could use other car's parts and combine them, you could spend your weekend working on them. Electric cars just worked, or people didn't have the technical know-how to toy around with them. Read; non-techies don't know how to setup a Rails app. Assuming 'Ghost' is the new best thing, making the underlying technologie easy for non-techies is NOT the way to make it happen. The whole goal seems to be to make the UI easy and useful. You make the point that non-techies need to be able to set it up. You make the wrong assumption that they would need to touch code/servers to do this.

I meant PHP.

I don't want to spark some sort of war on what language beats up your language. So I wont. Besides I don't think something 'being everywhere' makes it good. By that standard lots of things in this world are good.

PHP is exactly what you say it is with regards to being similar to a workhorse. It is a tool for programmers who like to work very hard to achieve something that a harvester could do a lot quicker and more efficiently.

Alex Munroe explains what I meant better than anyone I have seen. It is a great read. Also if you like PHP. http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-de...

He does not bash PHP, he explains why he thinks it is the wrong tool for the job. Interestingly, he also uses the tool analogy. We are all so predictable :).

Let's switch Java for Javascript and Python for Coffeescript as far as similar syntaxes go. In any case, regardless of existing userbase, doing a forward looking project in backward looking technologies doesn't sound right to me. Go with Node, or Clojure if easily deployable today is a must.

"easily deployable" for Clojure or Node isn't even on the radar for 99% of people.

I go to any $5/month host, check "install wordpress", and it's done. When Clojure CMS/blog apps have even 1% of the installability (as in, ability to be installed) by non-developers, perhaps they'll have a fighting chance.

I say this as someone who develops Grails apps all day long.

Granted I don't know the state of Clojure, but I thought running on the JVM would make it easily deployable most anywhere. Of course then having a blog engine or cms built in Clojure that's easy to install is another problem, but this thread is exactly discussing such a solution.

>I go to any $5/month host, check "install wordpress", and it's done.

That is a function of popularity, not language. If some blogging app had a userbase the size of wordpress's, it wouldn't matter if it were written in PHP or brainfuck, shared hosting providers will set it up. This is why appealing to techies makes sense. They will be the ones setting it up in the initial "its not popular yet" phase, and if they don't use it, it will never get off the ground. Once they start setting it up for their friends/family/etc, a few companies start offering it as an option for their hosting. Then a few more, and it snowballs as the app gets more and more popular. Trying to start from "use PHP so end users will use it" doesn't work, because installing a PHP app is just as hard for them as installing anything else.

"easily deployable" is part of the equation, but even assuming a clojure app was 'easily deployable', the architecture of JVM apps runs against the interests of shared hosting providers - anyone looking to get more functionality from less hardware.

Keeping JVM engines going, and keeping a lot of compiled apps in RAM, on the offchance that someone makes a request, means fewer apps/sites can coexist on the same hardware. My $5/month PHP plan (hypothetical - I don't have one) - only compiles/executes the PHP when the request is made. If no one requests my site for 3 days, it's all just sitting there, not using any resources.

Until there's another technology that follows a similar model (or something else which provides good economies of scale for hosting providers), PHP will continue to dominate large segments of certain problem spaces.

I have only run across one host that didn't have Ruby / Python available, and they were charging 4x the market rate for bad shared hosting - we easily saved $15 / month by ditching them.

Anyone that only has PHP likely also doesn't have their PHP/MySQL updated to the point that anyone should trust them.

One.com (big in europe) have only php support but offers unlimited network for €1.25/month. They run recent-ish php (5.3 i think).

I meant being able to drop the application files to almost any web server (including cheap hosting providers) and just have it run

What are those two commands?

    apt-get/yum install ruby rubygems
    gem install rails

That's not sufficient to serve a Rails site though.

Rails is a great platform for building a custom web app, but it's a terrible platform for building an open-source blogging platform. It simply moves too quickly and breaks things too often to be useful for the demographic that uses WordPress.

When you're talking about web code with such an astronomical deployment to developer ratio, the advantages of PHP are magnified by several orders of magnitude. Even the perfect WordPress replacement written in Rails with elegant, featureful and performant Ruby code digitized by God's own hand is by definition a niche product that can never hope to compete meaningfully with WordPress.

The images and the proposal part was what I noted first as well. I left the site as soon as I noticed that all content was in images. I wonder what the reasoning behind such a poor choice of displaying content was? Prevent Search Engine crawling? Prevent easy copying of the text?

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact