Why stop so short

[Paul Kramer <kr...@me.com>]

Hey Folks,

You are doing something I think is great work in Buildr. But why stop so short. 

I'm my mind, all of the infrastructure should be developed with rapid development in mind. To me that equates to Python/Django and Ruby/Rails, and not only that. There is HUGE opportunity in the embedded space. Look at the rapid growth of the mobile market. The folks in this space are looking around and what do they see. Lots of Java based tools (cruise-control, hudson, teamcity, and on and on). That java stuff does not fit into that space at all.

So why stop short with Buildr. Buildr could easily be extended to provide its own continuous integration, done in ruby/rails of course.

Consider the following: http://qbal.mozdev.org/ circa 1999-2000 http://qbal.mozdev.org/oldQbal.jpeg This was a proof of concept based on earlier work I've done. It was 100% javascript. I'm going to ramp this stuff up again, but this time I want to use ruby/rails/javascript

Here is the thing. I've been doing this stuff for a long long time. You can take a moment to look at www.qbalsoftware.com to get an idea of my background. I'd like to start collaborating on some solutions that turn things upside down and produce some results that help teams fly!

Let me know if you are interested in talking further.

Regards -- Kramer

I live in Mt View (silicon valley) and this is my wing-man Cosmo.

Re: Why stop so short

[Alex Boisvert <al...@gmail.com>]

Hey Paul,

Sounds like Buildr sparked an impassioned reaction in you :)

I agree there's a whole lot of software around build, continuous
integration, configuration/lifecycle management that could suck less.  We're
not "stopping here" but Buildr's scope is relatively well defined at the
moment, although as an Apache TLP, we can certainly grow in any of the
different directions you mentioned.

I probably don't need to tell you this but what's needed, beyond vision, is
typically one (sometimes two) very motivated individual to lay the
foundation for that expansion in such a way that will incite other people to
join.  There needs to be a critical mass of software written up-front to
kick-start things.  No roadmap or vision can replace that.   And it's not a
sufficient condition to guarantee traction -- merely a necessary one.

The good news is there's a good likelihood you'll find interested people
and, perhaps, some who share your passion and ambitions in this community.
With some luck, they might even have a lot of free time too :)

I certainly encourage you to pursue this.  If something comes out of it and
the conditions are right, I believe Buildr would be a great community to
host the project(s).   Just be prepared for what sounds like a fairly
engaged and arduous journey.   Bootstrapping open-source projects can
require a lot of effort and dedication; even more so for projects not
directly tied to developer's itch.

cheers and welcome!
alex

On Thu, Jun 10, 2010 at 9:07 PM, Paul Kramer <kr...@me.com> wrote:

> Hey Folks,
>
> You are doing something I think is great work in Buildr. But why stop so
> short.
>
> I'm my mind, all of the infrastructure should be developed with rapid
> development in mind. To me that equates to Python/Django and Ruby/Rails, and
> not only that. There is HUGE opportunity in the embedded space. Look at the
> rapid growth of the mobile market. The folks in this space are looking
> around and what do they see. Lots of Java based tools (cruise-control,
> hudson, teamcity, and on and on). That java stuff does not fit into that
> space at all.
>
> So why stop short with Buildr. Buildr could easily be extended to provide
> its own continuous integration, done in ruby/rails of course.
>
> Consider the following: http://qbal.mozdev.org/ circa 1999-2000
> http://qbal.mozdev.org/oldQbal.jpeg This was a proof of concept based on
> earlier work I've done. It was 100% javascript. I'm going to ramp this stuff
> up again, but this time I want to use ruby/rails/javascript
>
> Here is the thing. I've been doing this stuff for a long long time. You can
> take a moment to look at www.qbalsoftware.com to get an idea of my
> background. I'd like to start collaborating on some solutions that turn
> things upside down and produce some results that help teams fly!
>
> Let me know if you are interested in talking further.
>
> Regards -- Kramer
>
> I live in Mt View (silicon valley) and this is my wing-man Cosmo.
>
>
>
>
>
>
>
>
>
>
>
>
>
>

Re: Why stop so short

[Paul Kramer <kr...@me.com>]

Antoine,

Yeah I can understand your need for resources around Buildr. I did not mean to suggest the team is falling short of my expectations. No just the opposite. 

Buildr is unique to me in that... it went completely against the grain of offering a non-java utility to build java code. What I'm saying is that, "I don't see Buildr as a new build solution".  I see Buildr as a group of people that went against status-quo and said there has got to be a better way!

What I'm suggesting is that folks consider a larger scope. A grander vision. There are HUGE opportunities to turn things upside-down. The mobile industry is providing that vehicle!!!! The Buildr team can do much more! Why do I say this. Because I've been fixing build systems for years, and I've always said, build systems are easy, its the source tree thats hard. If the product has not been designed and implemented with distinct layers and modules, then the build system will be complex ... and so too every other aspect of testing and productizing. The #1 problem software team have is managing change. What I'm suggesting is that perhaps you and the team after this release, consider going after the big kahuna!

