I don't think it's possible. An open source project is two things: the community and the product. Without a product you've got vaporware, and without a community you've got two guys sitting around smoking pot in their garage.
Implementations are worth a lot more than ideas, and until you have an implementation you don't have a project. Saying "I'm going to build a robot dinosaur that breathes fire" is not nearly as useful as having a robotic dinosaur that breathes fire. And until you've got the dinosaur, you're just selling dinosaur futures. There are certainly things you can do before writing code: design, use case modeling, looking for a market, etc. But you don't have a project until you have an implementation, and you don't have an implementation until you have code. And without an implementation you won't get users, and without users you won't get more developers. -Jeff On Wed, Nov 19, 2008 at 3:12 PM, Robert Eickmann <[EMAIL PROTECTED]> wrote: > > I have been stewing on this question for a few days. > > I don't believe that it is fundementally possible to design a large > system or project with out knowing how to code. > > As you remove the abstractions and the hand waving and go deeper into > the system, you need to understand the rules, why things work the way > that they do. > > For example I have spent some fun days with 'business analysts' who > spend their days writing out detailed specifications for out of > country outsourced projects. Their lack of knowing the details of how > to write code, and their rudimentary knowledge of the business process > they were implementing made the actual code that came back > 'interesting'. Thankfully for the analysts the top 3 consulting firm > they worked for made a habit of shuffling them off to new consulting > gigs before the results came back from India. > > Larger projects, which to me is anything bigger than say twenty pages > of single spaced printed code often have interesting abstractions and > digressions in them. There are parts of the code that exist to resolve > bugs, or because the programmer didn't know about a simpler way of > solving the problem, or the base system doesn't do this that or the > other thing. These chunks of code are like knots in a piece of wood, > they can make the final product more distinctive or wind up fouling > the tool your using. As a result every piece is distinctive. > Think of how many open source text editing programs exist, each with > different features and bugs and viewpoints of what is important. > > With the Six Hour Startup Projects, we have little projects, in > relatively known universes. For the most part we are building, web > applications using fairly well defined inputs and outputs. The > majority of the projects count as a 'features' rather than a products. > That said one of our big challenges is getting everyone viewing the > world with the same vision. On our successful projects its the unity > of vision (everyone being on the same page) that makes it successful. > > One final note, you might consider reading up on Eric Raymounds > (google ESR) writings, he has done a lot of thinking and research on > what makes an open source project successful and what doesn't. > Everyone will find something to argue with in his body of work, but > worth reading and thinking about. > > -Rob Eickmann > > > On Tue, Nov 18, 2008 at 12:58 AM, Kyle Mulka <[EMAIL PROTECTED]> wrote: > > > > Interesting question Nick! > > > > Well... first of all, I don't think an open source project is really > > started until it has some source code. So, whoever writes the first > > line of code I think would be deemed the person who "started" it. Of > > course, then there's the person with the initial vision, the person > > who leads the project in the beginning, the person who funds > > development of the project. These all could be the same person as is > > the case I think with most open source projects. On the other extreme, > > each of these roles could be fulfilled by multiple people. > > > > I think the key thing you have to do to lead the initial development > > of an open source project is provide motivation. That's it. All you > > have to do to get a project started is to provide motivation. You have > > to influence others to write the code for you. The specific type of > > motivation could take many forms. You could get the person to believe > > that they are doing work for free for a worthy cause. You could get > > the person to believe this is a really good way to hone their skills. > > You could tell them that they will get exposure by doing this work. > > You could get them to believe that this is the most fun and exciting > > thing to do... that its not actually work, its entertainment. You > > could just outright pay them for their work which is how freelancing > > and contract jobs operate. You could offer them sexual favors. You > > could do a combination of these things. > > > > I would argue that some Six Hour Startup projects are started by > > people who don't write a line of code. A person has an idea, someone > > decides that's the idea everyone is going to work on for 6 hours. > > Preferably, as I've heard from Rob, and agree with, the person who has > > the idea should be the one who leads the group and communicates the > > vision to them. The motivation for doing Six Hour Startup might be > > different for different people. For me, its a way to meet new people, > > and hang out with cool people I already know. It's a way to learn new > > things. It's fun to get some piece of software working in a short > > period of time. > > > > Those are just some of my thoughts. I'm sure I could think of more if > > I gave it more time. But, now on to other people's thoughts! > > > > -- > > Kyle Mulka > > http://www.kylemulka.com > > http://www.scrapwalls.com > > > > On Mon, Nov 17, 2008 at 6:34 PM, Nick Molnar <[EMAIL PROTECTED]> > wrote: > >> > >> I'm wondering if it is possible. > >> > >> I was going to ask this question to the group at SH, but couldn't make > >> it out. What would be the limitations? What role would one have to > >> play to meaningfully contribute in the early development phases? What > >> properties would the idea have to hold? > >> > >> I have some ideas on how it could work, and how it could fail, but I'd > >> love to hear from you guys. > >> > >> > > >> > > > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ Website: http://saturdayhouse.org/ Post: [email protected] Unsubscribe: [EMAIL PROTECTED] -~----------~----~----~----~------~----~------~--~---
