L-P Huberdeau

The W3C always had great intentions. The goal has always been to create great standards encompassing for all possible situations and respecting all special needs. In the early days, great standards still living today were created, like HTML and CSS. Of course, there were problems. It took years for standards to be supported correctly because of ambiguities. Facing those problems, they decided not to make standards official until they were fully supported by enough implementations. XHTML 2, CSS 3 never saw the light.

Standards like RDF never became what they were meant to be nearly 10 years after the reccommended proposition. SOAP and WSDL are huge buzzwords in the SOA world, but it never quite works as well as it should. Implementations are still incompatible and subsets of the spec need to be used for communication to be handled properly. Not to mention there are still no traces of XLink, XPointer or XForms anywhere in the ecosystem. All these specifications appeared in the early 2000s or late 1990s. Who were they made for?

The big problem with all of them is that they are so abstract that no one outside the comity who designed them can understand their purpose, let alone any idea of trying to support them. The specifications are too large. Too complicated. Building around XML probably wasn’t the best idea ever. It really is unlike anything else and painful to work with, unless you use even more XML technologies. It does not map well to common programming paradigms. It was only ever similar to HTML and SGML. Maybe those should have been taken as exceptions rather than the rule.

I consider the best specification build around XML is XPath, but only because it removes all the burden of managing XML and it’s not XML-based. CSS is great for formatting HTML, again, not XML-based. XSL-T is not too bad because it plays nice with HTML, but I find some other techniques like Zope’s TAL to be a lot more elegant. It extends XML without adding to the tag soup.

By ignoring all the details, APIs like SimpleXML allow you to read XML seamlessly, but writing it is a completely different task. XML works everywhere, but it’s always alien to the environment.

Recently, I have noticed that the Web started to regain it’s original nature. Standards are emerging rather than cultivated. The days where companies assigned employees to a consortium in order to write a specification are over. The W3C is still working on their specifications, trying to get them out the door, but nothing new started in a long while. During that period, we got to see great standards establishing themselves, not because they were supported by the industry, but because they were good.

Think about JSON and YAML. JSON is a subset of JavaScript that is well specified, easy to understand, easy to read for a machine and easy to write for a machine. YAML is a human readable format that is formal enough to be parsed by a machine. What do they have in common? They map to programming concepts. All scripting languages out there can load them in a single function call into their internal formats and rewrite them just as easily.

In the end, the problem can be distilled down to a single preference. You can either write a complex specification, encompassing for all possible cases, and spend months implementing it and making sure it’s compatible, then spend 5 minutes configuring it to perform all the magic. Or you can have a simple data exchange format, hook it to a scripting language and spend anywhere from 15 minutes to a few hours to do what you need. On the large scale, complex standards are worth it, but in most cases, they are a waste of time.

One of the great aspects of web development is that there are so many problems, there are thousands of people thinking about them. Over the years, a great ecosystem of tools and techniques was built. These days, all you need to do is piece together existing components. HTTP is a good environment to make requests and get responses. Data serialization is available. All you need to choose is decide how to use them. Recently, Identi.ca/Laconi.ca wrote a small specification for open microblogging. OEmbed allows to export the location of images and videos. When you look at those, the first thing that comes to your mind is: Why hasn’t anyone thought about it before?

It doesn’t have to be great. It doesn’t have to be so smart. We only need to agree on something, or do something and get others to follow. There is nothing religious about saying which field name you will use to contain the location or the size of an image. There is no need for namespaces and extendability. It does not even deserves debates or discussions. Just decision making. It’s a simple problem and it deserves a simple solution.

The specifications fit on a few sheets of paper. They can be read and understood by anyone who cares without investing significant efforts. Simple use cases can be illustrated. People get it.

There are so many ways in which different websites can’t talk to each other, which makes it painful to develop applications and forces people to re-implement the same things over and over again. In the new Web-SaaS-driven world, it’s a shame. Especially since the underlying protocol does not prevent anything. It’s just that one took the time to write down the problem and write down the simplest solution that could work.

Sure, you could go out and write something generic that solves everything (it would probably end up looking like RDF). In the end, unless you know what you’re searching for, there is no way you will find it. Abstract tokens don’t help anyone.

I’m currently writing my own spec (more information soon). What are your problems in integrating with other applications?

Note to self: This post contains too many acronyms and references. I should look these up and link in the future.

