There are two very different types of startup: one kind that evolves naturally, and one kind that’s called into being to “commercialize” a scientific discovery. Most computer/software startups are now the first type, and most pharmaceutical startups the second. When I talk about startups in this essay, I mean type I startups. There is no difficulty making type II startups spread: all you have to do is fund medical research labs; commercializing whatever new discoveries the boffins throw off is as straightforward as building a new airport. Type II startups neither require nor produce startup culture. But that means having type II startups won’t get you type I startups. Philadelphia is a case in point: lots of type II startups, but hardly any type I.

Incidentally, Google may appear to be an instance of a type II startup, but it wasn’t. Google is not pagerank commercialized. They could have used another algorithm and everything would have turned out the same. What made Google Google is that they cared about doing search well at a critical point in the evolution of the web.

In this footnote alone there is a sizeable nugget of wisdom for any government or other innovation funding body outside of the Valley that cares to listen. Whether you see it as a good thing or a bad thing, it’s clear there is no startup culture in this country. I’d guess that a disproportionate number of ventures in Australia fall into Graham’s type II category: commercialising the results of academic research with no startup culture required and none produced. Notwithstanding the regulatory risk that often accompanies startups formed around a scientific breakthrough (think biotech and pharmaceuticals), the VCs that fund these sorts of ventures would typically shoulder less financial risk than their type I-loving Valley counterparts; there’s a surer trajectory for type II ventures because there are fewer unknowns. Another way of saying this is that series A funding for type II ventures (probably the most common kind of startup in Australia) is more like a series B or C round in the Valley.

The last part of the footnote above is perhaps most important. I hope that governments here don’t think that by allocating tax-payer funded block grants to pseudo-commercial technology “incubators” with an academic bent that a Google will pop out the other end. It could happen, but not by design. What these “investments” are more likely to produce is a steady trickle of good science resulting in the occasional type II startup. If that’s what’s intended, it’s all good, but let’s be clear about it! The creation of a Google by this means would be due more to luck than careful planning, and our current funding models certainly won’t trigger a self-sustaining chain reaction of startups.

@order_item = OrderItem.new(:hi => "hem", :ho => "hum")
@order_item.save!

@order_item = order.order_items.create(:hi => "hem", :ho => "hum")

@order_item = OrderItem.some_custom_creation_method(:hi => "hem", :ho => "hum")

The Problem

When you’re writing your spec (up front, of course!), you don’t want to presume too much about how the implementation will unfold. So, do you stub the create method on the model class? But what if we implement using the new/save combo (as above)? Or, what if we create the model instance through an association?

My Solution

My first pass solution to this problem is the following, based on Matthew Heidemann’s association stubbing technique:

module Spec
  module Mocks
    module Methods
      def stub_creators!(association_name, klass, stubs = {}, valid = true)
        target_mock = Spec::Mocks::Mock.new(klass, {:save => valid, :valid? => valid}.merge!(stubs))
        target_mock.stub!(:save!).and_return do
          target_mock.save
          valid || raise(ActiveRecord::RecordNotSaved)
        end
        klass.stub!(:new).and_return(target_mock)
        klass.stub!(:create).and_return do
          target_mock.save
          target_mock
        end
        klass.stub!(:create!).and_return do
          target_mock.save!
          target_mock
        end
        mock_association = Spec::Mocks::Mock.new(association_name.to_s)
        mock_association.stub!(:create).and_return do
          target_mock.save
          target_mock
        end
        mock_association.stub!(:create!).and_return do
          target_mock.save!
          target_mock
        end
        mock_association.stub!(:build).and_return(target_mock)
        self.stub!(association_name).and_return(mock_association)
        target_mock
      end
    end
  end
end

What this is doing

The thinking here is that, when I write my spec, I don’t want to be concerned with whether the implementation takes the create, new/save, build/save, or other route. In my spec I just want to know that at some point the controller asked for a model instance to be created and saved. The above code, which I put in spec_helper.rb, allows my specs to do just that. Essentially, I stub save so that it returns true or false, depending upon the optional valid parameter, and the other creation stubs derive from that: save!, create, create! on the target association class and the association itself. I also stub out new and build for convenience. This code ensures that save is always called, even though we’ve stubbed out create etc. Now if I need to check that a controller action has caused a model instance to be created, I need only ever check that save is called.

