Shared publicly  - 
 
Open Design Engine is going to be like sourceforge for oshw, except cooler and with other cool stuff, so if you have extra pennies, you should help fund it! :)
http://www.kickstarter.com/projects/373493158/open-hardware-needs-a-sourceforge-of-its-own
ODE is a web-based engineering project management system to facilitate the design and development of open source hardware projects.
11
4
Priya Kuber's profile photoMarkus Klink's profile photoVikraman Choudhury's profile photoDave Carlson's profile photo
46 comments
 
Could be good, if they build hardware diff tools.
 
+Frank Buss: Indeed. SourceForge itself, and Google Code, can both do all of that already.

Although, I don't know how well SF can handle projects with multiple, and non-software-oriented, licenses.
 
My hardware projects mainly consist of Eagle files, VHDL, uC firmware and host-side code. I publish on http://github.com/makestuff, and I have no complaints with it. I publish everything under GPLv3 because I (perhaps naively, from a legal standpoint) consider Eagle files to be source code. But there's nothing stopping me using different licenses for different components if I wanted to.
 
+Frank Buss the difference between ODE and google code/sourceforge is that it will be designed specifically for hardware projects. Meaning, to put a project on there, you will have to choose an OSHW license.

One of the cool things that differs a lot from OSHW to OSS is that the process has to be much more documented. For instance... if you just put up all of your source files, sure that's cool, but you still may not be able to replicate the end design if you don't know what steps to follow for it being made. ODE is focussing on that.

+Windell Oskay exactly. Some of the licenses require that you post what has changed from one version to the next. Not sure if they are developing specific diff tools, but this may be easier to wait for when a universal XML format is reached.

+Chris McClelland Cool! Though, I'm not too sure if you would want to protect/unprotect the source of the file rather than the contents of the file? Or does one imply the other? In which case, maybe something else would be better? I have no idea, I'm totally a noob at all of this still, but it seems like this could be a cool discussion for the OHS mailing list: http://www.openhardwaresummit.org/mailing-list/
 
+Erin RobotGrrl I gotta admit I don't care too much about the license on my PCB designs because they tend to be pretty simple. I tend to spend about 1% of my time designing PCBs and the other 99% on FPGA stuff and software/firmware.

There's an interesting (albeit twelve years old now!) article[1] by RMS on this, in which he makes what I think is a valid point:

"Whether or not a hardware device's internal design is free, it is absolutely vital for its interface specifications to be free. We can't write free software to run the hardware without knowing how to operate it."

[1] http://www.linuxtoday.com/news_story.php3?ltsn=1999-06-22-005-05-NW-LF
 
If it is just the license, a new service doesn't make sense. With Sourceforge you can specify "Other/Proprietary License" when creating a project and write about your license on the project page and I'm sure Sourceforge would even add OSHW licenses, because they already have lots of OSI approved licenses to choose from. Maybe nobody ask so far. Same for Google Code: there are not so much licenses in the list when creating a new project, but the same solution: you can select "Other Open Source" and write about the license in the project description.
 
Interesting idea. The concern I would have is getting critical buy-in for it to go anywhere. That and the fact that they are building it on rails makes me hesitant to kick in funds.

I wonder about the folks involved too. They are going to pay LittleLines to do the development, and who is Mach 30 anyway? I am more comfortable with covering developers cost so they can take the time to write something themselves instead of donating cash to one party so they can pay another party to do the work.
 
+Frank Buss "one of the primary goals of ODE is to provide an easy to use public platform to use from day one so projects will naturally be encouraged to share their entire process and history" <-- from the guy who is making this (J Simmons), on the OHS mailing list

When I talked to him at OHS, he had some cool project forking tools/ideas that would serve better than those of sourceforge or google code. For example, a spaceship has numerous components to it- the electrical, mechanical, models, code, etc. From what I can understand, ODE will allow you to sort of have sub-teams so that they can all work on one aspect of the main project. They explain it better on their site: https://opendesignengine.net/