Most software design out there is a matter of personal taste. There are very few widely agreed upon rules. It happened to all of us. You get to read a particularly bad piece of code and think it requires a complete rewrite. In most cases, it wouldn’t be hard to get people to agree with you. Rewriting would make everything more beautiful and allow easier modification. However, it has a terrible cost. It will always take longer than you expected. Bad code has this ability to hide features inside. While it may happen that some portions of code are dead, most of the time, they serve a very specific purpose your great new design wouldn’t have considered.

Major backend rewrites also tend to leave the front-end part behind. It will break user experience. All the polishing that was made on the interface is likely to be gone because it was not re-implemented or simply left broken. It would probably take months to reach the same level of external quality (compared to days or weeks to improve the internal quality).

When you are at point A and think it’s not the best place to be, there is nothing wrong with trying to go to point B. However, teleportation does not exist in the world will live in, and your app won’t just appear in point B on the next day. Even if you rewrite everything, get a perfect backend and a better front-end. All this legacy data won’t just transfer itself. Data conversions are a pain. One of the reason the code was so bad in the first place is probably because the data model was messed up. Converting data for all the edge conditions is a very long process and is always prone to break, which leads to users complaining. Of course, this implies that your upgrade process even has a way to handle data conversions as part of the regular upgrade process.

Before thinking about your grand new design, think about transition. It will probably expense more effort than the development efforts. After you rewrote everything, will you be able to make it from A to B?

Recently, I started working on restructuring the wiki plugin API in Tikiwiki. The plugins are great. They allow to find the different features in the wiki and create create applicative wikis. The problem is that they are hard to use. The best ones have too many parameters and not all of them are really well documented in the UI (while sometimes documentation is better on the doc site). When too many parameters are used, it just becomes unreadable. I decided to rework these during TikiFestStrasbourg after all of us learnt one new thing about plugin capabilities during discussions.

These were some of the issues:

• Documentation in UI was a short blob of text containing HTML. It was not meaningful to users and a pain for translators to manage. Parameters were rarely detailed.
• Plugin list was not filtered. All plugins were listed, even if related features were turned off. This created too much noise.
• The syntax was hard to understand and a user interface would help a lot.
• Caching does not behave nicely with some plug-ins.

To solve these issues, more meta-data is required about the plugins. The naive solution is to rewrite the plugin API entirely and make it good. After all, at this time, each plug-in is stored in a separate file containing two functions with a naming conventions. This is not a modern GoF-endorsed design!

Well, rewriting is a bad idea. Tikiwiki ships with around 75 plugins, plus a few in a separate folder to be enabled by sys-admins in controlled environments, plus an unknown amount in mods, and all those custom plugins written for specific applications we have no control on. If we only had to consider our own work, it would still take around 40 hours to convert them all, considering no clean-up is made and documentation is only entered as-is without improvements. Rewriting the API would be a 3-4 hour job at most. The conversion is uncertain the result would break upgrades on all customized installations.

I’d much rather compromise a little bit on beauty to save some pain. Adding an extra function to provide all the meta-data and making sure that the functions who use these act conditionally based on if the new way of doing things is available. I can keep working on improvements without having to convert everything at once. No functionality is broken.

Of course, the transition still has to be made, but at least it provides us with more time to do it. No one will scream that their favorite plugin is broken. I will be able to merge back in trunk much faster and get help from the rest of the community.

There is more than just code involved.

At this time, I think there is nothing more important in an Open Source project than to have face to face meetings. I spent the last week in Strasbourg for the TikiFest. I don’t think any of us really knew what was going to happen. I had this idea that it was a perfect moment to release the next major version of Tikiwiki. Some thought it was about security or other technical aspects. We were all wrong. During those days, we got to know each other a little more. For the last years, we have been discussing over IRC, exchanging an occasional email, but we really didn’t know each other. I think that this alone will change the project’s dynamics in the future.

Sitting together in the same room working on the project made it clear that we were all facing similar issues. We could discuss them and see how to improve the situation in the future. No mailing list or chat session could have done as much. We would get up early in the morning and not really see time fly by, alternating between discussions and code. Only our stomachs could bring us back to reality, and that was usually very late.

One of the most important changes that we made is change the release schedule, or create one for that matter. It has been over 3 years since the last major release. Trunk changed so much, we barely know what has been added. The changelog is terrific and certainly not useful to anyone due to the very long length. We decided to release twice a year. The primary reason why we could never really release is that new stuff kept being added in. The reason it came to be that way was that everyone needed that other feature to be added before the release. Otherwise, it would be years before it would be part of a stable release. Well, it has been years since we had a major stable release.

