• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: WOBuilder Replacement
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: WOBuilder Replacement


  • Subject: Re: WOBuilder Replacement
  • From: Mike Schrag <email@hidden>
  • Date: Thu, 5 Jul 2007 21:45:46 -0400

Lastly, everybody is free to do what they want and I certainly agree the we do not have any right to expect others to do work freely for any of us. However I do not understand why there has to be a business case for developing a WOBuilder replacement ? that it must be absolutely profitable ? I'm curious to see the numbers that supported the development of WOLips, Project Wonder ??? Should I assume that these were profitable endeavors ! To me, they certainly seem equally large/serious development efforts, probably even more than a WOBuilder replacement.
All I can speak for is my own company, but the reason there needs to be a business case for WOBuilder for us is that there is a substantial up-front development investment that has to happen to have anything worth using. By substantial, I'm talking many man-months.

You bring up current-state WOLips and Wonder in contrast, so I feel that some context needs to be provided here. In the case of Wonder, I would say that 95+% of the code that I have contributed to Wonder was code that I had to write to solve a problem and we chose to contribute it back because we felt the community would benefit more (and by proxy, us) than we would if we kept it locked away. For Wonder, the answer is "it was already paid for". The business case was generally made already because we either already decided that we needed an internal app that required the feature, or we had a paying customer that literally paid for it to happen. So that's Wonder.

For WOLips, it's all tools, so it's harder to quantify. For almost all of the things I've worked on in WOLips, I felt that sinking the time into working on the feature either 1) made us more productive (i.e. automatically calling eogenerator -- relatively small feature, but a nice little bump), 2) made us less error prone (i.e. binding validation, code completion, etc), or 3) made me not want to kill people (i.e. replacing the previous HTML editor with a WO-smart one, which also ties into #1 and #2). We have invested a very large number of man-hours into WOLips development, don't get me wrong, but it's generally spread out over a year in little chunks. I didn't have to dedicate 4 months to get the new HTML editor out. Now it was maybe a week or two, but I dedicate a large amount of personal time in addition to work time on a lot of that stuff just because I enjoy it. So I tacitly make the business case for the majority of our WOLips contributions that I believe our development will be stronger because of it. Entity Modeler is an ENTIRELY different beast. I got a phone call from someone who worked with Apple and was asked "how serious were you when you mentioned on the mailing list that you were thinking about an Eclipse-based Entity Modeler, because that might be a really good idea." Entity Modeler was the single largest time investment that I've made to WO open source, and if we took that on entirely inside the company, I would have absolutely have had to make a business case for it. And it's entirely possible that Bill would have said "absolutely", but at the time, it was sort of exploratory, and I wasn't sure things would come of it, but I spent 5 weeks of completely off-hours personal time to try to get that out before WWDC 06, because I felt it was important to WO to have it. I'm not pointing that out because I want any sort of "yay thanks", but rather that I took that on independently, which gave me the freedom to not have to make a 5 man-week business case for it. Now we have since dedicated quite a few (many many) hours to it under the company, because we believe (and Apple agreed) that Entity Modeler provided a direction for the tools story to go for WO, at which point it became its own business case (we use WO, we don't want to use the alternatives, so we need to support this tool).

And then we come to WOBuilder again. It's the big missing chunk of the toolchain. But WOB is really hard, or at least doing WOB WELL is really hard. It's not just "stick a webkit front-end on a text editor and ta-da!". You have to write Interface Builder. And not only do you have to write interface builder, you have to write interface builder that works well with essentially entirely custom NSViews (meaning, go make a UI in IB that uses nothing but custom NSViews -- nice gray boxes, right?). Just making a good previewing HTML editor is hard, let alone throwing in arbitrarily-nested- dynamically-changing-based-on-content-and-data-that-doesn't-exist-yet- because-you-haven't-put-data-in-your-database components. And if we worked on it, I'm not content just rehashing what the original WOB is, because I don't _like_ the original WOB. I believe (and this has been debated to death, so I'm simply stating it as my personal opinion and NOT as a fact) that WOB falls down for complex components that make proper use of modern web design (lots of divs, laid out with CSS). I want to build tools that _I_ would use in addition to building tools that beginners can use. And I truly believe that's possible. It's really hard, but it's a fundamentally solvable problem. But this is not the kind of app you spend 5 weeks working on after hours. It's the kind of app you have a couple people work on for several months. And everyone knows IB, and most of you are spoiled by Mac apps. Anything LESS than the bar Apple has set with existing WOB and IB is going to be seen as pretty lame, and it should given that Apple has given a decent roadmap for at least PART of the thing. And then stack on top of that that you _ideally_ need to support Windows AND Mac developers (though given the choice, I would choose to make it a Leopard-only Cocoa bad-ass thing), and it has to integrate into Eclipse, but lots of people don't USE Eclipse, so you really need to make a generic interface that multiple IDE's can hook into, etc etc etc ... It's a big app. It's looks really simple when you just casually use WOB, but it's WAY harder than Entity Modeler was, and cumulative time (I'd have to look in our tasking system to get a real number) but it was EASILY two man-months up to now.

And that sort of effort, for use, requires justification. Because while we love working on WO, we also like to stay in business, and we do that by either 1) making our apps easier to build (i.e. current WOLips and Wonder) or by 2) straight-up putting in the hours to build actual apps that make us money directly. And for me, WOB is neither one at the moment. If WOB because the app that directly makes us money (i.e. selling a WOB), that's awesome, and what we would build would become the next thing that makes our apps easier to build, but it has to make sense for us and I don't believe WOB makes sense as #1 without #2.

That's my story and I'm stickin' to it.

ms



_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


References: 
 >Re: WOBuilder Replacement (From: Ricardo Strausz <email@hidden>)
 >Re: WOBuilder Replacement (From: Galen Rhodes <email@hidden>)
 >Re: WOBuilder Replacement (From: Chuck Hill <email@hidden>)
 >Re: WOBuilder Replacement (From: Louis Demers <email@hidden>)

  • Prev by Date: Re: WO used internally by Apple, a bad thing?
  • Next by Date: Re: WOBuilder Replacement
  • Previous by thread: Re: WOBuilder Replacement
  • Next by thread: Re: WOBuilder Replacement
  • Index(es):
    • Date
    • Thread