Open Source

Getting The Most Out Of A Hackathon

Posted on Updated on

The Basics:  A hackathon goes by many names – hack day, hackfest or codefest. Essentially, a hackathon is a design, build and demo sprint-like event where you get random people to team up and collaborate intensely, usually for 24 to 72 hours. The skills required are typically in software development, graphics or human centered design; user interface and user experience design, project managers, and domain or subject matter experts.

The organizer will provide some challenges, and the participants will form teams and try to come up with their best ideas/solutions. Eventually, the team(s) who presented the best ideas/solutions will get to win some cool prizes. Prizes can be cash or some gadgets.

Here are some thoughts about how to make the most of your participation in a Hackathon.

Ideate – It’s important! You should be prepared to spend time brainstorming… first defining what you’ll be building. Start with the kind of challenges or problems presented by the organizers. Social or support forums are also a great source of insights into what people are frustrated with, their problems, and what they’re asking for. This way you can be certain that you’ll be developing a solution that provides value and solves a problem.

Do not take on an idea because it sounded the most impressive or tech savvy. Think about the kind of impact your work will have on users. Take time to make sure that your idea is impactful and this should save you time down the line when you need to put all the features together.

Sometimes the idea falls into your lap in a flash, and other times it takes some digging to lock onto a great idea. The hackathon will teach you how to be patient under pressure. Keep in mind that at some point (ideally before the end of the first day), you definitely need to start building.

The All Conquering Team – To win the hackathon, you have to have a dream team. Usually the first thing to do when you get to a hackathon is to scout the registration form to get a sense of who else (and what skill set) is around. Often your team will be random people. Your goal is to locate people for these 3 key roles and ask them to join your team (would be great if you yourself are one of these 3 as well):

  • The Dev/Coder — this is someone with front-end development experience. mobile development is even better. If your team doesn’t have a single person who can code, it’s time to find one.
  • The Presenter/Pitch maker — this is someone who will sell your idea to the judges. You need a good mix of confidence and empathetic charisma. If your team can’t sell, it won’t matter how great the idea is.
  • The Designer — this person understands Human Centered Design – they know how to start with people, and then add technology to the problem. It would be great if they are good with user interface and user experience design. This role is a strong recommendation.

A hackathon is very short. Time flies when you are having fun, 4-5 people are trying to break the ice, pitch ideas, win over team-mates, and still get working. This is the time to communicate openly about what you think (and know) is incredibly helpful. If you have a question, ask for clarification. If you think of a better way to solve a problem, tell your teammates. Don’t hope that someone will see it the way you see it. Make sure that everyone is on the same page – this will save you time down the line.

An important part of finding a good team is determining to be a great team member. Hackathons are high stress, so you want to make sure you can rely on your teammates and they want to feel the same way about you. There is no time to worry about how or whether you will get along with a teammate. Going into a hackathon with people you have worked with before can save you the mental stress and energy of figuring things out during the hackathon, but you won’t always have this opportunity.

Figure The Heart and Soul – Figure out what your hackathon host and sponsor are looking for. Some hackathons will be more impact driven while others may be more technology focused. Knowing the focus of the organizers will help you decide how to narrow down your project idea. If they have organized previous editions of the hackathon, research the winning ideas. See what ideas were accepted to participate. Researching each judge’s background before the pitch can also make a difference on how well you do in the competition. Without a direction, you won’t be able to get to where you want to go.

During the event, make time to talk to the organizers and sponsors – figure out if there are products you will have access to which may help you overcome roadblocks. Talk to them about the idea you are building and the problem it solves, as well as your approach. The advice you will get ranges from which pathways to not tackle, or how you can do it more efficiently, which will save you lots of time.

If you are a developer/coder prepare by reading all about the APIs you are expected to work with and researching libraries you can use. This way, on the actual day you can focus solely on building your prototype and every team member will be on the same page.

Also, leverage the opportunity to network and find out about what other features or even different integrations their customers are asking for. You might just get your next great product idea from them! Don’t be afraid to reach out and ask for advice.

Learn, Unlearn and Re Learn
Get prepared – there’s going to be a lot of learning that happens in such a short time. I have been to a few and it’s clear that even in such a short time you can learn anything if you really want to. You will likely encounter tools you have never used, get insights into domains other than yours. A hackathon is a great place to learn how to learn. Although winning is nice, learning and appreciating the unique experience that a hackathon offers is something I’ve always enjoyed.