An example

In my specs I call stub_creators! on an instance of the association owner (in our example, the association owner is Order), passing it the name of the association I want to stub (order_items), the model class of the association target (OrderItem), optional stubs for instances of the association target, and whether or not we want the returned model instance to be valid (defaults to true). With this in place, I can do this:

describe OrdersController do
  before(:each)
    @current_user = mock_model(User, :login => "me", :logged_in? => true)
    @order = @current_user.stub_creators!(:order_items, Order)
  end

  it "should create a new order_item" do
    @order.should_receive(:save).and_return(true)
    post 'create'
  end
end

And it doesn’t matter which route the implementation takes to create that model instance. As long as save is called at some point, I know the controller has triggered the creation of the instance somehow.

Thoughts

Now, while this seems to work for me, I don’t really know whether this is kosher. Is it a sensible approach to take? I haven’t tested this extensively; as I said, it’s a first pass. Also, there’s bound to be stuff missing from my solution (for example, it doesn’t handle find_or_create_by_). Can a similar approach be taken to the various ways to delete an object, too? I shall continue to experiment.

Note that we’re experiencing a few difficulties with our Citemine production server environment, which means slow page loads from time to time. And it’s clearly lacking polish, but hopefully it serves its purpose as a proof-of-concept so that you can get a feel for what it’s all about. But please do read the paper. I’ve been told it’s a fun read.

One thing from that story that caught my attention was this:

She (Rachel Nolan) said people living near train lines or stations would not be able to tap into the free internet service because it would be “firewalled”.

That would have to be one pretty intelligent firewall! Here are some actual possibilities to guard against free-loaders. One not so attractive way to do it would be to set a limit on daily downloads. The theory is that there’s only so much you could download on the longest possible trip on the QR network in south-east Queensland (say, Gold Coast to Nambour, or something like that). The other more attractive solution, in my opinion, would be to tie usage to go cards. Your internet session starts when you swipe on at the beginning of your journey, and it finishes when you swipe off. There’d be some kind of web-based login procedure like you get at hotels and elsewhere, where you enter your go card number to gain access; or regular users could have the option of registering the MAC address of their wireless card with QR/Translink to skip the login procedure. Given that it still takes ages for a credit card top up to find its way onto my go card, I don’t hold out much hope for QR/Translink being able to implement this particular solution within the already very optimistic time frame of early 2010. But I do think it’s a reasonable long term solution. It might even help Translink in their quest to move more commuters over to the go card from paper tickets.

So what does this mean? It means that right now Twitter is hot. People are talking about it, and that’s the best that Biz Stone and company could hope for. The big question for Twitter is how to convert all the talk into more users, and ultimately revenue. If they do manage to do this, it would be nice to know how they did it!

National benefit versus private benefit… Hey, that’s what capitalism is designed to do, is to guarantee that there is no contradiction.

The line got a delayed laugh, because it took the audience a few moments to realise that was all Professor Ullman had to say on the topic, and that he’d moved on to the next topic. People laughed, but he was serious, and more right than many would be willing to accept.

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.

• Citemind
• Citecloud
• Citefish
• Citecrowd
• Citemarket

I would be more than grateful if you could point your friends and colleagues at this blog entry, particularly if they are involved in writing research manuscripts.

Thank you!

Often we seem to use the term Ubiquitous Computing to mean “computers everywhere” as if just having the hardware all over the place was a worthwhile end in itself.

But maybe a better meaning is “computing available when you want it in a way that makes sense for where you are and what you’re doing” which is much harder to do than “computers everywhere”.

In the research space, among others I can refer you to iCam (2006) and MARA (2006) from researchers at Georgia Tech and Nokia respectively. iCam allows the placement of virtual sticky notes on objects in the physical world, through a mobile device. This is neat, since the sticky notes only appear to those whom you want to see them. A limitation of iCam is that, while placement of these sticky notes is very accurate, it only works indoors. MARA overlays information about the real world (and even the people in it if information about objects is being streamed from a central server) in real time.

The there’s this concept device from petitinvention, which takes the idea a few steps further. The user can see information about buildings and locations overlaid on the video stream from the mobile device’s camera. But the same tool can be used to select text from a piece of paper (like a newspaper). Essentially, it’s an augmented reality search tool.