Your team has started something! But there are MUCH bigger fish to fry! 

There is huge confusion in the mobile market. Its like the 1980's but 10 times more complicated. In the 80's we had everyone and his uncle making hardware and software and there was lots of confusion because of all the competing platforms. The mobile market is just the same but much much bigger.

It will not be long before most computing other than servers will be mobile. And if we look at the technologies used as part of the product life cycle to deliver these modern systems, they are rooted in the 1980's and 1990's. Nothing new... Consider GIT and the other distributed source code control tools... 1980's man.... HP-UX had distributed branches using KCS and internal tools built on top of RCS (although people still shared the branch... the mechanics were there). Sun had smerge in late 80's to merge SCCS trunks, and then smoosh which became nse-lite, which became code-manager, which led to bitkeeper, which led to GIT.

NONE of the tools that are in vogue today satisfy the needs of software development teams today or tomorrow.

Thats what I meant by "stop so short". I think your team can take Buildr as a starting point and build outwards. 

Regards -- Kramer


On Jun 10, 2010, at 9:28 PM, Antoine Toulme wrote:

> Hi Paul,
> 
> thanks for the kind words, and hello to Cosmo :)
> 
> We have been preparing this release for quite a while with our meager
> resources.
> 
> We're sorry to fall short your expectations. If you can devote some time to
> our project, we would be ravished if you could open bugs for the items you
> mention and discuss there. We'd be happy to accept your patches.
> 
> Thanks,
> 
> Antoine
> 
> On Thu, Jun 10, 2010 at 21:07, Paul Kramer <kr...@me.com> wrote:
> 
>> Hey Folks,
>> 
>> You are doing something I think is great work in Buildr. But why stop so
>> short.
>> 
>> I'm my mind, all of the infrastructure should be developed with rapid
>> development in mind. To me that equates to Python/Django and Ruby/Rails, and
>> not only that. There is HUGE opportunity in the embedded space. Look at the
>> rapid growth of the mobile market. The folks in this space are looking
>> around and what do they see. Lots of Java based tools (cruise-control,
>> hudson, teamcity, and on and on). That java stuff does not fit into that
>> space at all.
>> 
>> So why stop short with Buildr. Buildr could easily be extended to provide
>> its own continuous integration, done in ruby/rails of course.
>> 
>> Consider the following: http://qbal.mozdev.org/ circa 1999-2000
>> http://qbal.mozdev.org/oldQbal.jpeg This was a proof of concept based on
>> earlier work I've done. It was 100% javascript. I'm going to ramp this stuff
>> up again, but this time I want to use ruby/rails/javascript
>> 
>> Here is the thing. I've been doing this stuff for a long long time. You can
>> take a moment to look at www.qbalsoftware.com to get an idea of my
>> background. I'd like to start collaborating on some solutions that turn
>> things upside down and produce some results that help teams fly!
>> 
>> Let me know if you are interested in talking further.
>> 
>> Regards -- Kramer
>> 
>> I live in Mt View (silicon valley) and this is my wing-man Cosmo.
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 

Re: Why stop so short

[Antoine Toulme <an...@lunar-ocean.com>]

Hi Paul,

thanks for the kind words, and hello to Cosmo :)

We have been preparing this release for quite a while with our meager
resources.

We're sorry to fall short your expectations. If you can devote some time to
our project, we would be ravished if you could open bugs for the items you
mention and discuss there. We'd be happy to accept your patches.

Thanks,

Antoine

On Thu, Jun 10, 2010 at 21:07, Paul Kramer <kr...@me.com> wrote:

> Hey Folks,
>
> You are doing something I think is great work in Buildr. But why stop so
> short.
>
> I'm my mind, all of the infrastructure should be developed with rapid
> development in mind. To me that equates to Python/Django and Ruby/Rails, and
> not only that. There is HUGE opportunity in the embedded space. Look at the
> rapid growth of the mobile market. The folks in this space are looking
> around and what do they see. Lots of Java based tools (cruise-control,
> hudson, teamcity, and on and on). That java stuff does not fit into that
> space at all.
>
> So why stop short with Buildr. Buildr could easily be extended to provide
> its own continuous integration, done in ruby/rails of course.
>
> Consider the following: http://qbal.mozdev.org/ circa 1999-2000
> http://qbal.mozdev.org/oldQbal.jpeg This was a proof of concept based on
> earlier work I've done. It was 100% javascript. I'm going to ramp this stuff
> up again, but this time I want to use ruby/rails/javascript
>
> Here is the thing. I've been doing this stuff for a long long time. You can
> take a moment to look at www.qbalsoftware.com to get an idea of my
> background. I'd like to start collaborating on some solutions that turn
> things upside down and produce some results that help teams fly!
>
> Let me know if you are interested in talking further.
>
> Regards -- Kramer
>
> I live in Mt View (silicon valley) and this is my wing-man Cosmo.
>
>
>
>
>
>
>
>
>
>
>
>
>
>