Probably the most important life lesson you will get at a hackathon is how to fail fast, and fail often. You will face some uncomfortable moments such as you are not the only expert in the room, but if you learn to deal with simple and small failures, you will muster the power of persistence, endurance and teamwork. Most importantly, that it’s okay to fail. Every failure will lead to a new insight about yourself and the world. Challenge yourself, and apply for hackathons for areas you know nothing about. You will walk away with newfound knowledge.

Coding – How Deep Should You Prototype?
So you have this cool idea – doing many awesome things – the tricky part is stripping it down to its core and focusing on building only what’s essential to deliver it’s value proposition. After all, you have to make it real. It’s time for the coder and designer in your team to start shining – by building a Proof-Of-Concept (POC). We are not looking for a bug-free solution, infact, you can even have zero functionality. Your audience wants to see, so visualize the solution, help them understand how your idea works. Try to make it look really good. Judges can easily be impressed when they see your team coming up with such a beautifully designed product in a short time.

A good technique is mapping the entire user flow you have in mind. This activity is best done along the product, design, and the dev team so everybody brings their perspective to the conversation. Techniques like Story Mapping should get you started.

After mapping, review the flow with the dev team and make them estimate how much it would take to accomplish that. If it requires more time than the hackathon allows, you’ll have to prioritize features and build only those essential to the core value of the product. If you can, work on everything that’s not code beforehand. It is of top priority that you define the specs of what will be built and that the design team gets mocks ready.

The Pitch – Your 3 Minutes Of Fame.
Your presenter needs to prepare for the presentation. Do not wait till the end to put this together, start working on it while the POC is being built. If the presenter is also the coder, prioritize the POC and then get to the presentation. You will need about 2~3 hours preparing for the presentation. 6 slides, 5 bullets on each. The slides are complimenting your own charm and charisma as you interest the audience enough to buy your idea. There’s no hard and fast rule on slide content, but generally make sure you get this across:

  • The problem statement — Prepare a few slides telling people about the background of the problem that you are trying to solve. Remember we are trying to solve a problem using technology.
  • Demo — People get bored easily. After telling people what the problem is, straight away tell them how you are going to solve it. Quickly show them your demo and WOW them. (Please make sure your demo works!)
  • Compare — Do a comparison. Is there already an existing solution to the problem, if there is, how is your idea better?
  • Hidden Slides — Always prepare some hidden slides that discuss potential future enhancements of the idea, business model, and what are some difficulties you faced during the hackathon. These can be useful during the Q&A.

The presentation is the only chance where you can sell your idea to the judges, the only time you can tell them: “my(give) idea(me) is(the) brilliant(prize)!”.

And Finally…
The most meaningful hackathons and experiences revolve around the people you meet, and not just what you build together. Your teammates can turn into future coworkers, collaborators, and friends. You get to know someone very quickly when you have to problem solve together in a compressed time and place – think of it as the perfect relationship icebreaker!

Hackathons are not just pizza, soda and free high speed wi-fi all day (and night) long – they are intense! You will not do much good for your team if you are not in a better shape physically and mentally. You’ll have a much happier and more productive experience if you take care of yourself along the way. Drink water. Take care of potential distractions like small errands – get up and walk down a flight of stairs – do whatever you need to make your hackathon a fun and happy experience, whether that means going home to sleep or taking breaks to get some air and some salad.

Prepare for the prize. Of course it’s not guaranteed, but if you work diligently, and follow the guidance above, most likely you will win something. Plan for what to do with tricky prizes like mentorship and incubation – which might require you to set up a business entity. Decide if a cash prize will go to developing the idea further or not.

Not all hackathons are the same, but when it comes to experiences preparation and good team communication will get you through. Many teams think the best outcome of a hackathon is winning the prize, but the better goal is to build the prototype of a product for which there is a proven market need.

Good luck in your next hackathon!

Advertisements

Uganda’s Policy and Strategy on FOSS and Open Standards

Posted on

The National IT Authority of Uganda (NITA-U) has released, for public review,  The National Free and Open Source Software, and Open Standards Draft Policy. Download PDF Here: Open Source Policy V0.3 2014-09-21

NITA-U has also released the accompanying strategy:  Open Source Strategy V0.3 2014-09-21.

It appears that both documents have received input from James Wire (@wirejames; ), a Kampala based FOSS Advocate. As of this writing, NITA-U seeks input from members of the ICT Association of Uganda, a body that brings together professionals in the sector.

The policy makes some exciting declarations:

Where there is no significant overall cost difference between open and non-open source products, open source will be selected on the basis of its additional inherent flexibility.