+Chris Kraft I kind of agree. Once v0.2 is done, then what? Do we need to fund v0.3 also? Here's the development roadmap, it goes out to v0.4 now: https://opendesignengine.net/projects/ode/roadmap

This is what they say on their blog regarding the cost:
"we are rocket scientists, not web developers, so we have had to hire a development shop to help us implement these features. Luckily, we found a great shop here in Dayton, Littlelines, and they have given us a discount since we are a 501(c)3. But they still have to eat, so we still have to pay them." http://mach30.org/2011/09/23/an-urgent-need-in-open-source-hardware/

They probably choose ROR since that's what Redmine (what ODE is built on) uses. (And if anyone is wondering: I can't contribute because Ruby is my worst language, no benefit would arise from this :( )

One thing to not forget though, is that they're gonna distribute ODE like Wordpress- so you can have a version running on your own server, which will be really useful.
 
Hi Windell. I really don't see the need for a new service. As described earlier in this comments by me, the license is no problem with existing systems like SourceForge or Google Code. And a destination for users looking for open source hardware projects could be just a Wiki, linking to your favorite project management system. Multiple sub-projects can be managed easily e.g. with multiple gmane.org mailing list, different categories for the bug tracker, sub-folders in the version management system and sub-overview-pages on a Wiki. You should not reinvent the wheel, but concentrate on the OSHW projects itself. Building a new project management system is a lot of work.
 
But for me it sounds like you want to, because all the services your Open Design Engine project managment system provides, are already available with SourceForge. Maybe I didn't understand it and you could write something about what's wrong with my previous arguments.
 
+Frank Buss WTF? I didn't say anything was wrong your previous arguments. I've never used (or even really looked at) sourceforge, but I have used launchpad, google code, and I've just moved my first projects onto github. If they build a new service that has hardware-specific features (and there are quite a few that could be added) then I'd be interested.
 
No offense intended here, but you're looking to make a new service, and you haven't even really LOOKED at something in that space already?

Admittedly, SourceForge could use more functionality, but this is one problem in the open source world that I've seen - rather than try to work with existing projects, fork or make a new one, which causes excessive project proliferation. Sometimes, forking or making a new project is the right answer, but many times it isn't, especially when there's network effects in play (which, IMO, is somewhat true here.)
 
I didn't wrote that you said my arguments are wrong. My assumption was that I didn't understand your project idea in all details, so this would be a reason why my arguments could be wrong. But I still don't see any hardware-specific feature which is not supported by SourceForge.
 
+Erin RobotGrrl Thanks for sharing our KickStarter and for keeping the conversation going.

+Frank Buss - +Windell Oskay commented over on one of my posts about the KickStarter and I just posted a somewhat long reply. The short version is while yes one can host hardware projects on the software hosting portals (sf.net, launchpad, github, googlecode, etc), once projects scale to a certain point it becomes something of a hack. ODE is meant to address that somewhat hacky nature and to be a place where other hardware specific needs will be addressed.

+Chris Kraft Mach 30 is a non-profit (501c3 public charity here in the US) dedicated to developing open source spaceflight hardware. We are a 100% volunteer organization run by a board of directors with experience in non-profit management and aerospace engineering. Believe me, I wish we had the internal resources to develop ODE ourselves, but as +Greg Moran and I were saying at the Open Hardware Summit, we're rocket scientists, not web developers. Our choice of rails was actually about leveraging a great existing platform (Redmine) instead of reinventing the wheel.
 
+Eric Rucker No offense intended here, but who gave you the idea that I was looking to make a new service?

+Frank Buss There are plenty of potential hardware-specific features that are not supported by SourceForge (or any software-focused, i.e., existing) project management system. Off the cuff, here are three:

First, BOM management, with a database of parts that can be shared between projects, with the capacity to assign an arbitrary amount of company-specific and project-specific data (e.g., internal part number used for this PEM nut, and what it's used for in kit A and in kit C). If the software is one database used by multiple companies, then it would be helpful to be able to segment this data. If the software were used internally by one company, then perhaps an inventory management system could be integrated (internally or externally).

Second, manufacturing. It would be wonderful to integrate capacity to send design files and hardware BOMs to different shops for purchase and/or manufacturing quotations-- maybe partner with Shapeways for 3D files, Ponoko for laser cutting, emachineshop for CNC metal cutting, Sunstone for PCBs, Digi-key and Mouser for electronic components, McMaster-Carr for fasteners, and so on.

Third, creating and storing visually-useful build data and diffs. For each schematic, layout, or CAD drawing checked in, it could create a rendered PDF, possibly including 3D models. For subsequent circuit board revisions, you could view the gerber stackup and view diffs, highlighted by color.
 
+J. Simmons I've read your response in your account and binary files are no problem for version systems like SVN. It is independent of the CAD systems you are using. Diffs are not possible, but it is still useful to restore old versions or to tag all files of a project with a release tag, creating development branches etc. I would not recommend to use non-versioned files, even the Wiki or a webpage can be versioned.

Regarding writing your own forge: You could download the SourceForge system ( https://sourceforge.net/p/allura/wiki/Allura%20Wiki/ ) and use this as a base for your own system, instead trying to write a new system with Ruby on Rails from scratch. Maybe the multiple project teams requirement would be really a good idea for bigger projects and needs some more features than SF currently has, to make it easier to use with a non-integrated solution like I proposed.

+Windell Oskay The BOM management sounds like a good idea. Of course, lots of work to implement such a feature (e.g. PADS installations with ERP integration costs 6 digit prices to setup), but sharing libraries etc. with different projects would really help to create new hardware projects. Maybe instead of the big solution with a central database, a small step in this direction would be multiple projects with different libraries (e.g. for Eagle electronics parts) for some areas, like one library for connectors, one for microcontrollers etc. With Eagle, and with other open source EDA tools, you can attribute the parts to generate automaticly a BOM with part numbers for distributors where you can buy it.

Visual diff needs not to be part of the project management system. Same e.g. with gEDA, which is its own project and not part of the ODE system. Better work on the gEDA project (or other open source EDA systems) to implement such a feature, if not already implemented (I'm using Eagle, so I don't know).
 
+Frank Buss Diffs are already possible for CAD/EDA formats that use ascii file formats (quite a few, actually).

Also, visual diffs are already nearly trivial with gEDA-- for example, PCB has command-line options to output a PNG, and then imagemagick can merge files. So, no work to do there. The value in doing this is to make it automatic, part of the process for project management.
 
+Frank Buss I am quite familiar with storing binary files in SVN, and I have never really been happy with how it works. I also find that users who are not familiar with source code control systems (such as the majority of my engineering friends) have a hard time getting comfortable with tools like SVN. I imagine this is because these tools are built around a workflow that assumes you can diff and merge the contents of the files, which is just not the case for work done entirely in binary files.

Regarding the source code to Source Forge vs starting over, we are actually taking a third option. We basing ODE on the rails project Redmine - http://www.redmine.org/. Feature wise, we felt Redmine was a better foundation for what we are aiming to do than what was available at the time (more basic features working out of the box, plus a very nice plugin architecture so we can develop and share our features with the larger Redmine community). I have taken a look at Allura (the new code base for Source Forge - which came out after we started designing ODE), and I think there is some interesting stuff here, it seemed to be something of a moving target which makes it hard to use it as a foundation for a new site. It will be interesting to see how Allura comes along though.
 
+J. Simmons How is the merging of files going to work in ODE? Will it be a manual process, or more automatic like +Windell Oskay was describing?

And as for the BOM- will it be based off of the main software tool for each sub-team, or one large BOM for the whole project, or a universal XML BOM for the subteams or... what? :)

Also, will each rev of the development have to be funded, or is this only for v0.2?

ODE is going to be something that will help out FIRST teams a lot. Right now, file management is usually through dropbox or usb stick, and github or the like for code. :p
 
I appreciate the answers +J. Simmons I personally won't kick in any funds because in my experience as a software dev I've found that out-sourcing development leads to future problems when it comes time to upgrade or fix issues. You suddenly are tied to depending on another company for future releases.
 
Hmm, I just found this cool website: http://www.ohwr.org/

+J. Simmons It has a lot of overlap with ODE. Wondering, why start from the beginning and not use OHR as a base?

They seem to have a lot of activity:
http://www.ohwr.org/news
http://www.ohwr.org/projects/ohr-support/news

And their general purpose is pretty much the same:
http://www.ohwr.org/projects/ohr-support/wiki/Manifesto

You probably looked at this before, so I'm just curious as to the reason behind starting completely new :)
 
+Chris Kraft Thank you for your candor. Hopefully we can avoid that problem, but it is a good point to keep in mind.

+Erin RobotGrrl So many questions... ;) Let me see if I can answer them all.