Getting more frequent releases was an easy decision. The discussion was in fact, very short. I think we had everything settled in the morning of the very first day. Later on, this allowed us to assign dates for some major changes, like fully dropping PHP 4 support. Timed-based releases have huge advantages when it comes to open source projects. It allows to observe how things are evolving, take decisions and still provide users with a decent amount of information. It’s not about saying that somewhere in the future we will drop PHP 4. We can provide a month and base it on the growth of PHP 5.

I really have the feeling I am now working on a new project, even if very little of the code changed during those last few days. Just like many other events where developers gather and discuss critical issues, I have some doubts about wether everything discussed will end up being done. However, I have a good feeling. The team is committed and deeply involved in the project. It’s a great thing to know we all share a common vision.

During the entire week, we didn’t have so many hot debates (except maybe one where I exaggeratedly bursted out). Some things are just plain good for a project, and when a project ran without any major guidance for years, some basic, typical, structures are welcome by everyone. One of the only issues we couldn’t quite agree on was what to accept in stable branches. Tikiwiki has a long history of being free for all, which was convenient for every major contributors. With the new model, stable branches are required. Not accepting new features is obvious. Some minor enhancements are acceptable, some not. UI enhancements are even harder to decide on. What is a bug anyway? Is it a major one? What is major? What to accept is an entire gray zone. It’s extremely subjective. I had to rollback commits. I hate doing that. Without people to discuss the issue in front of me, I don’t think I could have done it. In total, we reviewed around 8 commits made after RC1. It took us at least 2 hours to decide which one we couldn’t accept.

Rejecting someone’s contribution is hard. At least I could motivate myself by the fact that this was only the stable branch. They could still apply their patch on trunk. However, with faster release cycles, we will have to keep trunk as somewhat stable. We already have this idea of experimental branches (or feature branches) for new things to mature before being merged, but it really adds overhead. Subversion is quite hard to handle on the branching and merging issues. If you are familiar with version control, it really all makes sense, but it’s a barrier to entry. I started writing scripts to do the hard work, but they still require people using a shell to use them.

Establishing a software process to ensure quality without breaking the team dynamics is hard. Doing it on a community of volunteers is even harder. Some well known best practices just don’t apply. Unit testing? Forget it. Iterative development? We don’t even know what people will be working on or when they will have time to do it. With at least 6 years of development, people got used to their way and, let’s face it, it worked so far. Only part that didn’t work is that the software could never quite release. The decisions we took in Strasbourg were required to improve the releasability of Tikiwiki. I hope it will work out with the community.

For every other decision other than the release cycle, we basically had to take accountability for it. We built some sort of road map, but it can’t really apply to anyone else as we can’t assign tasks to anyone. People will keep volunteering on what they want and we have no control over that. This leads to a strange phenomenon in the roadmap. The roadmap is more about dropping things than about adding things. Tikiwiki is huge. It has features for everything. Letting people add whatever they want has always been very important. It lead to features no one could have imagined with incremental changes and clever combination of features. However, for all the great things that happened, some things were added and forgotten by their authors, remained obscur, unmaintained and unused. For all we know, it might not work at all as it rot and broke. These things are a burden for the project administrators, so they will gradually be removed. Ideally, things like removing unmaintained features and dropping support for older technologies will reduce the weight we have to carry and allow to build greater things.

In some theoretical sense, developing the complete infrastructure before implementing any visible functionality might be efficient, but in a practical sense, managers, customers, and developers begin to get nervous when too much time goes by before they can actually see the software work. Infrastructure development has the potential to become a research project in creating a perfect theoretical framework[...]

Sounds like a familiar problem? Taken from Software Project Survival Guide. I can’t say it’s my favorite from McConnell, but it’s still right on.

Today is just one of these days I can just look back and laugh at my own behavior. I have been working on a personal project for a while now (should go public soon). Of course, it started off with many great ideas and I could have fun just thinking about it. When came the time to actually code it, motivation dropped. The problem was really that, while I had a great goal, before getting close, I had to get all the ground work done.

What happened? Well, it froze. I stopped working on it for months, until recently. When I got back to this project, I came back because there was something specific I wanted to implement in it. When I took a good look at at what I had in progress, I realized that the things I was focusing on were not getting me any close to my goals. I just left everything as is. Tests were running. Some code was not used yet. No problem.

