Archive for the 'SE Michigan Tech' Category
July 13th, 2010 by Mark Ramm
So, I’ve been working on sf.net in various ways for about a year now.
http://sourceforge.net/p/. It’s written in Python using modern open source tools, from RabbitMQ, and MongoDB, to Git and Mercurial. And we are committed to making this the most open forge possible. We’re committed, to open processes, open code, and perhaps most importantly open data.
The first thing we did was create some new pages for downloads. Recently we releases a new service designed just for open source project leaders who want to use sf.net as a directory and downloads service.
But, we’re also aware that one of the most important services we provide is project hosting. For the last several months a small group of us have been trying to bring sourceforge.net’s tools into 2010. And now we’re releasing an early preview of those new developer/community tools:
We have a long way still to go, but every long journey begins with a single step, and today’s step is allowing you to try the new forge, to create new projects at:
https://sourceforge.net/register
Where you can go to get a new project, with our new tracker, wiki, git, svn, and other tools. Projects can have subprojects, and links to other tools hosted off site, along with the many features that sf.net brings (free web hosting, hosted apps, etc).
But, why do all this?
In 1999 SourceForge was cool.
It provided all the tools that an open source project needed to get going, from cvs hosting, to bug tracking, and e-mail list support.
They pioneered free free software project hosting, and helped to transform the software development culture from one which barely new about free software or open source, to one where nearly everybody I know uses open license software. Oh sure, some of them might not know it, but they have it on their phones, in their TVs, their wireless routers — not to mention all the websites they use everyday that run on open source.
But, time passed.
More alternatives came out, more projects (including my own) started self hosting, and the landscape of open source software development changed. SourceForge.net took a long time coming out with support for new tools like svn, and then git.
Still, SourceForge has a special place in my heart. Partly it’s nostalgia, I suppose, but I still think:
- the core mission is still right
- and there is still a real need
We (Open Source developers) still need tools like git, mercurial, and svn hosting. We still need bug trackers and mailing lists. And in a meeting of other open source project leaders last fall, nearly every single one of them identified the time wasted integrating and administering these tools as one of their most important frustrations.
Not enough…
But, for many sourceforge.net and other free project hosting services were just not good enough, they weren’t scriptable, the weren’t extensible, their data wasn’t portable, and so they felt like they had to take on that cost.
And I fundamentally believe that open source projects live an die by communication, and that sourceforge.net can do something new by integrating the various kinds of “conversations” that happen around the project. We can integrate mailing lists and forums, we can integrate SCM and ticket trackers, etc.
New and improved
So, a couple of us have been quietly working on something new. The new forge is designed around a few core ideas:
- that data should be portable (every project gets their own database, which they can take with them if they want),
- that the open source community ought to be able to extend and enhance the tools they need,
- that integrating and cross linking the various kinds of conversations that open source projects need to have ought to be easier.
So, what we’re announcing today is more of a commitment to getting there on all these things, and a commitment to the “release early, release often” project management strategy.
So, expect us to take your feedback and make things better. Expect us to release lots of small fixes, and expect a few places where things are broken/incomplete because we value feedback more than polish at this point.
June 29th, 2010 by Mark Ramm
Lean Manufacturing people go around saying “it’s always a process problem.”
Meanwhile Gerry Weinberg, who wrote several books that I love, and gives lots of great advice, including the some of the best advice I’ve ever read about how to give advice, says “every problem is a people problem.”
So, which is it?
Are bad things that happen the result of bad processes, are they the result of things people do?
I’ve been party to a bit of discussion about this in the last month or two, and in the end it’s all pretty silly.
Processes are created by people, implemented by people, and are designed to accomplish the goals of people.
People run processes!
So, whenever something is broken, it’s people who will need to find the problem and fix it.
People can and do think of ways to improve processes everyday, but I’ll eat my shoe if you find a process that thinks of a way to improve people.
But there’s still a HUGE problem.
Modern companies seem to have a persistent failing — they look for people to blame when something goes wrong — and ignore the context in which those problems happened.
When something goes wrong, fire some people, and replace them with new people who make the same mistakes all over again.
Sometimes you “get lucky”.
The company might get lucky and find a person who’s able to raise awareness,
reveal the larger contextual problems, and succeeded in spite of the fact that everything’s stacked against her.
More often than not though, the poor new guy doesn’t see the systematic pressures that caused everything to fall apart, at least not until it’s too late.
Sometimes replacing what’s broken isn’t enough.
Sometimes it’s the equivalent of a mechanic replacing your car’s engine several times in a row, because it keeps burning up — without ever checking to make sure oil is flowing normally, and the cooling system is working.
The easy way out.
It’s often easier to blame people because they don’t “control” them they way they do the context. This blame game is as old as the hills, but definitely not as pretty.
Help people fix processes
The solution is to ask people to look for the systematic pressures, give them the tools to find them, and to empower them to change the way work gets done.
In the end, people will improve the processes, if they believe they are allowed.
Sometimes a design isn’t working because you think you can’t change the one element that needs to be changed.
–Ryan (via svn)
The same thing is true when you are designing the processes by which work gets done.
July 16th, 2009 by Mark Ramm
No, we’re not moving the TG2 hosting to SourceForge. Instead, Sourceforge is now using TG2 to display the front pages, project pages, and download pages for all projects
. This comes with a new look for SourceForge, but more than that it’s the first step in a fundamental rethinking of what SourceForge does. We’ve been given the opportunity to focus on improving the experience of users of SourceForge hosted software. We’re not ignoring developers, and lots of good stuff is going on for developers, but this latest update is all about the users. We wanted to make downloading software from SourceForge faster and easier, because this will help projects attract and maintain users. And more than 9 out of 10 of page views on SourceForge are by end-users, which means that the vast majority of page views on the SourceForge site are now going through TG2.
It’s all about users.
The big user experience wins come from some heuristics that we’ve developed to guess the best file to download. We’re analyzing your browser’s user agent for information about your operating system. And when the project has not told us about their preferred download, we’re analyzing file names and other data to get our best guess as to which file is the most relevant for a particular operating system.
This means we can generally give you a direct link to the right version of the file, right on the project page, so there’s no need to browse through a complex array of pages, and links just to finally get to the file you came to download in the first place.
Now with TG2 goodness.
Under the hood, there’s a new TurboGears 2 app powered by MongoDB. We’ve put this all together very quickly, and there have been a couple of rough spots here and there. Fortunately, none of the rough spots were in the TG2 or the TG2 stack.
But we did have a couple of rough patches. For example, we couldn’t use a mongo replica pair for the master database and have slaves on each node. So, we chose to try running the site all against a single replica pair rather than to do master-slave everywhere. This was compounded with a coding issue that, we were trying to pull tons more data out of MongoDB than we needed, and we ended up saturating a 2 gigabit network connection between the mongo master and the local slaves. Which if you think about it is kind of amazing, since MongoDB was still only using a few percent of the CPU on the box.
At this point though, all those issues are resolved and we are very confident that we’ll be able to add more user-facing improvements to SourceForge project pages and make the download side of things even better.
December 17th, 2008 by Mark Ramm
I’ve been very, very busy trying to get TurboGears 2 beta 1 ready to go, as well as a few other interesting projects, and had neglected to blog about a ArbCamp before, then it was sold-out, and I didn’t blog about it because I didn’t want to raise people’s hopes only to have then dashed upon the rocks. But, we’ve secured a new venue, so ArbCamp registration is now Un-Sold-Out. It’s UnSold because it’s free, and it’s un-Sold-Out because we can now fit everybody in. We had over 160 people registered and on the wait-list, but could only let 100 people in. Now we have space for 200, so those on the wait-list and those who didn’t sign up in time have a second chance.
ArbCamp will be tomorrow night, in the upstairs of the downtown Cottage Inn’s, so this is kind of last minute, but I think it’ll be a very cool event. It’s an UnConference, and people will be self-organizing a variety of sessions, and the possibilities are endless.
June 8th, 2008 by Mark Ramm
Well, it’s official now, I have a new job with Predictix, doing open source TurboGears and Python web dev stuff. Predictix is very much invested in helping the TurboGears community to grow and thrive, and I’m proud to be working with their team. And I’m even more excited about the fact that they want me to do work on TurboGears 2 as part of my “real job.”
One of my main goals when looking for this job was to make sure that whoever I worked for was committed to growing and takeing care of the TG development community. And I couldn’t have asked for anything better. Working for Predictix will help me to polish up the good work that’s already been done to get us to a TG2 beta release, and they already have a lot of fantastic stuff that they would like to open source, which I’m really excited about.
TG2 is moving forward like crazy. In the last three weeks, we’ve had two sprints, both of which had several people working on docs, and on adding the last few features needed for the beta, and cleaning up the show-stopper bugs in our ticket system.
I’m a bit burned out by all the activity, but at the same time I’m very excited about where we are going. I think 2008 is shaping up to be a really busy year for the TG dev team. I see my job in the very short term as creating some stability and consistancy in the midst of the firestorm of new development that’s going on. So, my highest priority right now is getting a stable beta release out the door, and helping us to move forward the docs so that anybody who wants to try out TG2 has a stable base to work on.
My plan will be to do releases about once a month for the rest of the year (or until we have a TG2 final release), because there’s a lot going on, and I want to make that stuff available to people as soon as possible.
