March 7, 2014
This is the third post in a series about how to throw the perfect hackathon.
Someone call in the lawyers… Hackathons have both grown in size and spread around the world in recent years. Companies are using hackathons to engage their communities, non-profits are using them to help solve big problems, and so on. This increased awareness of hackathons means that people are looking at different IP and ‘openness’ arrangements — some of which you might want to think through with a lawyer.
Remember I’m not a lawyer - I’m a hacker. This isn’t legal advice; I just want to highlight some common issues you might want to keep in mind.
Who owns the output?
Over the past few years, organizers have experimented with different ways of capturing and distributing the work created at hackathons. Some of these have involved different intellectual property (IP) arrangements; I want to review these and offer some thoughts on how you might tackle ‘ownership.’
At the vast majority of hackathons, participants retain ownership of their work and this is usually the best model. My colleague Brian has written on this subject before. As he points out, a transfer of IP towards the event organizer seldom aligns with your goals and won’t build long term engagement with the developer community.
Rewired State, based in the UK, has tweaked the traditional hackathon model with their signature Hack Days. There are a few variations of hack days, but they include some form of IP transfer. Two points are important to note here: the developers are paid at market rates and the IP transfer is completely transparent & explicit when participants register. You can learn more about Rewired State and the different kinds of events they run on founder Emma Mulqueeny’s blog.
The international civic-focused hackathon series Random Hacks of Kindness (RHoK) takes a different tack. Hackathon projects must be published under an OSI approved license and the code is made available on a publically accessible code repository. Again, this is clearly communicated to the community in advance.
While these two examples are quite different in nature, they are both upfront about their restrictions / conditions up front for potential attendees.
“I don’t want people to use my data after the weekend.”
Executed properly, hackathons can be a quite compelling for businesses. It’s an opportunity to expose talented and motivated people to your team and technology. I’ve seen lots of great examples where companies have used hackathons as a way to get user feedback and new ideas. Of course, participants benefit too: inside access to new tech, it’s architects, and spirited competition.
However, providing data & services for the weekend and then revoking them afterward does not work. The only circumstance in which I’ve seen this done properly is when work at the hackathon revealed a major security bug in the API. In this case the organization explained to everyone involved why the API keys were being revoked and provided access again as soon at the bug was resolved.
From a practical standpoint, it’s going to be very difficult to ‘take back’ datasets that were released during the hackathon. If you know ahead of time that your data or services aren’t going to be public afterwards, don’t build your hackathon around them!
That’s all for this week. Next time we’ll focus on how to find and set up a great venue. Happy hacking!
February 28, 2014
The bi-annual PennApps hackathon, hosted by the University of Pennsylvania, has long been a standard bearer for large-scale college coding competitions. The Spring 2014 winner, The Homework Machine, embodies four key characteristics of a winning project:
Addresses a problem we can all relate to
At some point, every kid has wished for a way to automate tedious math homework. These students were probably more bored than lazy, but it’s a fantasy we can all wrap our heads around. Projects stand out when fellow participants, judges, and the less technically inclined general public can all appreciate their value.
This hack (1) learns your handwriting, (2) solves math problems, (3) guides a pen rigged to motors and a pendulum to mimic your handwriting, and (4) correctly answers in the exact right spot! Oh yeah, and it was built it in 36 hours!
The ‘internet of things’ is all the rage right now, and while hardware hacks shouldn’t be given preference over equally difficult software-only projects, they do tend to have more engaging demonstrations. The Homework machine produced tangible results - not vaporware promises of something to come.
A bit quirky
Creators Derek and Christopher didn’t plan to help 4th graders shirk their homework responsibilities. They just wanted to test their skills while having a good laugh, which is the whole point of a hackathon. You may learn new technologies, create the seed of a business, and meet recruiters too, but it’s all about building something awesome in a ridiculous setting.
February 26, 2014
At ChallengePost, we’ve worked with some of the best organizations in the world and powered more than 400 in-person hackathons and online software challenges. But, if you’ve never participated in one, you may not fully grok the ChallengePost experience. That’s why we put together this short video:
Curious about planning a hackathon or online challenge? Our team would be thrilled to help! Give us a ring at 212.675.6164 or email firstname.lastname@example.org.
February 25, 2014
Today’s blog post comes from Ross Kaffenberger, ChallengePost’s Head of Engineering. You can find him on Twitter @rossta.
Exchanging feedback doesn’t have to be painful
These days, software developers are living in a GitHub Workflow world. They develop new code on version-controlled branches and gather feedback prior to inclusion in the primary release, or “master” branch, through pull requests.
Our development team at ChallengePost has been using this workflow for almost two years with great success, although we’ve had our share of pain points. For better or worse, feedback typically happens asynchronously and is in written form. Convenient, yes, although this approach is not free of the wrinkles, especially when we use poor word choice, hyperbole, sarcasm, and other forms of counterproductive commentary.
This has led to resentment and injured relationships on occasion. In response, I’m working to improve how we give and receive criticism.
Let’s assume that, when done well, code reviews are a good thing. That is to say, the practice of giving and receiving feedback in a consistent, continual manner has true benefits. These may include improving code quality over time and driving convergence of ideas and practices within your team. In my experience, for feedback to be effective, trust amongst team members is a key requirement.
This may not be an issue for teams that have been together for a long time or share common values, but for others, trust has to be earned. In the absence of trust, there’s more opportunity for personal differences to get intertwined with feedback. While there are no quick fixes, what follows are code review practices that we have adopted to foster our shared sense of trust.
1. Adopt a style guide
Spoiler alert: code syntax and formatting are trivial choices. What’s most important is your team agrees on and adheres to a set of guidelines.
Take a few hours as a team to hammer out a style guide for each of the languages you use. Better yet, use a public example like GitHub’s style guide as a starting point. Besides the obvious benefits of consistency and maintainability, style guides reduce the likelihood of flared tempers during reviews; when you’re pushing to get a new feature out the door, it’s unhealthy to argue over whitespace. This works when your team respectfully follows and comments on style issues respectfully, saving concerns about existing guidelines for separate discussions.
2. Start with the end in mind
Imagine a developer who emerges, after hours or days off in the “zone,” with a sparkly new feature and asks for a review. All is good, right? Except that the rest of the team has issues with the implementation. Words are exchanged, the developer takes the feedback personally, and suddenly the entire team is distracted from shipping code.
Personally, I believe code review should begin well before the final commit. It can happen early on; in short discussions with teammates once the ideas start to take shape. Get buy-in on your approach before you’re ready to merge your branch. Opening a pull request and asking for feedback while work is still in progress is a great way to build trust between teammates, and reduce the likelihood that criticism may be interpreted as a personal attack.
3. Use the Rubber Duck
Rubber duck debugging is a method of finding solutions simply by explaining code line-by-line to an inanimate object. We’ve found it helps to do the same with our writing, especially when our first instinct is to respond to code or another comment with sarcasm or anger. Take a moment to read your response aloud and question the wording, timing, and appropriateness. This includes taking into account the personality of the team members you’re addressing. Thoughtbot has compiled a useful set of code review guidelines to help both readers and writers respond thoughtfully. I also suggest that teammates share meta-feedback to ensure that everyone is hitting the right notes of tone and instruction.
The next time you feel pain in a code review, take a step back to consider what’s missing. It could be that your team needs to adopt some guidelines to reduce friction and ensure feedback is exchanged in as a constructive and positive manner as possible. After all, you have both code and relationships to maintain.
February 11, 2014
Every day, nearly one million people across the U.S. explore their local communities on delivery.com. And they don’t just order food. Consumers order delivery from local restaurants, liquor stores, laundries, dry cleaners, and a variety of neighborhood businesses — all at the click of a button.
In 2014, online ordering isn’t exactly new news. But an open API that connects apps to local merchants is! Interestingly enough, the delivery.com API is the world’s first open one of its kind.
What does this mean for you as a developer, designer, or online delivery tech fan? Now you can:
- Connect your app to 10,000 businesses in major cities across the country
- Allow your users to search, discover, and make purchases from local restaurants, liquor stores, and laundries
- Earn 25% of net revenue on every order that originates from an app that you create
And that’s not all…
This week, delivery.com launched a development competition on our platform offering $65,000 in prizes. In addition to a recurring revenue stream, the top seven apps have the potential to earn recognition from a star-studded judging panel and win up to $15,000 in cash.
Don’t miss the chance to revolutionize the future of online ordering and show off your creative chops. Join the delivery.com App challenge today.
More news on the delivery.com API:
With New API, Delivery.com Connects Content and Commerce [StreetFight]
Delivery.com Calls on Developers to Rethink The Online Ordering Process [PSFK]
delivery.com Challenges App Developers to Change the Local Delivery Experience [delivery.com]
Can’t get enough? Sign up to hear about ChallengePost’s latest software competitions & hackathons.