Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 7 years ago.
Improve this question
I mean, this is Sakai, the open source project of a learning management system. But, really I'm clueless trying to estimate the hidden costs in one implementation project (on the technology side, not the pedagogy-stuff) in a small-medium scale institution.
Deployment (1 engineer two or three months, with experience in Java EE)
Customisation (1 engineer, 1 designer two or three months also)
Support (1 guy)
One server reasonably good with 4, 8 or 16 GB in RAM. It will host the application server, the database server, and da da! ?
???
can somebody experienced, give me advice in how to estimate the TCO in open source implementations like this? In fact, it could be Moodle, and in that case I would be lost too!
Yep, is not really a question of programming, but I think that this is one proper place to ask.
Thanks!
I work on support staff for a large uni that uses Blackboard. All the support people are students working part time, so salary can be pretty low per hour. You'll want to have someone on permanent staff as an administrator, who could also be the developer/deployment guy. Perhaps only part time if your institution is small enough, but someone who knows the ins and outs of the system will be handy when (not if) things go wrong. (Maybe you could combine them with the support role?) On that note, you'll probably want a seperate server for backups and recovery, at the least something that will backup data.
If your school is small enough, maybe one person could handle the admin/support/dev roles by themselves (my roles are both support and developent and I often wish I had admin priveleges). You could probably talk to your IT department on how much servers are going for these days, I'm not sure there or on competitive salary ranges (but students are cheap.) Hope that helps some.
Sakai Deployments lists details of some Sakai deployments, but be careful to check the last updated date as I would look a deployment data that has been updated in the last year.
I manage a Sakai deployment and all aspects are doable with one FTE, which includes full customisation and development. For larger installations (>10K users) and for more customisation, consider adding another FTE.
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 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 9 years ago.
Improve this question
What are the key practical concepts that a fresh graduate should be educated with when he starts with his first programming job and how soon should you expect him/her to be productive and actually deliver the code you expect ?
source control and testing
Get them started with checking out code and writing unit tests first, learn what its about, and then go from there.
Yeah, that's a subjective question. We have done several summer and during-school internships as well as hired recent grads in CS.
If we start with a student who knows:
An OOP-ish language (Java, C#, VB.NET, C++)
How to fire up a compiler/debugger
How to work with our Source Code Control
Then given a defined problem domain with prerequisites (for example, for a recent intern, the problem domain was "adding autogenerated annotation metadata to TIFF files using self-describing barcodes"), the student needed to therefore know
How to generate and parse XMP
How to read/write metadata into TIFFs (we have tools for that)
How to read from a barcode scanner
Write unit tests
We saw progress in a week and saw demo code in a month. This was all within expectation. I mostly let him work on his own, but stepped in and course corrected some of his style and coding practice.
The important part of this is how goals were set and met. I made the important parts crystal clear (ie, requirements) and left the less important parts up to his design. After all, who wants to do paint by number all the time? For setting goals, I try in general to follow the SMART guidelines. A good goal is
Specific
Measurable
Avhievable
Realistic
Timely
It's very important that the project has a good feedback loop for communication. We were somewhat wanting in this regard.
Don't assume anything.
I made it through college without source control. Testing was stepping through the code with the debugger. No paperwork was needed for any assignment.
These 3 things are vital for production-grade code.
Just my thoughts and experiences:
Mentor. Assign a senior or lead programmer to mentor them. Not everyone is geared for this sort of assignment and a good mentor makes a difference. We have a mentor assigned to every new programmer - regardless of how long they have been coding - just to get the new employee familiar with our systems.
Start small. Depending on how your organization / team / etc is configured have the new grad start on some small maintenance projects, with a mentor reviewing their code and guiding them.
Get them training in the development environment your shop works in - expect that they will know a little about a few languages but that most of their development experience will be with school projects - not exactly solid production code. They will need a solid base to work from in the environment you use.
Code review and best practices - give them guidelines and make sure that they stick to them - if you are not using best practices internally, then start. Makes a huge difference when a large development group is involved. Review code frequently - this does not have to be a large group of developers in a meeting - one on one reviews, informal inspections, etc work wonders.
Develop an environment of cooperation - allow developers to mingle and talk and brainstorm - give them the opportunity to discuss ideas and thoughts that might not be related to the code at hand - they will rely on each other more then plants in the cube farm and production will higher quality. Allow them to read blogs and sites related to their craft - sights such as this one, coding horror, hacker news, etc. Support them going to local user groups and developer conferences.
Productive? That depends on the individual - some new graduates will never be productive coders but might be productive analysts or managers - some will be code machines out of the gate but will quickly churn out 1000 lines of maintenance nightmare code where 20 would suffice. I would say a fresh programmer out of school should be productive in 6 to 8 months - this is to say up to speed with you average programmers on staff, able to take a new project for your product, design and implement it, and able to handle any maintenance task required. It takes time to get the experience required to be productive - experience that can only come from actually developing in a production environment.
First: If you are a fresh graduate or a skilled developer - you always can gain new experience. So developers should be ready to always learn.
For the question: If your dev-team Practices Test-Driven-Development the first thing should be to show him how to write tests and how it can be useful.
Naturally the freshman should be able to use version-control, so if he relly has no skills at version-control a short introduction for this should be made.
Here are a few things I've found to be important for recent grads as well as new hires that have experience:
be proactive about including them in the corporate culture, don't assume they will fit in on their own
include them in meetings even if they are only there to listen
encourage them to interact in meetings when appropriate
be careful when dismissing their ideas as bad I've seen this discourage people from mentioning good ideas later down the road
Use of source control would be first on my list as very few schools need or rely on this. Really sit down and explain how to use the product you use and why it is necessary. Then for at least the first month, make sure to frequently check to make sure they are using it.
Next would be basic database skills. I've yet to see anyone come out of school really understanding how to query a database.
Third would be an introduction to your database and code base, explaining how things are done and organized and why.
Fourth, testing procedures and policies including how to do a code review, unit testing, QA etc. Tesing is not something that most students need to worry about either.
Fifth, assign a mentor if at all possible, someone the new person can go to for advice, to ask questions about company basics. You probably need someone to give them the basics of professional behavior as well. What is acceptable in terms of dress, attendance, etc.
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 working in a small team on some projects in my spare time. We are having the problem that we seem to go in circles and are not able to get our products developed - however this is not a problem during my day job. The lack of face-to-face communication seems to have a real impact on productivity.
Any examples of software or methodologies in use by the open source development community would be appreciated.
If you read the history of most open source projects, they start with one person doing a lot of the initial work. If there's a team, it's small, and one person actually leads the team.
To pick one example. In the Python community, they refer to Guido van Rossum as the Benevolent Dictator for Life (BDFL). His word is (more-or-less) final. In many cases there are folks don't agree with him -- but for the sake of the Python community -- they seem to acquiesce to his judgment.
I think every open source project has a (singular) lead programmer who assures that decisions get made, and made in a consistent way.
Back in the olden days, Fred Brooks (The Mythical Man Month) described "chief programmer teams". Same concept. Someone is in charge of the technical content. Emphasis on the one. Nowadays we call the the "architect" or some such term.
No real methodology here, but I think 2 things are important:
Have well defined goals and
responsibilities.
Let each developer
have the last say in how their
allocated part should be done.
In open source projects the only real and strongest motivation is the fun to be had coding the product. Relating to #2 above, if people are told what to do, and they don't agree with it, the motivation starts lacking. Of course there will always be a bit of give-and-take like in any other type of relationship.
Also about the face time, Skype is great for having face to face meetings, which I recommend at least once a week or month (depending on the size and momentum of the project)
This is a difficult question to answer because "open source projects" is a very broad selection of projects. I think the defining characteristic is the project has a single unifying goal (perhaps, a set of related goals).
Are you on any open source mailing lists? I am subscribed to my favorite distro's mailing list and the developers e-mail each other many times a day. Also, there are other avenues of communication such as IRC / Instant Messenger.
I am not a RoR developer, but I would suggest skimming through Getting Real for some inspiration.
My guess is that your private projects are all run and coded by developers. Developers are known to... keep on developing. The big difference, in my experience is that a company has experienced managers that can define when things are DONE. I'd recommend putting someone on the task of defining goals and decide when things are done.
I've been on some projects where we had a lot more talkers than developers. My inclination is to ignore the talkers and listen to the coders. Even then there's usually one person who is in charge of accepting patches. There may be political issues they have to tread lightly around, but for all intents and purposes they have final say.
Linus has had some fairly famous issues with the same problem. Take note of this thread from 2006: Talk is cheap. Show me the code.
One more thing. Since you say in the comments that you do have code, just a lot of rewrites, I'd highly suggest you read Eric Raymond's The Cathedral and the Bazzaar. Eric's a bit of a nutter actually, but the essay is priceless for anyone wanting to run a Free Software project.
I'd have a think about your and your team mate's motivation and goals in this project. Are they to:
a) Create an awesome product
or
b) play around with software, and learn some new things
Both answers are equally valid, and i'm guessing it'd be a mix with a leaning towards one or the other.
If it's more of (a) then look at suggestions on methodology etc. Maybe even consider forming a company around your awesome idea. Because making such a thing takes work.. and well you probably get enough of that at work.
If it's mostly (b) then you're going to have a harder time making an awesome product, but an easier time in that you can forgive yourself for not getting there right away and suffering multiple re-writes. And you will all be learning new skills each time you look at it and work together which are very applicable to your long term careers.
Firstly i suggest you all be clear with each other on why you are there. Then look at paring back on what you are planning on doing, and release early and release often. If your project is made up of three components and one is complete, then release that as a separate component and start building a community of users. This will pay off as these users will possibly help you with your code, plus form a solid core of users for the full product and let you assess how you are going early rather than later.
Good luck.
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.