Instead of starting over from where I was, I mapped out the high level features I wanted it to achieve and wrote down a road map. It was not based on building good foundations, not based on a good architecture. It was based on what’s needed for the software to be any useful and what I felt like working on. What did it change?

• Changes were visible on the final product
• At every step, I would get closer to being able to use it, and find out different ways to use it
• I got motivation to work on the project
• The project evolved more in the last two weeks than ever before

So, why today? Well, that feature I had half started months back, I finished it today in just 30 minutes. Months of no progress to avoid 30 minutes of work. It’s not that it was long, certainly not hard. It was a boring task. It was necessary, but along it did not do any good. Today, writing it enabled a very powerful feature. Even if it was boring, I was happy to do it because I would then see the whole thing in action. It’s not quite complete yet as it still misses a few critical features required to normal use, but I can already use it for my own needs, which is great.

Now, if I had done it a few months ago, I’m pretty sure it would have been more than 30 minutes of work. It just takes me more time to do work when I’m not motivated. It’s also likely that the feature would have been more complete. Rather than doing what it has to in order to be useful, it would have been what it should be not to be so boring to write. Goldplating? Scopecreep?

The scary part is that I’m pretty certain it’s not the first time I’ve dropped a project just because I didn’t feel like doing a tiny little part.

Recently I have been reading Programming Collective Intelligence by Toby Seragan. I love the subject. It’s all about handling large data sets and finding useful information out of it. Finally an algorithm book that covers useful algorithms. I don’t read code-centric books very often because I think they are boring, but this one has a great variety of examples that keep it interesting as the chapters advance. There are also real world examples using web services to fetch realistic data.

My only problem with the book is that there are way too many code samples. It may just be my training, but there are some situations where just writing the formula would have been a lot better. Code is good, but when there is a strong mathematical foundation to it, the formula should be provided. Unlike computer languages, mathematics as a language has been developed for hundreds of years and it provides a concise, unambiguous syntax. I like the author’s effort to write the code as a proof of concept, but I think it belongs in an appendix or on the web rather than between paragraphs.

Which one do you prefer?

def rbf(v1,v2,gamma=20):
    dv=[v1[i]-v2[i] for i in range(len(v1))]
    l=veclength(dv)
    return math.e**(-gamma*l)

or

For that kind of code, I vote #2 any time. I’m not a Python programmer. I can read it without any problem, but that vector substraction did seem a little arcane at first and it took me a few seconds to figure out, and I’m about certain that even a seasoned Python programmer would have stopped on that one. It’s not that it takes really long to figure it out, but it really keeps you away from what is really important about the function. What was important was that you want to score points that are far away from each other a lower value than those that are close by. Anyone who has done math could figure it out from the formula because it’s a common pattern. From the code, would you even bother to read it?

This is a very short code sample. In fact, it’s small enough that every single detail of it can fit into your short term memory. Here is an example that probably does not. In fact, I made your life a lot easier here because this code was scattered across 4 different pages in the book.

def euclidean(p,q):
    sumSq=0.0
    for i in range(len(p)):
        sumSq+=(p[i]-q[i])**2
    return (sumSq**0.5)