In the commercial/start up realm, a couple of companies have been creating a bit of buzz. First there’s Enkin. Enkin has been developed for the Google Android mobile phone platform. It enables users to tag places and objects on Google Maps, and then to see these tags overlaid on the real world as you walk around with the phone. My favourite is Sekai Camera from Tonchidot. I’m not going to explain it. Just watch the video below. But note that even products on the shelves in shops are tagged in the virtual world and overlaid on the real world. And it’s a very social application.

There’s probably still all sorts of hurdles to overcome, but what a great presentation.

Technologies developed by NICTA’s Queensland facility are widely used by the state government. One example is software to authenticate and protect digital evidence currently deployed by the state’s police force.

To be honest, “widely used” might be a bit of a stretch at this point, but it’s true that the state’s police force are using the mentioned piece of software and they’re very keen on it. I’d be willing to bet that the next four years of the lab will be pretty successful in terms of spin-outs, licenses and other outcomes.

NICTA has a very different atmosphere to DSTC (which I can’t imagine will ever be surpassed in my career in terms of outright coolness) and Sun Labs, two places I’ve worked before and which I give credit to for inspiring me along the path to a career in research, so it took a while to get used to. I guess it’s still trying to find its own culture, really. The Queensland lab may be helped on in that respect by the cozy confines of our new quarters at UQ (at the very least, we’ll all get to know each other very well!). NICTA as a whole has set pretty high standards for itself, particularly in terms of research project approvals, and to its credit, recent evidence tells me that it’s going to do its best to keep to those standards. I hope it does.

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.

• Traditional peer review requires that authors trust reviewers to act in good faith – reviewers are not required to “put their money where their mouth is”, so to speak;
• Related to the above, traditional peer review gives no real incentive to support the good work of a group competing scientists;
• Related to the above, traditional peer review provides no real incentive not to support the poor work of a colleague or friend;
• Traditional peer review gives no tangible recognition to the many hours of reviewing that scientists do – reviewing is just something you’re expected to do for the good of the scientific community;
• Traditional peer review gives no incentive to authors to self-review their work before submission, meaning reviewers get burdened with too many bad and mediocre papers;
• Metrics such as H-index and G-index are somewhat arbitrary, do not give a direct indication of the esteem with which scientists are held by their peers, and are not indicative of the current capacity of a scientist to produce good work;
• Citation collusion is too easy to accomplish, but difficult to filter out when calculating the above metrics;
• Not enough cross-fertilisation between fields, largely because closed communities are too common; and
• The publication process is too slow, often taking years for a journal paper and months for a conference paper.

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.

Anyway, after having checked out Python and Django and deciding that I’d be happy enough with that set of tools, I thought I’d better check out Ruby and Ruby on Rails to see what all the fuss is about. Well, I have to say, so far I really like the Ruby language. I’ve been helped along by what has to be the weirdest, but coolest, guide to programming that has ever been written for any language (what other programming guide comes with cartoon foxes and its own soundtrack?). I’m still learning the ins and outs of Rails, but there are some very helpful tutorials online for this, too. The fact that Ruby, like Python, comes pre-installed in Leopard was a pleasant surprise. Ruby comes with a command shell environment called irb (Interactive Ruby), which enables you type Ruby code at the command prompt (again, just like Python’s python command line tool). This makes it very easy to experiment with the language.

One of the things I like about Python is list comprehensions. They’re a very neat and convenient way of mapping a list to a new list by applying a function to each element of the original. It kind of works like the map function in many other languages, except you can include conditional statements. The heavy use of list comprehensions in Programming Collective Intelligence tells me that there’s a good chance they’ll come in handy for me later on. Here’s a trivial example:


>>> list1=[1,2,3]
>>> list2=[x**2 for x in list1 if x%2==1]
>>> list2
[1, 9]


In Ruby there’s no syntactic sugar for list comprehensions, but it turns out you can pretty easily implement the required behaviour:


>> list1=[1,2,3]
=> [1, 2, 3]
>> list2=list1.map {|x| x**2 if x%2==1}.compact
=> [1, 9]


Furthermore, since classes are never “sealed” or “final” in Ruby, it means that you can do something like this:


>> class Array
>>   def comprehend( &block )
>>     block ? map( &block ).compact : self
>>   end
>> end

