Sun is excellent at computer plumbing, and has the track record to back it up. Microsoft has dominiated the eye balls of the end-user and they too have the track record to back it up.
C# vs Java is a race for volume, just as IE and
Netscape was a race for volume. This race won't
turn out the same way though because game has changed
And that game is Open Source. Open Source is the
wild card in this battle. Without Open Source, I believe Microsoft would win in short order.
Prior to 1987, I worked as a Unix System Administrator at HP in their networking development lab.
I was responsible for all Unix
Systems and new HP-PA Risc Systems. The approach
I took then and still believe in is to provide
an environment where people can be the most productive. To me this means that everyone has root access and the ability to use their judgement to accomplish their work.
How did I support this kind of environment? Instead of using my time to develop and enforce policy, I used my time to educate and develop
tactics to restore environments when issues occured.
The result was a very productive devlopment environment with many skilled
engineers that also further developed their
system admin skills (this approach later served
me well, when I moved into engineering as a
buildmeister, release enginering, configuration
management engineer)
I spent many years at HP and Sun and the trend
I have observed over 20 years is that everytime
centralization in engineering environments occurs, the support teams become distanced from their end-users. The solutions delivered by centralized organizations are almost
always generic as a result of limited funding and
staffing.
In all that I've observed, engineering
will hire their own system administrators to better
respond to specific engineering needs.
IT organizations seem to be a much better fit
for non-engieering teams, such as MIS, Operations,
Manufacturing, where the users as part of their
day-to-day work are not required to reconfigure,
install new software for evaluation, testing and
further development.
I'm currently working at a company that does not
allow developers root access... my solution has
been to bring my own laptop preloaded with everything I need to get my work done...
SGI lack of direction has been going on for at
least 10 years. I was working at Sun in 92' and
went over for an interview at SGI at that time
and walked away shaking my head... It was
explained to me that during the interview that
SGI wanted to move into the commerical server market. During the interview, we discussed:
SGI technologies, methodologies, and culture. It
was clear from a technology perspective,
SGI could accomplish what they needed to, but
to affect change in the culture to deliver into
the commerical server market was underestimated.
In summary, responding to business opportunities,
in some cases requires cultural change. For example, a company like Sun, that is primarily a systems company (Sparc + Solaris) has a culture that is best suited to deliver their products into their market channels. Back in 95' rumors
floated about Sun buying Apple... If this had occured the bug challenge for Sun would be cultural changes. One culture is end-user oriented and the other is OEM channel oriented.
HP's bussines opportunities are a superset of
Sun, Apple, and SGI, requiring their culture to
be more diverse. Anyone trying to effect cultural
change has a big challenge, but in corporations like HP, GE, IBM, etc... it is monumental.
I worked on the HP-UX 1.x and 2.x releases in the
mid-late 80's. HP has always been a good training
ground for engineers, and many have gone on to
careers outside of HP.
This operational approach is technically sound, its the business side of using this approach
that is challenging. The challenge in many large companies,
and smaller companies too, is who owns what? There is a constant negotiation that goes on
between the business and engineering organizations. Questions that need to be answered in
this type of model is: who is funded for this work, who supports it, who approves it. When
cost cutting needs to occur, who prioritizes? who decides? Who ulitmately is repsonsible for
delivering what?
This type of model would be interesting in an OEM relationship, where product branding
is key to OEM marketing, but the challenges that will face the company is how do they
go about providing a level playing field for their OEM customers, how does the company
accomodate everybody. One of the key areas in a business relationship, is that when dates
are agreed upon and not met, the OEM customers can loose a tremendous amount of revenue,
resulting during the project lifecycle in business decisions be made? What's going to get cut,
and what is the quality level?
The book contents are about tools and running a project which implies specific tools, methods, and practices
Fundamentally the question I ask myself is, "Is this book for OSS fun or profit?"
Based on my experiences, I don't see the value from a business perspective
Thanks for the pointer on Subversion, I spent time just the other day, reading about it.
I think that the team effort will result in an improvement over CVS, but I don't see it or
any other solutions addressing the problems faced in todays business environment. For
example, versioning for source code is different than version/revisions of documents, from
a document control perspective, or versioning of a bugid, requirement id, etc... Fundamentally,
change control is difficult when looked at from a customer perspective, and working back
towards engineering and marketing.
You may have already considered the following, but in a nutshell the following keys are
what I look for:
Managing Change
Repeatable Process
I've found that the better these two keys items are executed against, the better the
productivity, quality, and timeliness of the project will be.
What I mean be managing change, is all elements of a project: requirements, schedules,
dependencies, source code, test code, development environment, build environemnt, test
environment, packaging/assembly environment, st aff resources, etc...
What I mean be control mechanisms, is what practice and supporting procedures/tools
are used to control change (i.e approve, non-approve, etc...)
Keys steps to peform
Defining the project lifecycle in terms of both content and quality along a timeline
Defining control mechanisms for pre-integration, integration, build, test, and publishing cycles
Identify risk and mitigation plans for the first two bullets
I've observed many tools and practices being used, ulitmately it is up to the people executing
the assigned roles and responsiblities... there is no silver bullet in terms of tools... I myself do
prefer lite-weight loosely couple tool versus the monlithic solution as it reduces both central
point of failure and dependency on specilalized knowledge to maintain.
Another key area to consider is to try and get as many people on the project to understand
the product lifecycle workflow and practices, specifically change control and change management
I've had the opportuntity to work with companies that are either using open source software
as a backbone for their services and for their products.
An area that I've seen in which all have many challenges with, is not in the development of their
respective products and services, but in managing the environments, tools and source code.
This is not unique to open source, but this is an area where open source could really contribute.
Fundamentally the tools used by the software industry to manage and publish software are
20-30 years old and have not undergone much in the way of evolution. The tools and practices
used today to manage the development of software, in most cases gets in the way of productivity
and quality, because they are not DESIGNED to solve todays problems, they are adapted to
solve today SYMPTOMS.
If we look at all of the mainstream change control systems, they Generally don't solve todays
business needs, resulting in customizations by the development teams, that generally miss the
mark. They may support some engineering team needs, or some developer needs... But ask
most team leads, project managers, and engineering managers and they will tell you that this
is an area that causes alot of pain.
CVS based on top of RCS
Teamware based on top of SCCS
Perforce based on top RCS
Continuus based on top of RCS
ClearCase based on Apollo DSEE
Bitkeeper based on SCCS
SCCS was developed... what around 1975, RCS early 80's, ClearCase/DSEE mid 80's
Fundamentally these products are not DESIGNED to support all the different variants and
product lifecycles to repsond to todays business opportunties.
Individuals and Companies have made great attempts at creating wrappers, customizations,
books, and articles to attack the problems that the deisign and implementation of these solutions
failed to deliver. But this is only addressing the symptoms of the design and implementation of
these tools
A new look at the problem is needed, if anyone expects to see any significant
improvement in the ability to deliver the right solution in the right timeframe to the right customer.
I'm not sure, based only on my exepriences up-to-this-date, that open source methodologies
can make any SIGNIFICANT improvement over todays current business methodologies...
I don't see any accountability in open source metholodgies. Not being able to see accountability
in the methodologies, leads me to be concerned about how open source addresss businesses,
support the consumers need to effectively resolve issues and concerns.
My first job in a software engineering organization was as a System Administrator.
I found that the breadth of experience I gained
positioned me to move into Lab System Administration. In my experience there was alot more freedom to create solutions in a R&D Lab. From here I moved into Software Testing, and Software Release Engineering. The System Admin background was always a very big help!
From there I did Program Management, but found that I prefered creating software/hardware solutions and now consult and build custom
portal solutions.
I guess the thing it took me awhile to determine is what I was best suited for. Some folks love trouble-shooting and responding to urgent situations, some like to create, some like to manage, some like to write. I was fortunate to
have spent a large part of my working years in
large companies that provided exposure to alot
of different careers. Once I figured it out...
I went out on my own.
Slashdot Mirror
Sun is excellent at computer plumbing, and has the track record to back it up.
Microsoft has dominiated the eye balls of the end-user and they too have the track record to back it up.
C# vs Java is a race for volume, just as IE and Netscape was a race for volume. This race won't turn out the same way though because game has changed
And that game is Open Source. Open Source is the wild card in this battle. Without Open Source, I believe Microsoft would win in short order.
qbalus
Prior to 1987, I worked as a Unix System Administrator at HP in their networking development lab.
I was responsible for all Unix Systems and new HP-PA Risc Systems. The approach I took then and still believe in is to provide an environment where people can be the most productive. To me this means that everyone has root access and the ability to use their judgement to accomplish their work.
How did I support this kind of environment? Instead of using my time to develop and enforce policy, I used my time to educate and develop tactics to restore environments when issues occured.
The result was a very productive devlopment environment with many skilled engineers that also further developed their system admin skills (this approach later served me well, when I moved into engineering as a buildmeister, release enginering, configuration management engineer) I spent many years at HP and Sun and the trend I have observed over 20 years is that everytime centralization in engineering environments occurs, the support teams become distanced from their end-users. The solutions delivered by centralized organizations are almost always generic as a result of limited funding and staffing.
In all that I've observed, engineering will hire their own system administrators to better respond to specific engineering needs.
IT organizations seem to be a much better fit for non-engieering teams, such as MIS, Operations, Manufacturing, where the users as part of their day-to-day work are not required to reconfigure, install new software for evaluation, testing and further development.
I'm currently working at a company that does not allow developers root access... my solution has been to bring my own laptop preloaded with everything I need to get my work done...
Kramer
SGI lack of direction has been going on for at
least 10 years. I was working at Sun in 92' and
went over for an interview at SGI at that time
and walked away shaking my head... It was
explained to me that during the interview that
SGI wanted to move into the commerical server market. During the interview, we discussed:
SGI technologies, methodologies, and culture. It
was clear from a technology perspective,
SGI could accomplish what they needed to, but
to affect change in the culture to deliver into
the commerical server market was underestimated.
In summary, responding to business opportunities,
in some cases requires cultural change. For example, a company like Sun, that is primarily a systems company (Sparc + Solaris) has a culture that is best suited to deliver their products into their market channels. Back in 95' rumors
floated about Sun buying Apple... If this had occured the bug challenge for Sun would be cultural changes. One culture is end-user oriented and the other is OEM channel oriented.
HP's bussines opportunities are a superset of
Sun, Apple, and SGI, requiring their culture to
be more diverse. Anyone trying to effect cultural
change has a big challenge, but in corporations like HP, GE, IBM, etc... it is monumental.
I worked on the HP-UX 1.x and 2.x releases in the
mid-late 80's. HP has always been a good training
ground for engineers, and many have gone on to
careers outside of HP.
This operational approach is technically sound, its the business side of using this approach that is challenging. The challenge in many large companies, and smaller companies too, is who owns what? There is a constant negotiation that goes on between the business and engineering organizations. Questions that need to be answered in this type of model is: who is funded for this work, who supports it, who approves it. When cost cutting needs to occur, who prioritizes? who decides? Who ulitmately is repsonsible for delivering what?
This type of model would be interesting in an OEM relationship, where product branding is key to OEM marketing, but the challenges that will face the company is how do they go about providing a level playing field for their OEM customers, how does the company accomodate everybody. One of the key areas in a business relationship, is that when dates are agreed upon and not met, the OEM customers can loose a tremendous amount of revenue, resulting during the project lifecycle in business decisions be made? What's going to get cut, and what is the quality level?
RegardsKramer
The book contents are about tools and running a project which implies specific tools, methods, and practices
Fundamentally the question I ask myself is, "Is this book for OSS fun or profit?"
Based on my experiences, I don't see the value from a business perspective
Thanks for the pointer on Subversion, I spent time just the other day, reading about it. I think that the team effort will result in an improvement over CVS, but I don't see it or any other solutions addressing the problems faced in todays business environment. For example, versioning for source code is different than version/revisions of documents, from a document control perspective, or versioning of a bugid, requirement id, etc... Fundamentally, change control is difficult when looked at from a customer perspective, and working back towards engineering and marketing.
Regards KramerYou may have already considered the following, but in a nutshell the following keys are what I look for:
Managing Change
Repeatable Process
I've found that the better these two keys items are executed against, the better the productivity, quality, and timeliness of the project will be.
What I mean be managing change, is all elements of a project: requirements, schedules, dependencies, source code, test code, development environment, build environemnt, test environment, packaging/assembly environment, st aff resources, etc...
What I mean be control mechanisms, is what practice and supporting procedures/tools are used to control change (i.e approve, non-approve, etc...)
Keys steps to peform
Defining the project lifecycle in terms of both content and quality along a timeline
Defining control mechanisms for pre-integration, integration, build, test, and publishing cycles
Identify risk and mitigation plans for the first two bullets
I've observed many tools and practices being used, ulitmately it is up to the people executing the assigned roles and responsiblities... there is no silver bullet in terms of tools... I myself do prefer lite-weight loosely couple tool versus the monlithic solution as it reduces both central point of failure and dependency on specilalized knowledge to maintain.
Another key area to consider is to try and get as many people on the project to understand the product lifecycle workflow and practices, specifically change control and change management
Good Luck,Kramer
I've had the opportuntity to work with companies that are either using open source software as a backbone for their services and for their products.
An area that I've seen in which all have many challenges with, is not in the development of their respective products and services, but in managing the environments, tools and source code.
This is not unique to open source, but this is an area where open source could really contribute. Fundamentally the tools used by the software industry to manage and publish software are 20-30 years old and have not undergone much in the way of evolution. The tools and practices used today to manage the development of software, in most cases gets in the way of productivity and quality, because they are not DESIGNED to solve todays problems, they are adapted to solve today SYMPTOMS.
If we look at all of the mainstream change control systems, they Generally don't solve todays business needs, resulting in customizations by the development teams, that generally miss the mark. They may support some engineering team needs, or some developer needs... But ask most team leads, project managers, and engineering managers and they will tell you that this is an area that causes alot of pain.
CVS based on top of RCS
Teamware based on top of SCCS
Perforce based on top RCS
Continuus based on top of RCS
ClearCase based on Apollo DSEE
Bitkeeper based on SCCS
SCCS was developed... what around 1975, RCS early 80's, ClearCase/DSEE mid 80's
Fundamentally these products are not DESIGNED to support all the different variants and product lifecycles to repsond to todays business opportunties.
Individuals and Companies have made great attempts at creating wrappers, customizations, books, and articles to attack the problems that the deisign and implementation of these solutions failed to deliver. But this is only addressing the symptoms of the design and implementation of these tools
A new look at the problem is needed, if anyone expects to see any significant improvement in the ability to deliver the right solution in the right timeframe to the right customer.
I'm not sure, based only on my exepriences up-to-this-date, that open source methodologies can make any SIGNIFICANT improvement over todays current business methodologies... I don't see any accountability in open source metholodgies. Not being able to see accountability in the methodologies, leads me to be concerned about how open source addresss businesses, support the consumers need to effectively resolve issues and concerns.
Regards,Kramer
My first job in a software engineering organization was as a System Administrator. I found that the breadth of experience I gained positioned me to move into Lab System Administration. In my experience there was alot more freedom to create solutions in a R&D Lab. From here I moved into Software Testing, and Software Release Engineering. The System Admin background was always a very big help! From there I did Program Management, but found that I prefered creating software/hardware solutions and now consult and build custom portal solutions. I guess the thing it took me awhile to determine is what I was best suited for. Some folks love trouble-shooting and responding to urgent situations, some like to create, some like to manage, some like to write. I was fortunate to have spent a large part of my working years in large companies that provided exposure to alot of different careers. Once I figured it out... I went out on my own.
Cheers, QBAL