The FIRST Alliance - A whole new way to play

[plnyyanks]

Originally Posted by bduddy

While I understand where you're coming from, lately FIRST data has felt a little like this...

Originally Posted by artdutra04

My thoughts exactly.

I almost just posted that exact same comic, but scrolled down before hitting Submit.

I too, almost linked to the same comic. xkcd always seems to have something appropriate... I just feel like there are too many websites out there that do similar things, and if we focused our resources as a community, we could build one superior site. This looks like a cool resource and all, and it looks like some quality coding, but I'll stick with good 'ol TBA for the time being.

[GGCO]

Originally Posted by plnyyanks

I too, almost linked to the same comic. xkcd always seems to have something appropriate... I just feel like there are too many websites out there that do similar things, and if we focused our resources as a community, we could build one superior site. This looks like a cool resource and all, and it looks like some quality coding, but I'll stick with good 'ol TBA for the time being.

Maybe a good question to ask is why? Currently the only things we are missing are stats from previous years (which I don't think many people use anyways) and videos (which are a priority right now).

What features would The FIRST Alliance need for users to switch over?

What other features does the FIRST community want to see? If you're looking for ways in which the community can help build a great site, then help us out here. We're two committed individuals who have so far proven they can respond quickly and release updates in very little time.

[jwfoss]

Originally Posted by GGCO

Maybe a good question to ask is why? Currently the only things we are missing are stats from previous years (which I don't think many people use anyways)

I disagree, i'd like to look at a teams performance over time. It can show you their consistency and if they are trending up or down as well.

[Siri]

Originally Posted by jwfoss

I disagree, i'd like to look at a teams performance over time. It can show you their consistency and if they are trending up or down as well.

I too use previous years' data for many purposes. It's quite handy to have it all in one place.

As to other reasons I'm not switching over, one (not necessarily the only/biggest) is simply integration and habit. You see that little TBA-> beside your team number in your user title? Convenient, no? I probably use frclinks.com/tba/nnnn almost as much as I use ChiefDelphi. It's amazingly convenient. (And maybe I'm just an old fogey at heart.)


All that said, I'm loving the OPR/DPR history charts. Is there anyway the events could be displayed in chronological/reverse chronological order? For instance, 357's is (reading down): DC Regional (week 5), MAR Championship (week 7), Hatboro-Horsham District (week 1), Chestnut Hill District (week 2). I guess you're displaying them in FIRST's "Regional Event" page order now? Maybe it's just me; that order really bugs me.

[plnyyanks]

Originally Posted by GGCO

Maybe a good question to ask is why? Currently the only things we are missing are stats from previous years (which I don't think many people use anyways) and videos (which are a priority right now).

The quotes below basically sum up my answer to your question. I use TBA's historical data all the time - whether its to look at a team's recent trends, to find a particularly awesome match from many years ago, or to just gather ideas and learn from teams of the past. I'm sure that, in the last two years, the majority of teams looked back to match video from 2007 and 2006 respectively to gain insight on the current year's game. That's the real beauty of TBA's huge archives.

Take a step back and look at the track record/competing standard argument from a different point of view. TBA has been around for a really, really long time (I don't even know when it was founded, but I do know that it's long before my time). They're established, I know I can rely on them and their server for anything I have my website throw at them. Now, TFA enters the scene. To me, it just seems a little bit redundant - why spend so much of your time writing a similar website to an already established one? Because face it, there are a ton of similarities between TFA and TBA. What if you, instead of spending lots of time writing portions of code that do exactly the same thing, you spent that time improving the existing codebase? Your site has a lot of cool features, and some ideas that I like, but I feel there's too much overlap between the two.

But hey, feel free to build an awesome site and convert me. You'll just have to establish your own niche.

Originally Posted by jwfoss

I disagree, i'd like to look at a teams performance over time. It can show you their consistency and if they are trending up or down as well.

Originally Posted by Dave Flowerday

I'll tell you what TBA has that you don't have yet: a proven record.

Originally Posted by Chris is me

That's part of his point... he's arguing against the merit of having multiple competing standards, when there is already one that is both well established and open source.

I haven't been able to keep up with this thread, and don't have the time to read all 100 posts, so I apologize if this has already been asked.

Will The FIRST Alliance have records for offseasons as well?

[mobilegamer999]

Originally Posted by SuperNerd256

I haven't been able to keep up with this thread, and don't have the time to read all 100 posts, so I apologize if this has already been asked.

Will The FIRST Alliance have records for offseasons as well?

Its a possibility, me and grant will talk about this one tonight.

[mobilegamer999]

Wow, this thread exploded a bit overnight. I'm going to lay out certain responses as I see them from my point of view.

Why did we make our own site?
There were quite a few reasons why we chose to make our own website. One reason was for the enjoyment/practice it takes to plan, design, create, debug, launch a website. It was something I had never done before and I felt like it would be a good project, and post-launch, if it got a good rep and people were using it, I would have no issue continuing to pay for the hosting. The second reason is that we wanted a site where anybody and everybody in the FIRST community could submit an idea and have it seriously considered as a new feature to the website, because, in my personal opinion, TBA is a website that is there and does not change unless the developers want to add/remove something, regardless of if that is their model or not, that is the feeling that TBA gave me personally.

Why not just build upon TBA's codebase?
The main reason is that its not THAT simple, TBA would not let some random outsider start modifying their code and pushing it live to the website. Even if they let us help them with their code, every time more people are added to a project, the slower changes become and the less often changes can be made.

Open Source?
I can almost guarantee that we will not open-source the website. Our biggest reason for this is that we made the API public and extremely easy to get started with so that there was no need to open-source the website. While we wont be open-sourcing the website, we WILL be providing very simple/easy to read code example for how to do just about every feature on the website in many common languages (C#, Java, Ruby, PHP, etc.)

How do we know the site is going to stay up?
I am going to say that as long as people are still visiting/using the site, I will continue to keep it up. You do not need to trust me on that, but that is what I'm sticking to.

How do we know that the API is going to stay compatible?
This is a very simple one. All versions of the API will be kept and stay accessible. The second version of the API will be requested at api/api.v2.json.php and so on and so forth. This is the easiest/cleanest way to implement a multi-version API.

Why use TFA over TBA?
There is no reason that you have to, its simply a matter of preference.

[Dave Flowerday]

Originally Posted by GGCO

When you say TFA looks like a hobby project, what do you mean by that?

I mean that it looks like you're paying for it out of your own pocket, or you're running it on a free service somewhere which likely won't handle the load when it becomes non-trivial. Anything that costs money to sustain and doesn't have a planned way to at least recoup operating costs qualifies as a hobby to me. End-user sites, like TBA and CD, can use advertising if needed to help defray the cost of hosting. You can't do that when your primary product is an API, unless you charge people to access the API which you have not indicated that you are doing. So, it comes back to my question of how are you going to pay for it when it gets busy enough that you need to run multiple servers and load balancers and such. Are you prepared to foot a $100+ bill per month yourself? If so, for how long?

Originally Posted by GGCO

The economics of this are a bit sketchy.

Originally Posted by mobilegamer999

if it got a good rep and people were using it, I would have no issue continuing to pay for the hosting.

Originally Posted by mobilegamer999

I am going to say that as long as people are still visiting/using the site, I will continue to keep it up.

These quotes should be major red flags for anyone considering developing against your API. You're admitting that it costs money to run, you're paying for it yourself, and basically you'll keep running it "if it gets a good rep and people are using it". That's not much of a guarantee to someone considering investing 100s of hours in developing an app against this API.

[GGCO]

Dave, you misquote me. I was not saying the economics of our service (ie how we're paying for it) are sketchy or that we don't have a plan, rather responding to another member's post.

http://www.chiefdelphi.com/forums/sh...7&postcount=96

As far as sustainability goes, we're going to implement ads soon to help recoup our costs. Secondly, we're not using a free service for hosting or our domain name or anything like that. We're paying for it just like anyone else. If you mean our design looks cheap that's one thing, but I don't know how by just looking at the site it gives you a feeling of shoddy work.

Maybe for an app like the Spyder, you'll never give up control and use a third party API. It probably just doesn't make sense for you guys and that's fine. However, we think there are a lot of other developers out there who have great ideas or tools they'd like to build and could really use our API. We're here to help those guys out.

[Andrew Schreiber]

Originally Posted by GGCO

As far as sustainability goes, we're going to implement ads soon to help recoup our costs. Secondly, we're not using a free service for hosting or our domain name or anything like that. We're paying for it just like anyone else. If you mean our design looks cheap that's one thing, but I don't know how by just looking at the site it gives you a feeling of shoddy work.

Your product is your API, how do you put ads in an API?

[GGCO]

Originally Posted by Andrew Schreiber

Your product is your API, how do you put ads in an API?

Ads on the site. Sorry for the confusion.

[Andrew Schreiber]

Originally Posted by GGCO

Ads on the site. Sorry for the confusion.

No confusion. You have stated numerous times that the API is your differentiator, this means that it will probably be your biggest cost. People like myself will be consuming your API and never hitting your website so I will never be generating revenue for you but I WILL be generating costs for you. Do you think, based on your current traffic, you will be seeing enough web traffic to cover your costs? I don't want to know numbers I just want to make sure you've considered this possibility.

TL;DR - How do you make sure that people like I are not just cost generators for you without creating API limits and forcing me to pay for more use?

[kmehta]

Originally Posted by mobilegamer999

Why not just build upon TBA's codebase?
The main reason is that its not THAT simple, TBA would not let some random outsider start modifying their code and pushing it live to the website. Even if they let us help them with their code, every time more people are added to a project, the slower changes become and the less often changes can be made.

Actually you can just fork the github repository and join the mailing list if you want to start helping TBA.

[Dave Flowerday]

Originally Posted by GGCO

We're paying for it just like anyone else. If you mean our design looks cheap that's one thing, but I don't know how by just looking at the site it gives you a feeling of shoddy work.

I never said anything like that. I have no idea of the quality of your work, and have no reason to assume that it's not wonderful. My simple point is that when providing an API to other apps, the other apps become dependent on you. Your decisions affect them. If you're running an end-user website and decide to take it away sometime, that sucks for the community but it doesn't really invalidate anyone else's work. If you take away an API that others are accessing with apps that they spent considerable effort to create, then you're harming them.

Originally Posted by GGCO

As far as sustainability goes, we're going to implement ads soon to help recoup our costs.

You've been pitching this as primarily an API service. How are you going to run ads on an API service? Or, from a different perspective: you keep pointing out how anyone could duplicate your website using your API. If you put ads on your website, wouldn't someone else just duplicate the site without the ads, causing people to use that instead (since people obviously prefer sites without ads)? Or worse, they put their own ads on it and pocket the profits while you're footing the bill for the grunt work of collecting the data.

I'm not trying to offend anyone, I'm simply trying to point out some of the real-world issues that crop up after the enjoyment of creating it wears off (which it will, I promise). Things that start out as a fun side project can turn into an annoyance faster than you'd think. Pretty soon you'll find that instead of getting praise for an awesome tool, you'll just get complaints about "why doesn't it have feature x" and "when are you going to support y" or "it's down, how soon is it going to be back up?". Instead of being grateful, there's a lot of people out there who just expect you to provide more and more things for them, for free.