Merging files: ODE has two means of managing files, source code repositories and a document management system. Merging files in the source code repositories is just a matter of using the built in merging tools of the repository (we currently support SVN, and v0.2 will add git). Files stored in the document management system will require manually merging of changes, but this is really intended to be used with binary files or files that are not expected to change (such as raw data collected from sensors) so this is really not an increased burden because of the nature of those files. I have to say, the idea of having visual diffs for graphical formats is something that could be a big help, so added it as a feature request.

How will BOMs work?: Honestly we have not started designing the BOM feature as we are focused on the next release. However, these are all good questions that I think should be considered. I am going to copy these and ideas from +Windell Oskay into the comments on the appropriate features over at ODE.

Using ODE with FIRST teams: Wow, what a great idea!!!! I had not even thought of that, but I would love to see that happen.

OHWR: Yeah, that is actually kind of an interesting story. As near as I can tell, CERN and Mach 30 (with input from CSTART another open source spaceflight org) independently conceived and developed the OHWR and ODE. The crazy thing is both groups chose Redmine as the foundation. I have been in contact with the folks at CERN who are running the OHWR, and we are interested in finding ways to work together. In the meantime, I think we are going down slightly different roads (I believe CERN is primarily running OHWR for their own projects but are willing to give people accounts if requested while Mach 30 is developing ODE with the primary purpose of opening it up to anyone who wants to host open source hardware projects - this is kind of a subtle difference, but important for the community in the long run).

Funding ODE: Great question, and one I am not entirely sure of the answer. My hope is to have a blended approach in the long run, where community members help develop some features (one of the great things about Redmine is it has a rich plugin architecture, so many new features can be developed outside the core code and then included when they reach maturity), and we raise funds to develop others (though not necessarily all through KickStarter). It is important to realize Mach 30 is a non-profit so many of our programs are funded through donations/fund raising. As we start to build out ODE, hopefully we can find a way to bring in some earned income to pay for the hosting and feature development when required.

One more thing. I am going to be away from Google+ for a bit while I prepare for a conference I am presenting at this week. I will do my best to get back this evening and answer any new questions that come up.
 
+J. Simmons Cool! Thanks for answering all of the questions! :) Would definitely try to get the funding plans more concrete in the near future, as it is kind of "scary" to fund something where you don't know how the next version revs are going to be developed eh!
 
Having used both SVN and GIT I would have to say that binary file support sucks especially for large files so you definitely need some additional document management system.

Differencing and merging versions of files: you can do this for any arbitrary format, binary or text, you just need to specify an external tool that is capable. I'm not sure how this would work server-side, but client-side it is just a matter of registering the tool with the source control system. Of course writing these tools, especially for merging, is non-trivial, but would be self-contained and plug-in friendly.
 
I'm finally back online, but bouncing back and forth at AIAA Space 2011, so my replies will still be sparse.