def getdistances(data,vec1):
    distancelist=[]
    for i in range(len(data)):
        vec2=data[i]['input']
        distancelist.append((euclidean(vec1,vec2),i)
    distancelist.sort()
    return distancelist

def gaussian(dist,sigma=10.0):
    exp=math.e**(-dist**2/(2*sigma**2))
    return (1/(sigma*(2*math.pi)**0.5))*exp

def weightedknn(data,vec1,k=5,weightf=gaussian):
    dlist=getdistances(data,vec1)
    avg=0.0
    totalweight=0.0

    for i in range(k):
        dist=dlist[i][0]
        idx=dlist[i][1]
        weight=weightf(dist)
        avg+=weight*data[idx]['result']
        totalweight+=weight

    avg=avg/totalweight
    return avg

or

The formula is insanely shorter, and the notation could certainly be improved. What’s the trick? It relies on well documented language features like vector operations and trims out all the python-specific code. I actually wrote more than I had to because gaussian itself is well defined in math. Because all operations used are well defined, whichever language you use will probably support them and you can use the best possible tool for your platform. The odds that I use Python when I get to use those algorithms is low, so why should I have to bother with the language specifics?

The author actually included the formula for some function in the appendix. I just think it should be the other way around.

After the courses, the exams, the rituals and the various parties, I came to realize it was all finally over. I mostly completed my studies by now. I still have one last course remaining this summer, but most of the people I spent all these years with are moving on now. It really is the end, and I already feel nostalgic of those years.

This last semester was a blast. I don’t think there is a single moment I could relax. All I could do was look forward to a date just to realize I had an other blitz coming up.

• January
  • Cross Lingual Wiki Engine project launch
  • CUSEC 2008
  • CLWE core
• February
  • Architecture for Translation Synchronization document
  • Version control presentation redaction for PHP Quebec
  • Mid-term report for school
• March
  • Blitzweekend
  • CS Games
  • PHP Quebec 2008
• April
  • Final report for CLWE
  • Paper redaction for WikiSym08
  • End of semester

This list isn’t even exhaustive because it ignores most normal school assignments, my regular work and various local PHP Quebec activities. No wonder I have not seen time passing by. Next week I will be in vaccation under the sun and I am really looking forward to it.

What is ahead? Mostly fuzzy. I refused all offers to work for large companies. I will simply continue my consulting work for a while with a few ventures along the way and I will try to keep doing some work on CLWE. Back when I started college, I had no idea what would be 3 years later. When I started university, I had no plans for the post-study period 4 years in the future. Nothing changed to my vision, but it has been a long road already.

A few months ago, I made an update on my system running 7.10 and it turned bad. The package actually got corrected very fast, but I had no time to waste so I re-installed my system. I had been upgrading my Kubuntu distribution since 6.06 and didn’t have any CD for 7.10. To get multiple screens working and the non-conventional screen resolution of my laptop, I had been carrying a heavily customized version of my xorg.conf file and a few scripts to handle the different resolutions I could need (dual head at home, single head when on the road, and a cloned 1024×768 for those times I had to present. Upgrading is always a mess, but I didn’t feel like downloading all updates, so I got an alpha release for 8.04. I was surprised to see it first correctly configured my resolution to 1280×800 and didn’t need that 915resolution fix.

OK. Maybe that wasn’t the smartest move. To keep the story short, I couldn’t get the extra monitor on my desk ever since that upgrade. My xorg.conf file would not work anymore and the configuration tools were broken. Since I had too much to do, I couldn’t get the time to investigate, but today I did. I seems like the way X is handled is having a huge face lift. There was something comforting about the xorg.conf file. If something messed up, you could always fix it by knowing some arcane lines and searching for solutions from lynx. However, it seems like that file is about to go extinct. This is what my file looks like at this time:

Section "InputDevice"
        Identifier      "Generic Keyboard"
        Driver          "kbd"
        Option          "XkbRules"      "xorg"
        Option          "XkbModel"      "pc105"
        Option          "XkbLayout"     "ca"
EndSection

Section "InputDevice"
        Identifier      "Configured Mouse"
        Driver          "mouse"
EndSection

Section "Device"
        Identifier      "Configured Video Device"
EndSection

Section "Monitor"
        Identifier      "Configured Monitor"
EndSection

Section "Screen"
        Identifier      "Default Screen"
        Monitor         "Configured Monitor"
        SubSection "Display"
                Depth 24
                Virtual 2560 1024
        EndSubSection
EndSection

It really is different from the 222 lines file I used to carry over from installation to installation. The only thing specific to my system on it is this section:

        SubSection "Display"
                Depth 24
                Virtual 2560 1024
        EndSubSection

The only purpose of it is to tell the Intel driver to allocate a larger framebuffer at X load time in case I want to extend the Desktop. It made sense before to allocate only what was needed at load, but since you can now change the resolution dynamically, reloading X is not an option.

With fairly simple commands, the resolution can now be changed and it’s mostly safe. Never prevented me from using my computer. The only problem is that the GUIs are lacking at this time, so those commands may not be good for everyone and there are some parameters I wish I didn’t have to understand.

To get my second monitor working, I had to use these commands:

xrandr --output VGA --right-of LVDS
xrandr --newmode 1280x1024 108.88 1280 1360 1496 1712 1024 1025 1028 1060 -HSync +Vsync
xrandr --addmode VGA 1280x1024
xrandr --output VGA --mode 1280x1024

Other than the second line, this is fairly simple. Tell it where the second monitor should go, register a resolution (Google told me the line, I didn’t figure it out), tell that the resolution applies to the VGA monitor and activate it. In the blink of an eye, the desktop is extended. No need to restart X anymore.

All this messing around with resolutions was always annoying for laptops running Linux. On desktop, all you have to care about is your own setup. However, with a laptop, the setup can really be anything. Now if I could just have a GUI to select the monitor resolution, I would be fully happy. I guess this is all going to arrive before the final release of 8.04. Still, the situation is a lot better than it used to be.

xrandr could use better documentation, but I doubt it was meant to be used by end users. Just calling the command lists the available screens and the known resolutions for them, so that is easy enough. However, the –help option does not help so much with what is expected as an argument. There is some help available on forums and such if you know what to search for.

Saturday morning. PHP Quebec Conference 2008 came to an end. This year, I was making a presentation on version control techniques, branching methods and general quality assurance elements. This is not quite the typical subject you can expect at a PHP conference, but I still think bringing more general software development topics to web developers is important. It was not the first time and I guess it won’t be the last.

However, reading the feedback forms, I found out that there was great variety within the audience and I don’t know if there is a way I can address everyone. How can it be to give enough information to teach something to those who actually know quite a bit about software development and at the same time not loose those who are self-thought and basically have no structured foundation? I guess this is something I will have to try and solve for the next time I make a presentation. That and my habit of speaking too fast.

Overall, the session went fine and I am happy with it. Other than the fact that I needed 3 laptops to get the projector working, everything went fine. I noticed that I had forgotten my notes after the presentation, so that’s a good sign I didn’t really need them. The negative comments I had in the feedback forms last year didn’t show up again this time, so that’s also a good thing.

Feedback forms are great. Especially when the organization team has someone as dedicated as Anna FIlina to type back all comments and hand them out to the speakers within hours of the session. Fill those comments, write down what you think should be improved. I think most speakers gladly accept the critics when they receive them.

Anyway, if you attended my presentation and have comments about it you didn’t write on the form, feel free to email me. In the same way, if you have questions you couldn’t ask, I would be glad to help out. Who knows, if I ever give this presentation again, I might be able to incorporate a few more details.

The Blitzweekend was quite a special event. When I first saw the announcements, I thought it was like our CodeFests. In fact, the concept is very similar, but the community is completely different. It’s simply not the same people. In CodeFests, most of us are from the Open Source community. Our goal is to play with technology, collaborate on projects and work together to learn. At the Blitzweekend, this kind of collaboration did not exist so much. Outside of the Tikiwiki room, all projects were isolated. It wasn’t as much about technology as it was about business.

I still had a great time and met with very interesting people, but it wasn’t quite what I expected. Our goal for the week-end was to make a first release of Tikiwiki 1.10, which we decided to label as beta. Otherwise, it was just a great opportunity to get together and meet other contributors. The Rest of Blitzweekend was targeted towards creating a product, starting a company and making a pitch about it. The whole competition thing wasn’t for us, but I thought it was quite nice to see all those ideas.

However, it was hard to evaluate the merit of the projects. Some projects had excellent ideas and made a great pitch, but I couldn’t be convinced that they actually got anything working during the week-end. At best a nice user interface with functional links. No proofs it actually works beyond navigation. In other cases, the projects did realize something over the week-end, but it seemed like a lot was already prepared before the first day. I was a little disappointed by the lack of attention the projects made out of self-interest and passion received. Seemed like the fact that the project was useful to you and was a nice accomplishment in a week-end was of no importance. Unless you were hunting for millions, making a presentation was a waste of time.

Don’t get me wrong, I loved the event and have nothing against entrepreneurship, but I do wish the next editions will leave a little more space for technology and collaboration. On Friday night, there was a moment where people had to raise their hands depending on if they were designers, entrepreneurs or developers. The developers and designers in the room were litterally a minority. How do you actually expect to get a product out the door with such a proportion? Too much focus on business will drive developers away. Sure having a contest for business plans and prototypes is nice, but I don’t think that closing the door to the technical community is such a good idea. I think the first step would be to accept that not everyone takes on the challenge of developping something over the weekend with the sole idea of making millions out of it.

The second step would be to make sure that collaboration can actually happen. If it’s not to be with other people and share something, the challenge can be taken from home and does not require anything else. I wouldn’t have had a problem with answering a few questions and helping out other teams during the week-end.

Anyway, the whole thing was very well organized. Location was suitable, although a little far from downtown, and the shared room was a nice place to meet with the other participants (at least, those that ended up taking breaks).