To those who responded to my plea for help by leaving a comment or responding out-of-band, thank you very much. We’ve settled on a name for our application, purchased the corresponding domain names and filed a trade mark application.
Will keep you posted as things evolve further. But just to give you an idea, we’ve already iterated through several “alpha” versions and expect to have a public beta ready by the end of February. Stay tuned for an explanation of what the service actually does.
It’s probably time to come clean about my recent spate of posts on startups, Ruby, Python and so on. Well, there are a few things about peer review and publishing in the realm of academia that I think could be better, so I tried to figure out an alternative process that retains the benefits and overcomes some of the problems of the current system. We think we’ve done that, and it turns out that I wasn’t the only one who thought that things could be a lot better.
NICTA has provided pre-seed funding in the form of a couple of commercialisation grants to implement this new way of doing things. I’ve hired a top notch graduate software engineer (who’s been working with me as a student for the past year and a half on unrelated things) to help me deliver alpha and beta versions of this system over the next six months or so. For this project, we’ll be working in startup mode; I’ll be making every effort to provide a small company atmosphere for the engineer and others who join the project.
It turns out the solution to the problem can also be applied to (web) search, since it is essentially a nice way of ranking documents within communities. I can’t go into the details of the solution here, but I can list some of the things that I (and other researchers, as it happens) think could be better.
These are some of the problems that researchers say they can see with the current way of doing things. We think we can claim that our idea solves many of these problems. For example, under our system, which we are calling PubRes for the moment, citation collusion is futile. Under PubRes, you’d also be silly to lend support to a paper that you know isn’t very good (even if it is written by a colleague), and you’d be silly not to lend support to a good paper (even if it is written by a competing group of scientists or your worst enemy). There are some things we haven’t solved, like honorary authorship and ghost authorship, but these are problems I’d like to investigate in the future. Although I can’t reveal the details here, I can say that the underlying mechanics of PubRes are no more complicated than traditional peer review procedures (and probably much less complicated), but it is a major departure from how things are done now. I can also say that the feedback we’ve got from people we’ve explained it to has been overwhelmingly positive, which is the main reason I’m still pursuing this.
NICTA are making sure we do this properly, so some of the grant money is being spent on figuring out the structure of the academic publishing market. We already know that the top three academic publishers had combined 2007 revenues in excess of $US3 billion, but that doesn’t say much. We’re currently doing some much deeper market research to get a better understanding of the domain.
It’s important to note that what we’re doing is completely different to all known attempts to bring science to the web. PubRes is not another CiteULike or Connotea. It’s not another arXiv.org. It’s not like PLoS One or PubMed Central. It’s different to ResearchGATE and Science Commons. While our implementation may contain elements of these existing tools, PubRes is a fundamentally new way of getting your research published, and it’s a new, much fairer (we think), more direct way of rating scientists and the papers that they write. One of our aims is also to make the whole reviewing, publishing and reading cycle a lot more fun.
With any luck, a public beta will be available early next year. Oh, we think we’ve settled on Ruby and Ruby on Rails for the web tier, and no doubt there’ll be some AJAX stuff in there to pull off a few nifty browser side features we have in mind. Stay tuned.
So it turns out that quite a few readers of this weblog use Bloglines. For some reason, Bloglines stopped sucking down the RSS feed for this weblog after March 19 until three days ago. Did other feed readers experience similar difficulties with my blog? I know Google Reader continued to work, as did the RSS screensaver on my Mac. Anyway, that partially explains why I had no feedback on my hypothetical question about startups.
Thanks to those who did end up responding. Here’s some snippets of what you said, along with some feedback I got via e-mail in no particular order:
- My 2c – I don’t believe there’s that much inherent difference between the major web platforms – in my opinion you’re best off going with what you have the most experience with (and what the people you can get have experience with). You could probably lose 2-3 months learning a new platform (primarily learning it’s idioms and gotchas) and it’s not clear that you’re ever going to get that back. Having said that, I would tend to recommend against the embedded scripting languages (PHP, ASP, etc) on any project of significant size – it’s not so much that they can’t scale, but they strongly encourage non-scalable design by their nature (and it can be harder to find developers who understand the difference). A ‘well-designed’ PHP application will often actually include it’s own sub-templating language (e.g. Smarty), and treat PHP as a pure programming language.
- Now you have the prototype you pretty much know the functionality – “recoding” is all about achieving the chrome and non-functional requirements. So, maybe Erlang – excellent for reliability/uptime (incl. for hot-upgrading and failover) and scalability – the two most important -ilities for webapps. Frontend “yaws”, plus some javascript library, and/or maybe an web framework like “erlyweb”Backend – hand-coded erlang apps. Database – “mnesia” or maybe “couchdb”
- Thing is, there are big sites being run on all combinations of your options. If you just need *something*, write it in what you feel comfortable in, if it needs to scale later you can use your first iteration as a learning experience. Personally, I think you’d be crazy to write anything in java, you can’t be nimble in java. I also think php is a dead end, it’s just too bodgy. Python/Ruby is the only way to go imho. Funnily enough I saw no mention of javascript for your web 2.0 site :) I would suggest that none of the backend stuff matters at all, and that the only thing that matters is which javascript library you use in the front end.
- I assume that this is for a “friend” :-). But I shouldn’t assume.I’m afraid to say I can’t add that much. Just don’t have the knowledge. For this kind of thing, being able to easily tinker with and evolve the system seems an important critiera, if just one of the relevant criteria.
- it doesn’t matter what technology you use, because you’ll rewrite the whole thing several times anyway. pick what’s fastest to explore the idea and the market now. time to market, and reaction time once you’re there, cost far more than another 100 servers while you’re in the early stage.who are your partners (or your VC’s partners)? do they have an affinity with any particular technology? what are your friends best at? you’ll need a pool of expertise (and employees), so choose something to maximise that opportunity.
- I was going to answer but my intial answer seemed too stupid and it was going to take too long to come up with an intelligent well thought out answer for a hypothetical that did require me to stretch my imagination to the extreme. It’s sort of like what I am finding with some of my 1st years. In one the subjects I am teaching they have to do a lot of hypothetical work and most of the time, the results are utter disasters because they simply, simply can’t stretch their brains into comprehending scenarios so outside their sphere of “being”. Since founding a startup is far, far outside my sphere of ‘being’ I decided I would much rather play pokemon. Now if you ever want to know which pokemon is best to use against a ground-type pokemon….
Mostly very useful feedback, and amusing otherwise. It’s interesting how similar most of the feedback was. Agility, ability to tinker and swiftness of development were common themes. For at least the alpha and beta, I think it would be best to go with tools/platforms where you can put something together fairly quickly, and make changes quickly if your users tell you they’re looking for something a bit different. I’m not sure Java fits that description (although I’ve always been a Java nut). There’s at least a compile step and possibly a deploy step, depending upon your development environment, between making a small change in the code and seeing the result in your browser. Ruby looks cool, but it is still lagging way behind the other serious contenders in terms of performance. PHP could be a contender, but if the system ever got really big and you had new graduates working on the application, I’d bet you’d soon end up with a mess, with business logic stuck in the presentation code and so forth – I really do agree with the first comment above on that point. So I’ve got to say that Python is looking good right now, despite its Makefile-like treatment of white space. Coupled with Django, it might be a winner. There’s also the fact that Google have provided a nice playpen for Python-based web applications.
Once again, thanks all for your input. Please keep the advice and opinions coming if you have more to add. It’s much appreciated.
—Update (06:49 19/04/2008): I’m not sure my comment about Ruby performance is entirely fair. The performance difference between Ruby and Python is nothing (Python is a few times faster on most tests) compared to the difference between Python/Ruby and Java, for example (where Java is one and sometimes several orders of magnitude faster). By this reasoning, if one is happy to sacrifice some runtime performance and use Python instead of Java, one presumably wouldn’t be too worried that Ruby is slightly worse than Python. And Ruby doesn’t do too badly in terms of memory usage. Besides, if one was really worried about performance, one would use C.
So, after waiting a few weeks, I still have no responses on this blog entry. Okay, I got one reply by e-mail, not including the advice I received from friends before posting the blog article. Was I silly to think people might actually respond? (Chorus: “Yes, Ricky, you’re very silly!”)
Picture yourself in the following situation. You’ve come up with what you think is a cool idea for a so-called web 2.0 site. Furthermore, you’ve managed to convince some VC types to invest some (pre-)seed funding – enough to develop a public beta. You developed a quick and dirty proof-of-concept to show the VCs, but now it has to be thrown away. You have to start development on the real thing from scratch.
The question is, what technologies, programming languages, tools and platforms are you going to use to implement your idea? Language-wise, do you go for Python, Java, PHP, Ruby, or something else? If you take the PHP route, how do you ensure maintainability in the long term? If decide on Java, do you use JSP, Velocity or Freemarker? Would you use Struts or Spring? Do you need any of these frameworks at all? Do you run on Linux, Free BSD, Windows or Mac OS X Server? Why?
To make this question at least partly answerable, imagine for the moment we’re just considering the presentation tier, and not any of the back end magic. Also imagine that what you’re developing is similar to one of today’s social networking sites (Facebook, Bebo, MySpace or something), and that visualisations (e.g., of directed graphs) might need to be generated dynamically from data in the back end. You can assume that the beta version will have a small number of types of dynamically generated pages (less than 10, say) but later versions will end up with many more.
Answers along the lines of “It’s much of a muchness, so I would choose X, Y and Z because they’re what I know”, “I’d choose X, Y and Z because the newly graduated computer science students I’d have to hire are most likely to be comfortable with those” and “X, Y and Z are nice but too expensive for my startup, so I’d choose A, B and C instead” are completely acceptable.
I’ve already got some great input from my closest friends (at least the programmers among them), but I’d like to get some responses from a wider audience. I’m hoping some ex-DSTC engineers/researchers might have an opinion on this; you don’t need to have worked at a startup to give useful feedback!
I’m asking this question out of pure curiosity, nothing more, and I have my own feelings on this (represented by the sample answers above). Please leave your answer as a comment below.
Big companies will slowly suck the life out of you. That’s one way of summarising Paul Graham‘s latest essay. To maximise your freedom, he says, join a start-up or start one yourself. It’s a theory that I find very appealing.
I’m fascinated by the idea of ordinary football fans being able to own a football club and collaborating to decide on which players to buy and sell. This idea is very close to reality as MyFootballClub has agreed terms with Ebbsfleet United FC to buy a controlling share of that club. MyFootballClub members get a say in the running of the club, including picking the team from week to week. This takes Fantasy Football to a whole new level! At £35, it’s very tempting to buy my own share of the club…
One might imagine the idea of letting the fans pick the team could drive the manager crazy, but here’s the reaction from Ebbsfleet United’s manager, former Ireland international Liam Daish:
Everyone has worked wonders to get this club into the top half of the Conference. We all agree the club needs something extra to take it to the next step. As a football fan, I think the MyFootballClub idea is fantastic. And as the coach, I look forward to the challenge of working with thousands of members to produce a winning team. Alan Kimble and myself are 100% committed to making this work.
I think “challenge” is the key word in that quote.
Brisbane (and Australia, for that matter) needs more crazy rich people willing to invest in technology startups. Probably mindbogglingly obvious, but that’s the conclusion I’ve drawn after reading another of Paul Graham‘s insightful essays. Brisbane does not have nearly enough venture capitalists to create a critical mass of technology companies. This means that despite the existence of places like UniQuest and inQbator, any innovative ideas produced by universities, CRCs, NICTA and CSIRO (and I’ve seen a few of them) are released into a near vacuum, with the fruits of this labour dissipating according to the second law of thermodynamics. Only a critical mass of startups will have enough gravity to prevent this research fizzling away to nothing or leaping across the Pacific Ocean to the US, where the capital market is far more accommodating of crazy ideas. A critical mass of venture capitalists is required to gain a critical mass of startups, and once this is in place, a chain reaction is started whereby startups beget more startups. When this chain reaction gets going, that’s when we’ve created a sustainable, innovative technology industry.
So, what do we do to get the ball rolling? How do we get rich people to invest in our work? The first step might be to make them aware of what we do, which means inviting them to our workplaces, networking with them at dinner functions (hell, we the researchers should be organising these functions and not simply waiting for someone to do it for us) and marketing ourselves. While some of us might be doing this to some extent, we aren’t doing it nearly enough. It’s important to note that I’m not talking about targeting existing VCs – they’re already doing a fair enough job. I’m talking about attracting those rich people around Brisbane who aren’t currently part of the VC and angel investment scene. Think about all that cash hulled up in Hamilton, Ascot, Fig Tree Pocket and other leafy suburbs. It’s probably going into resource stocks, property and superannuation. The challenge is to convince these people to do something more exciting and potentially much more rewarding with their dollars. The goal is to enlarge the pool of funds available for investment in technology startups. Why will this work? Well, there’s a good chance it won’t. But I’m convinced the way to get more rich people involved in funding startups is not by trying to demonstrate the merits of any particular new idea, but by holding a conversation with them over the long term and getting them to buy into the big picture. Maybe this has been tried on numerous occasions before, but because it failed then doesn’t mean we should cease the conversation. Let’s organise a few functions with the help of organisations such as the AIC, scrape together the dosh to fly the Paul Graham’s and Guy Kawasaki‘s of the world to Brisbane and have them speak at the functions. These are small steps for sure, but they are steps that need to be taken if the Australian technology industry is to improve its position in the world. The other thing that might have to change is rates of taxation, but let’s do one thing at once!
I say it can be done.
Note: This article is covered by the standard disclaimer.
The excellent Paul Graham observes that the cost of getting a web startup off the ground is very low, and getting lower. Hence the proliferation of so-called Web 2.0 companies. He, like me, believes there’s still a lot of room for more web startups. Facebook, YouTube and company are only the beginning. Innovative minds will find ways to bring many more interesting things to the web. Some of them will be game-changing the way Google was. Some of them will change the web altogether.
What implications might this have for NICTA and other such places? It might just mean that these organisations shouldn’t be surprised if the next big web thing comes out of the suburban bedroom of a twenty-something year old rather than one of the universities or CRCs. Whether this turns out to be a threat or an opportunity partially depends on the way it is perceived by the general public, who might be inclined to ask “If a billion dollar technology company can emerge from some person’s bedroom, why do we need publicly funded ICT institutions again?” Of course, there are at least a few good reasons, like trying to ensure that the brightest computer scientists contribute to Australia’s GDP rather than that of another nation’s. And besides, one web startup, even a tremendously successful one, does not a Silicon Valley make. These institutions have an important part to play in spawning an innovative, self-perpetuating IT industry in this country, and from my point of view, it would be great if the hub of this industry was Brisbane. How to be Silicon Valley is the subject of another of Graham’s essays, and my next article.
Note: This article is covered by the standard disclaimer.