+Erin RobotGrrl Good point re: funding. I can tell you that while we are still developing some of the details about the long term picture, ODE's roll as a key project at Mach 30 means we will continue to fund it through our annual budgetary process for as long as it is of value to the OSHW community (which we hope will be a very long time).

+Shaun Houlihan Thanks for the nod. I look forward to talking with you about your plans for Open Edison and how we can work together to meet this need.

+Rupert Rawnsley Couldn't agree more re: binary files + version control systems. Good point re: the challenge of diff'ing/merging should be self contained along file types. I would recommend starting with the diff'ing problem, and working towards merging when it is really needed.
 
Looks like OHWR is open to anyone, but the registration is not automatic, you have to contact Javier Serrano for the project setup by eMail. But he is very polite and you can select either GIT or SVN as a repository. Wiki and a mailing list are also included in the free project service, and all the other stuff, like feature requests, bug tracking etc. Now there is a project for my Universal C64 Cartridge, with initial Eagle and CPLD files in the SVN repository (read access open to all), and a Wiki: http://www.ohwr.org/projects/c64cartridge/wiki I've choosed the CERN OHL license for the project, because it is less restrictive than the TAPR license.
+J. Simmons , but good luck for your project, a bit competition might be useful for all project management systems.
 
+Frank Buss Thanks. I agree, a little competition (especially in these early days) is good for both sites and the community as a whole. I am actually working on setting up a call with Javier, and I would whole heartily agree he is polite and helpful. I am hopeful we can work out a good way for both organizations and sites to contribute to open source hardware.
 
Woah! OHWR got a total makeover! It looks awesome! :D :D :D

+Frank Buss Your project is cool. How is the backend interface for managing all the files? Is there one? How long did the setup by email process take? Do they only take serious projects? What do you wish there was, but isn't there? xD

+J. Simmons Where does the long term picture of ODE stand now? Are you thinking more of collaborating with OHWR? What roadblocks would there be? Has there been any progress since? :)

It would be fun just to make a silly shield to test out these various systems. (Creating hardware to test out more software... nice.)

And here is another one too, it looks like it takes more of an instructions based approach. http://www.openhardwarehub.com/
I wonder what backend they use? That parts list module/plugin/whatever looks pretty sweet.
 
+Erin RobotGrrl Thanks for checking back in. I should have posted something yesterday. Oh, well.

I had a very nice conversation with Javier @ OHWR the other day. And at this point I would say our two projects are a more different than they appear, and are quite complimentary. From my understanding, CERN originally launched OHWR to host their projects and are now letting some folks from outside host whereas ODE has always been intended to be a public hosting site. So, both organizations will continue to pursue their own sites for the time being. And Javier and I plan to keep in touch as the two sites grow. And of course, should things change and CERN were to decide to openly host projects, Mach 30 would be interested in developing a more formal relationship.

So, that leaves the long term picture for ODE basically the same as before. Raise the necessary funds at the KickStarter to support a public launch, and continue to work with the community to see that open source hardware gets free project hosting catered to the OSHW community's needs.

And, I love the idea of developing the same project at all of these sites to compare them. If you or someone else wanted to seriously do this, I would be more than happy to provide an evaluation account for the process.
 
+Erin RobotGrrl Thanks, the PCBs arrived and I have soldered the board: http://www.frank-buss.de/tmp/cartridge2.jpg The microcontroller can be programmed by USB and the CPLD by JTAG, no board shorts or other problems so far.

OHW uses Redmine as their system. You can choose SVN or GIT for your version management system. For the Wiki you can just upload images for the page you are editing. The setup process by eMail took a few days, I guess Javier was busy. I think they'll take all projects, if you demonstrate at least that you want to develop some useful open hardware, I wouldn't call my C64 project "serious" :-) Maybe try your shield, if you have a good idea. So far I don't miss a feature, but I'm a programmer and all I need is SVN anyway, but this might change, if more people are working on the project, but the mailing list, bug tracking etc. they provide should be sufficient.
 
