Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
We're considering an ESB infrastructure.
When would you consider open source products like Mule and when would you consider packages like TIBCO, BizTalk or Oracle Fusion?
Cost and support are the obvious two distinguishing features.
If you have no money to pay for licenses, then open source is a good alternative.
If you don't like open source because of managerial objections, then you'll go with a licensed product.
With open source, you want to be sure that you're getting something that has some longevity to it. The signs are vibrant developer and user communities, easy access to forum support, periodic updates to the software, standards-based with alternatives available, etc. You don't want to make a choice for something as fundamental as infrastructure and regret it a year later because the open source project has fallen apart.
ESBs can play a lot of roles:
gateway for B2B with external parties
messaging between services
transformation between formats (EDI, XML, etc.)
orchestration of services
centralization of cross-cutting concerns like auditing, logging, metrics, etc.
You'll want to make a careful decision to meet all these needs.
I know nothing of their product, but Loose coupling versus decoupling ... briefly discusses an important point often missed, and one that can bite you very hard later on.
I worry that BizTalk is being taken over by the .Net types within Microsoft, and may be headed in the direction of the closely-bound interfaces of WCF. Read a lot, ask a lot of questions. Don't expect much of open source offerings.
Among other concerns, given the nature of the ESB design pattern, performance is very important. There are many results published out there. Here is the latest round of ESB performance done in January 2013. However in the performance space, it is advisable to run your own performance test and pick your choice, rather than banking on what are published out there.
In addition to performance, ease of use, extensibility, development effort it takes to integrate systems via the ESB needs to be taken into account. Sometimes, you may start the integration with an ESB, and later, as the system evolves, ability to govern the solution, security, ability to monitor, metering and billing, number of connectors supported, will come into picture. So you might want to watch out for the related solutions around the ESB along those lines.
In general, as it is the case with any software, total cost of ownership (TCO) is also key. Sometimes, it would seemingly be less costly to start with one vendor, yet over time costs might proliferate. Specially, supportability and maintainability is important, given the central nature of the ESB use.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I am building a 'software as a service' website that will be charging users a small monthly fee. I am considering changing the Github repository over from Private to Public. Essentially open sourcing it. Is this suicide? I would like the community to be able to benefit from the code. It is unlikely that I will accept any push request so I'm not going to gain anything in that regard. It is community based, so I think most of the value would be lost by someone self hosting it. It is for a very niche audience so I doubt someone else will start a competing hosting. I would really like the code to be in the open, but not at the expense of my idea of course. How does everyone else feel about this? What is common practice?
Conclusion, I'm keeping it closed for the time being. I may look to open source sometime after launch however.
Since you are not going to accept pushes you might as well hold on get your code stable and then publish it for others to learn and benefit from. You are still building the service, so its not going to attract too many eyeballs either.
From a business point of you, you might want to have a reasonable community around your service before you opensource it. if you are still budding who knows if its taken up by a stronger competitor. If your idea is patented its a different story.
To be honest, and this is not likely going to be a popular answer, but to myself, I would keep it closed for a period of time.
The reasons for this are simple, establish your foothold in the marketplace, build your userbase, your brand, then it gives you a mechanism to market your product further by selectively or completely open sourcing components of your system.
I say do it for both personal benefit and potential strategic benefit ... afterall, alot of software IS a service
Most open-source projects stand to provide a return in the right circumstances. Don't forget, unless you have a patent or some massive advance that is so complex and unfathomable that nobody can re-implement it .. if they want to they will anyway, so you have little protection staying closed source anyway ... even more interesting is that the open-source equivalent may well overtake your proprietary one if it garners support.
People may send you great ideas you never thought of, or take your codebase in a direction you would not have predicted. Unless you have significant value in terms of IP or strategic position tied up in the source code ... releasing it will probably do more good than harm.
Also, by being first to the open-source arena with your code, you gain control over any resulting community driven development ... if somone reimplemented your functionality and went open source ... could you compete on any front?
I know it is a cliche, but probably for good reason, but read The Cathedral and the Bazaar and the essay Open Source as a Signalling Device - An Economic Analysis which is an interesting read. Michael E. Porter's texts on competition analysis are interesting when held up against the mixed value economics and competitive forces of open source and shows how disruptive open-sourcing a product can be to competitors ... and how it can add value to your market position. Also, whilst counterintuative, it can raise the barriers to a successful entry by competitors.
More food for thought on the advantages and disadvantages of open sourcing:
What the DoD thinks of open source
Alfred H. Essa "Innovation and strategic advantage: lessons from open source" (warning, journal link)
I like to fix flaws wherever I see them, and perhaps I am one of your users. I'd rather send a patch than send a potentially nagging-sounding email any day.
What benefit are you hoping to gain from making the code open source? If you don't want the input of other developers then there are very few advantages and a whole lot of potential disadvantages.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I have already built a site from scratch. It has banning, PM, comments, etc. The PMs and comments are done using markdown (like SO).
There are pros and cons for writing my own or using another software. But some cons keeping me from using another forum software is
Multiple Logins: One for the site, one for separate forums.
Need to Customization code: I'll need to change the toolbar in the forum software so I can access pages on the regular site.
Look consistency: It may look drastically different from my site even after applying lots of css changes.
Banning and User consistency. Users may be ban on site or on forums but not the other. users may select a different or multiple usernames on the forum instead of being forced to use the same username on both site and forum.
Should I write my own forum code or should I use something already written? What are some reasons for or against writing my own and using forum software?
The heuristic I tend to use is that if at least two or three of these are true, it's probably worth writing yourself:
It's one of your core business offerings.
You have the time, money and resource to specify, design, build, test and support it.
The amount of time you would need to spend evaluating, prototyping with, integrating and customising off-the-shelf packages is near to or greater than the amount of time you estimate that it would take you to build your own.
The off-the-shelf packages do not have good support. By 'good support' I mean that you can raise an issue, and be assured that somebody will look into your specific issue and provide a fix if it is found to be a bug.
None of the off-the-shelf packages meet your quality bar for security, performance, quality, etc.
You are not writing open-source software, and the off-the-shelf packages have a viral open-source license; be particularly wary of AGPL and other similar licenses.
One of the oft-quoted articles about this is from Joel Spolsky. Lately he seems to have just been writing flame-bait, but this was one of his worthwhile early posts.
Note that you can also take a combination approach, and use some pre-built things such as recaptcha and gravatar even from within a bespoke solution.
Writing your own forum software is nowadays in almost no case useful. The available software is highly customizable. For example, you can create your own skin to fit with the layout of your website. You can integrate the login with that of your website.
Writing your own forum is so complicated that the quality of your own software will be much lower than of something like phpBB or vBulletin. And dont forget the security bugs, the mentioned software has been reviewed by a huge amount of people. Until you reach the same quality (functionality, stability, security, etc), your website will be outdated and your forum software with it.
Once again, the current forum software is so adaptable and extensible, that it doesnt make sense to make your own.
I think it highly depends on your needs for the forum.
First off, is the forum itself an essential part of your website's function? Or is it more of a 'support' style forum?
If it's essential to your daily business, then it makes more sense to write your own - or at least highly customize an existing package.
If what you need instead, however, is a vehicle for customer support, or some sort of generic community revolving around your site, I might recommend looking at a completely different vehicle: something like http://getsatisfaction.com, or a Google Group, or some such.
(I'm in no way affiliated with either of those sites).
Regardless of the solution you choose, I'd recommend you give some serious thought to how essential the forum is. If it's not, then I wouldn't waste too much time configuring/setting one up. Instead, focus on what your site's main draw is, and spend the bulk of your time on improving that. You and your userbase will be much happier with that, IMO.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
How to successfully implement democratic (non-BDFL controlled) type of management for the open source project?
More specifically - for the project using distributed source repositories.
What style of communication is best to adopt in such environment?
How to encourage merging branches into the master?
I am mostly interested in establishing the situation where people can directly merge into the master branch under the "social contract" agreement that they follow the project roadmap (which they themselves help to define) and that code they commit is tested.
I specifically want to encourage workflow
define the problem->define requirements and specific metrics of success->architect->build and test
The reason is that - I often see emails like here is the problem and here is how I think it should be solved
Immediately somebody else jumps in and starts a fight.
Not productive at all.
Often disagreement of that kind stems from not being on the same page on the problem definition, requirements or architecture. Or sometimes just because nobody even thought about such things.
How to encourage people to analyze the problem properly, share great ideas and select the best solutions?
How to organize communication so to avoid silly fights, make good decisions without being overly bureaucratic and move along at a good pace ?
Would you have any suggestions? Are there examples of projects managed this way?
How do you think adoption of distributed revision control instead of centralized affects the style of project management?
edit: found some interesting links in related questions
http://gettingreal.37signals.com/toc.php
http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/
Sorry for this somewhat off-topic answer (i.e. one not addressing directly the question). Please edit at your heart's delight!
Projects _do_ need executive governance!
Such may come from a single Benevolent (or not) Dictator, or a [IMHO, small] group, possibly open, of diverse but like-minded individuals. A standard joke on this is that: "The group should be made of an odd number of members, and 3 is already too many"; in truth, small collegial committees can be very effective.
This requirement for a "non fully democratic" decision making entity is however somewhat aligned with the processes suggested in the question. To effectively harness the good will of contributors to the project, the executive team needs to
be perceived as legitimate
communicate effectively
empower "the masses" to contribute with roadmap definition, problem identification, solution scoping and all other design-level tasks. (All the while it remaining clear that in the end, and after all has been said, final decision will be done in committee.
DELIVER a good and vibrant product (BTW by adopting agile development processes, the time between deliveries is lessened)
compromise when needed
advocate the interest of pooling resources in a coordinated fashion, rather than branching out.
Share the glory!
To support all of this formal documentation and processes are very useful. For example, the define the problem->define requirements and specific metrics of success->architect->build procedure indicated in the question can be implemented in the form a single collaboratively edited document (wiki-based or other), i.e. one per issue/idea. This document is templated with a defined format: required attributes such as date, initial posting info... and sections which are opened (and closed) for editing following a given schedule. This allows keeping a clean(er) record of the way the collective though of a given issue, what was suggested etc, what was [authoritatively] decided and why.
With such a process, the community feels engaged and hopefully individuals not too disappointed when the eventual decisions do not go "their" way. They can read and comment on the what and why of the decisions.
Another useful approach is to reward effective participation by informally (or factually) provide more weight to the contributors who effectively help with the project. The more active members can either gain their way into the "inner circle" or be handed-out leadership roles on subsets of the project.
Finally, the leaders of a project (whether in the context of a "democratic" or of a "partially dicatorial" leadership) need to be ever vigilant about "peace keeping". Contributors to Open Source projects are typically energetic, smart and opinionated individuals; conflict of opinion, conflict of personalities, impatience etc. is to be expected. These clashes however can be eased by systematically addressing issues with clear facts, moderating/editing aggressively against name calling and non-productive forms etc.
Originally posted on MetaOptimize.
Constitution for Governance of Open-Source Projects (v20100227)
Let it be affirmed that the primary goal in instituting governance of an open-source project be to ensure the long-term health of the project.
Accordingly, the default bias should be towards openness and inclusiveness.
However, policy should be changed as issues present themselves, in order to maintain the long-term health of the project.
For the model of decision making, we favor a "do-ocracy".
The people who contribute the most generally command the respect of the community.
Alienating them is the best way to derail the project.
The repository should be open the committers, given that commits can easily be reverted and commit-access easily revoked. This is preferable to alienating potential committers.
To ensure transparency for developers new and old, and allow them to decide their involvement in a project based upon the history of the project, their should be transparency and openess in the inner working of the project. For example, the email archive should be public.
Lastly, let us remember that too much red-tape gets in the way of progress. So red-tape and other barriers to contribution should be avoided, and only added as issues present themselves.
This Constitution can and should be amended as issues present themselves.
Therefore be it resolved.
access to repository
there are several options ranging from one controlling committer to anyone can commit - but upon social agreement that they respect the project guidelines and the roadmap.
in my opinion distributed repository allows you to be more relaxed with who you allow to commit, because there are multiple backups and the repo becomes virtually unbreakable.
on a separate note - anyone can commit approach - which I would like to test out - sounds more like a "wiki". I can directly compare this with my experience managing a wiki (nmrwiki.org): where despite complete openness - where not even user registration is required to edit the resource, people are often wary about "breaking stuff" and this worry becomes a mental barrier to making a contribution. So a permissive approach to repository management may just work.
Communication style:
email and mailing lists:
discuss everything concerning the project in public (?)
when asking questions - do not bundle
questions with your own opinions
encourage people to propose more than one solution
ask people to weigh pros and cons
be brief and to the point
avoid frivolous language that can be perceived negatively with people that do not know you well
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
Our investor wants a SDLC. I've never written one before, and I don't have enough time to go and buy a book, or spend much time learning about them. From what I've been told about them, they consist of requirements (what needs to be done), and a list is done. Is this correct?
Update:
I have found this article which really helps to explain things in simple terms and very quickly. Not that I think an SDLC should be done quickly. In my case, I have no other option.
There are lots of ideas about SDLC out there. You can't swing a cat without hitting one.
What have you done to develop software that attracted your investor in the first place? Can't you describe that? Why do you have to go out and "learn one"?
There's a number of choices:
Waterfall: requirements->design->build->test->deploy,
all in sequence
Iterative: similar to waterfall, but you break the design into smaller pieces, of 1-2 week duration, that are delivered at the end of the iteration.
Extreme Programming (XP): Kent Beck's approach; no BDUF (Big Design Up Front). Everything is designed, built, and delivered in small pieces.
Scrum: Agile, iterative, but not as dogmatic as XP.
Rational Unified Process: Waterfall from IBM.
Not really; that's more project management. That's what you need at the point where you've figured out how you're going to develop software.
For the 'how' of developing Software, the two 'biggies' are Agile and Waterfall; with a weird hybrid in between the two.
But that's only one part of the Software Development Life Cycle: You still have to have a maintenance and deployment plan.
My question for you: If someone's giving you money, and they want a plan, isn't it in your best interest to read a book about the SDLC and give them a plan?
If your investor wants you to describe the SDLC, he wants that you describe how looks the life of a software project which is done by you from its plan, birth, through growth to maturity and death. That is the reason why it has "life" in its name. The result of SDLC should be "software" hence the first word. The "development" part comes from the fact that you are responsible for planning, specifying, designing and implementation of the software, you should create (develop) the software. And finally, "cycle" means that, when the investor looks at you SDLC and thinks it is good (it produces quality and business value), he can ask you to use the same process once again in another project.
A complete SDLC meaning you need to perform Requirement gathering and Analysis-> Design (Design document creation) -> Coding and Unit testing -> Testing (System and Integrated testing) -> Deployment and Support -> Maintenance
I found this Blogg really helpful.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I have a problem to solve that I think will take 4 days, but if I had a feature request sorted and a snapshot release then I reckon I could have it done in one. Superficially this creates a budget of 3 x my daily rate to get it the feature-request actioned.
So my questions are, have you ever paid an O/S project member to fix something for you? Did it work out OK? How did you sell the idea to your manager / colleagues and where did the money come from?
Most importantly how did you go about asking nicely? Is there an etiquette for these things? Are the project leaders likely to be receptive to the idea?
In case it matters, the software with the the missing feature is a JBoss project - the home of professional open source - and I'm able to claim expenses as I'm a contractor.
At work, we've had good luck hiring open source maintainers to enhance libraries that we use.
Here are some projects we've done in the past:
We needed to integrate Quake 2 with wxWidgets. We hired Vadim Zeitlin, a major contributor to wxWidgets. In less than 4 days, he built a wxQuake2 widget by adapting the Windows version of Quake 2.
Later on, we needed portable access to raw bitmaps. So we hired Vadim again, and worked with him to produce a new raw bitmap API. This involved a substantial bit of design work, but we really liked the resulting API, and we use it to this day.
At a later date, we hired another one of the core contributors to improve wxWidgets accessibility support. As it turned out, we ended up not using this code right away, for various technical reasons. But other people have been enhancing this code since then, and we hope to use it some day.
In other words, hiring open source maintainers is a lot like hiring any other kind of contractor. But some things are a bit different, too. Here's some advice based on our experiences:
You'll have the most luck if you want to enhance an existing project and release the changes as open source.
In general, you want to hire members of the core team. They have the best track records, they're the most productive, and they have the best chance of getting your changes merged upstream.
You want to get your changes merged upstream. If you don't, you'll be maintaining a local fork, which is a headache.
Before hiring, do some research. Who works on the features you care about? Are they somebody you'd enjoy working with? Read the mailing lists and glance at the version control history, and pick out a few people to approach.
During the design phase, there may be a bit of give-and-take. The developers are looking at the larger health of the project, and you're looking at the needs of a specific business. This has occasionally made negotiations a bit more complicated for us, but the final result has typically been a better design than we would have chosen on our own.
And most importantly, don't be shy. In any sufficiently large open source project, several members of the core team will already run consulting businesses. In smaller open source projects, you'll generally find several contributors who want to run consulting businesses.
And if you're still hesitant to approach somebody, you can always ask, "Do you know anybody who'd be interested in getting paid to work on $FEATURE?" If they're not interested, you haven't put them on the spot, and they may tell you who to ask.
On the whole, we've been impressed with the professionalism and productivity of open source maintainers, and I would recommend this route for others.