We’ve just added another method to the (existing) Array class which works very much like a list comprehension:


>> list1.comprehend {|x| x**2 if x%2==1}
=> [1, 9]


That’s a little of what I’ve learned about Ruby in the past week or so. Anyway, I can say that I’ve narrowed down my search to two candidates. Python has the lead in terms of being a mature technology. But Ruby really is fun to program in, and I like its syntax better than Python’s. Furthermore, I spent a while faffing around with Django and mod_python for my Mac. But getting Rails up and running was a breeze using the Mongrel web server – a production quality web server for Ruby applications, used by many web sites including Twitter. Ultimately, my (hypothetical) first hire gets the final say. :-)

Coincidentally, according to the most recent entry in his blog, Toby will be giving a talk on a topic sort of related to one I’ve been thinking about as a possible project at NICTA: Creating Semantic mashups: Bridging Web 2.0 and the Semantic Web.

It turns out that Toby is also a fan of GTD, and he’s written his own web based GTD tool. It doesn’t look much, but it’s gained some favourable reviews.

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:

1. 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.
2. 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”
3. 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.
4. 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.
5. 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.
6. 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.

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.

Image credit: Nunes, M., Greenberg, S. & Neustaedter, C. (2007) Sharing Digital Photographs in the Home through Physical Mementos, Souvenirs, and Keepsakes. Research Report 2007-875-27, Dept Computer Science, University of Calgary, Calgary, Alberta, Canada T2N 1N4. July.

It is important in doing ubicomp research that a researcher build a compelling story, from the end-user’s perspective, on how any system or infrastructure to be built will be used. The technology must serve a real or perceived human need, because, as Weiser [1993] noted, the whole purpose of ubicomp is to provide applications that serve the humans. The purpose of the compelling story is not simply to provide a demonstration vehicle for research results. It is to provide the basis for evaluating the impact of a system on the everyday life of its intended population. The best situation is to build the compelling story around activities that you are exposed to on a continuous basis. In this way, you can create a living laboratory for your work that continually motivates you to “support the story” and provides constant feedback that leads to better understanding of the use.

Designers of a system are not perfect, and mistakes will be made. Since it is already a difficult challenge to build robust ubicomp systems, you should not pay the price of building a sophisticated infrastructure only to find that it falls far short of addressing the goals set forth in the compelling story. You must do some sort of feasibility study of cutting-edge applications before sinking substantial effort into engineering a robust system that can be scrutinized with deeper evaluation. However, these feasibility evaluations must still be driven from an informed, user-centric perspective—the goal is to determine how a system is being used, what kinds of activities users are engaging in with the system, and whether the overall reactions are positive or negative. Answers to these questions will both inform future design as well as future evaluation plans. It is important to understand how a new system is used by its intended population before performing more quantitative studies on its impact.

It strikes me that too few ubicomp research groups heed this, seemingly obvious, advice, including our own. Though we might occasionally attempt to build a story, it is not often compelling, and I’ve read far too many papers that suffer from the same problem (caveat: I specifically exclude Karen‘s work from this blunt introspective analysis because her work is typically very well motivated, and compelling; and she read the paper I’ve just quoted early on in her Ph.D. and took note of it). I don’t think it’s a coincidence that the most successful ubiquitous computing researchers have taken this advice to heart. I want to make sure that the new project at NICTA does do these things properly.

Truly inspiring.

I wonder what sorts of casual, natural interactions such as those induced by Bowl might make sense in the domain I’m working in? What are the relevant artefacts that could be augmented to create new meanings for the people who interact with them?

So imagine my surprise to find in last Friday’s edition of ACM TechNews that this paper has been republished in Communications of the ACM this month, albeit in a slightly shorter form. Aside from a few cosmetic changes (updated figure and table), the content of the papers is the same. That is, you don’t gain any knowledge from reading one of the papers that you wouldn’t gain from reading the other. There is no indication in the more recent publication that so much content has been duplicated from an earlier paper, though there is a citation to the older paper. In short, this is not new material, having been first published more than three years ago. Communications of the ACM seems to be trialling a new model, whereby the best articles from conferences are modified and republished for the ACM audience. But seriously, the modifications in the republished MapReduce article are negligible. What gives?

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.