I love to see that this discussion is happening. I'm a developer at GitHub and we have been talking a lot lately about enabling and better supporting hardware and embedded electronics development. I too would echo some of the sentiments about 'Why re-invent the wheel and create yet another project hosting site?'. I understand that developing hardware is very different than developing a web application, but I'd argue that it would be better to start with something like GitHub and add in hardware specific features as the community needs them. We already have a huge community (including many hardware projects). We already have a great site for hosting code, downloads, issues, wikis, etc. We even do things like image diffs (https://github.com/blog/817-behold-image-view-modes) and have been exploring rendering diffs for other formats as well. What else would you all want to see on GitHub to better support these kinds of projects?

Here are just a few ideas:

- Better support for parts database and BOM. How are these being managed now? What is the ideal? Is there a single database you can query right now? Is there a common format for a BOM?
- Better rendering of hardware specific file formats. Can someone send me a list? Can pngs be generated for many of these? If we had a way to create renders and publish them to a github repo like our service-hooks would that be interesting to people?

Also, are people familiar with Upverter? http://upverter.com/
 
+Timothy Clem I'm the president of Mach 30, the organization developing Open Design Engine (https://opendesignengine.net, http://www.kickstarter.com/projects/373493158/open-hardware-needs-a-sourceforge-of-its-own). It's exciting to hear that GitHub is discussing how they can support open source hardware projects. I have actually had several discussions about the "reinventing the wheel" question and I have tried to summarize them in the FAQ at our KickStarter.

There is one point I think I can expand a little (though I would take a look at the FAQ on the KickStarter for the full picture), and that is the need for two file storage systems (one for code and one for engineering documents). When you all are discussing supporting open source hardware, are you mostly discussing electronics projects? I have noticed a strong bias in the early adopters of open source hardware toward electronics. I imagine this has something to do with the overlap between the software and electronics communities. But, I think we are already seeing a shift toward broader projects (like Open Ecology's various projects including a steam engine and a tractor). This is going to pull in new users who are not familiar with version control systems like Git and whose tools use binary formats. And while I understand one can store binary files in Git (or other version control systems), I do not think it is the best fit. You loose the powerful diff and merge features and the workflow is not in line with the workflows mechanical engineers and their like are used to using. This led us to very early on decide we needed separate file storage for code vs engineering documents.

In terms of features, we have a list of desired features over at Open Design Engine (https://opendesignengine.net/projects/ode/issues) that is taken from the work we did with CSTART to develop requirements for Open Design Engine (http://cstart.org/wiki/ODE#Potential_features). The CSTART wiki is probably easier to digest since it is in narrative form.

Oh, and yes, I've heard of UpVerter (I actually spoke to one of their co-founders on the phone a couple of weeks ago). They are doing very interesting stuff. I would at this point call it more of an online EDA tool than a project tool, but that is still a great thing to have out there in the world.
 
Thanks for the links +J. Simmons, I had not seen the FAQ yet. I definitely see that the kind of large scale hardware projects you are talking about have some very specific needs. I would still welcome your feedback on how GitHub can be more hardware friendly (both embedded electronics and true hardware). I will keep tracking the ODE effort here - looks like you guys are off to a great start!
 
+Timothy Clem - Thanks for the reply. You know what would be awesome is to find ways for GitHub and ODE to work together. Clearly you guys have the experience running large scale user oriented sites, and I think we at ODE can help bring a the needs of hardware projects into focus.

+Shaun Houlihan - As always, thanks for the support.

I also wanted to share a comment from one of our backers that I thought was absolutely brilliant (see the comments page here - http://www.kickstarter.com/projects/373493158/open-hardware-needs-a-sourceforge-of-its-own/comments). Add an integrated web store so projects can easily sell kits and finished products of their open source hardware designs. How cool is that? Not only does it mesh directly with the current OSHW business model(s), but I think it would be reasonable for ODE to keep a small percentage of sales, which would be a great revenue stream for the site. What do people think?
 
+Timothy Clem Wow, thanks for posting here! I love Github! :)

With regards to how Github could better support various hardware design files... there are a lot of file formats, and it would be a huge task to try and be able to make visual differences of them (thinking of CAD files or binary files). Here's two ideas that I have that might help:

1. A place to write precise differences for each file
- Commit messages are great for short code changes, but in hardware if you need to change the number of teeth on a gear you will want to be able to document why that change happened.
- The Github navigation format would be great for this. Usually changes like described above would be documented in a blog. With Github, I could definitely see the potential of being able to navigate through the change descriptions easily, almost like when you navigate through a trunk, but this would be for change notes

2. Annotate photo diffs
- The photo diffs feature now is great, but it would be cool if there were an online tool in Github to be able to annotate the images, with drawing or text.
- It would allow the committer to clearly point out what changed, making the documentation even better

Maybe these are already created, and I don't know about them?

With regards to a BOM... there definitely needs to be a common format created. It would most likely be in XML, but we need to figure out how that will be formatted.

It will be hard to adapt the software oriented github towards more mechanical projects though, but there's bound to be some way that +J. Simmons can integrate Github into ODE, at least for the software parts. :)

+Shaun Houlihan mentions good points.

Hope that helps Timothy!
 
+J. Simmons About the web store (hardware app store) idea- LetsMakeRobots was also thinking along the same lines. They would create a simple portal for people to put their hardware products, and they would sell it. The problems they were discussing were about shipping locations (I think this was later resolved that shipping would be directly from the person), and of course how LMR can make some moneys from it. :) There were two main ideas: Membership fee or percentage grab.

Aside: It may be worth mentioning that I have no clue what I'm talking about, since I've never made hardware to sell before x] But if I did...

I personally like the membership fee more than the percentage grab, because it means I don't have to up the price even more on my hardware just to make a decent profit. It's better for the people that way, in my eyes. And for me as a maker, it is a commitment. I pay $40 to belong to a special program, therefore I'll be more inclined to be attached to it.

Maybe +Andrew Terranova could add more about this, but it is also kind of splitting the discussion from hardware project management to hardware app store discussion. ;]
 