The Government will expect those putting forward IT solutions to develop a suitable mix of open source and proprietary products to ensure that the best possible Value mix is obtained. Vendors will be required to provide evidence of this during a procurement exercise. Where no evidence exists in a bid that full consideration has been given to open source products, the bid will be
considered non-compliant and is likely to be removed from the procurement process.

The Government will, wherever possible, avoid becoming locked in to proprietary software. In particular it will take exit, rebid and rebuild costs into account in procurement decisions and will require those proposing proprietary software to specify how exit would be achieved.

…and some even more interesting commitments:

All IT investments shall comply with Open Standard unless specific project requirements preclude use of an Open Standard or if the Open Standards are not appropriate. The Government will support the development of open standards and specifications.

The Existing IT systems shall be reviewed for Open Standards compatibility where appropriate.

There are also some places where a firmer voice could work better, in the interest of developing FOSS:

Because participation in the ongoing development and improvement of FOSS is the underlying basis for the promotion of FOSS solutions, MDAs/LGS should consider the extent to which they may wish to actively participate in the development of FOSS solutions that fall short of the project requirements for which the solution is used

And some places where the spirit of licensing derived works is broken:

No Discrimination against Fields of Endeavor: The licence must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.

 

Are you concerned about Free and Open Source Software? Does your government have a different policy? I would like to know. Well then, take a read and let me know what you think.

FOSSFA Weekend

Posted on Updated on

So on 12th October, i headed into Accra, for an epic FOSSFA Weekend.

Serving on the FOSSFA Council for a second term, this was once of the most critical meetings that FOSSFA held for its council, for out of this, a new FOSSFA executive was to be elected. The Council itself has been elected via a pioneering online vote, cast by all members. The current executive, has more than satisfactorily served enough terms. They served, selflessly, always, sacrificially, and they did it well.

A new executive has been elected out of this weekend, and its not just new wine, the wine-skins are new as well. A complete change of guard, one thing remains clear, FOSSFA can only go from one level to the next. The new executive has passion, lots of it, and they are younger, and more energetic. The air smells so good, and so fresh, that FOSSFA has used the weekend to establish commissions.

Here they are:

Judy Okite from Kenya, voted unanimously as the new FOSSFA Chair, taking over from Nnenna Nwakamna of Ivory Coast
Brian Ssennoga from Uganda voted as the new FOSSFA Secretary, taking over from Samer Azmy from Egypt
Neatness Msemo from Tanzania voted as the new FOSSFA Treasurer, taking over from Milton Aineruhanga from Uganda
Suen Ojedeji from Nigeria voted unanimously as the new FOSSFA CTO. (New Position)

Program Areas Committee Chairs:
a) Business & Innovations – Dele Ajisomo, from Nigeria
b) Networking & Capacity Building – Katim Touray from The Gambia
c) Education – Joris Komen from Namibia
d) Legal and IP – Nnenna Nwakamna from Ivory Coast
e) Localization & Diversity – Solomon Gizaw, from Ethiopia/Ireland
f) Government, Policy, Open Government and Data – Dorothy Gordon, from Ghana
g) IDLELO 6 Chair – Joe Sevilla from Kenyan

Lots of work to do, taking Free and Open Source Software allover Africa, but for now, we will wind up and integrate ict@innovation, as we run up to Nairobi 2014 for IDLELO

FOSSFA is the Free and Open Source Software Foundation for Africa, and can be found at http://www.fossfa.net , and on Twitter: @FOSSFA, and on Facebook: http://www.facebook.com/groups/163634167084849/?fref=ts

My 10 year old Open Source Hero

Posted on

Please Meet DR. EDGAR DAVID VILLANUEVA NUÑEZ, Congressman of the Republic of Perú.

He is my Open Source Hero for the year 2012 – and here is why!

10 years ago, The Peruvian government introduced a bill (English trans.) mandating the use of open source software by the state. The bill admirably proclaims:

“The basic principles which inspire the Bill are linked to the basic guarantees of a state of law, such as:

  • Free access to public information by the citizen.
  • Permanence of public data.
  • Security of the State and citizens.”

Microsoft General Manager Señor JUAN ALBERTO GONZÁLEZ responded by writing this letter to Peruvian Congressmen Edgar Villanueva Nuñez, containing many of the fallacious arguments that Microsoft has used against open source software in the past.

Congressman DR. EDGAR DAVID VILLANUEVA NUÑEZ replied with an insightful letter that cuts through the empty Microsoft arguments to expose the fallacies of its F.U.D. tactics.

FULL REPLY HERE