+Erin RobotGrrl Just wanted to publicly capture what we discussed last night about the webstore concept for ODE. I think you bring up a valid point that there are multiple models ODE could use to create a revenue stream around the webstore concept. I mostly suggested the percentage because it is simple to explain and calculate, and it is now a pretty common model (thanks to PayPal, KickStarter, Pledgie, etc). That being said, I think the best course of action will be to discuss this with the community after we get the KickStarter funded so we can find the right balance for the users and site management.
 
Congrats +J. Simmons!!!! I knew it would get funded :D Sorry I didn't pitch in- went a little (a lot) over budget in NYC. :| Hopefully sharing it w/the social networks helped you :)
When does the development begin, and what are you going to do with the extra dollars? :)
 
+Erin RobotGrrl Thanks!!! We're very excited over at Mach 30. Erin, don't sweat the dollars, the social networking you did helped us out a lot. Thank you so much for helping spread the word.

The money is still processing over at KickStarter/Amazon, so it will still be a few days before we get all of the financial stuff squared away. After that, we will get in touch with the backers to get info for rewards (top of my list is to get account info from our backers so we can turn on ODE accounts). Then we'll get right to work on the next set of features.

As for the extra money, I'm very excited that we passed our goal, but in the grand scheme of things we did not raise significantly more than we were aiming for (it is something like 4% more than we requested), so the extra money will not translate into a giant additional feature. Most likely it will either be cushion in case one of the budgeted features runs a little over or it will roll into the next release development. Either way, we will be sure to put it to the best possible use in growing ODE.

Thanks again to everyone who backed us, asked questions, or made suggestions. We appreciate all of the support.
Add a comment...